A subprocessor register must follow the product and data, not the provider's logo.
The showcase has no production subprocessors: its databases run locally and app demos call no remote backend. This page separates that state from a future commercial architecture.
Production subprocessors
0 configured
This number describes only the current local environment; it is not a promise about future architecture.
Inventory by current processing activity.
| Scope | Current system | Data | State |
|---|---|---|---|
| App demos | Local browser | Fictional data | No remote product service connected |
| Commercial brief | Local Prisma + PostgreSQL; writes closed | Voluntary contact details and context | Activation requires complete privacy information |
| Editorial newsletter | Local Prisma + PostgreSQL; writes closed | Email and consent | Conditional activation; no delivery provider connected |
| Blog and media | Local Payload CMS + PostgreSQL | Editorial content | No external CDN or object storage connected |
Before connecting a provider.
The register must become specific to each app and the production marketing site.
- 01Legal name, service, and exact processing role.
- 02Covered product, data categories, and purpose.
- 03Processing country, transfer mechanism, and hosting region.
- 04Contract, safeguards, duration, and deletion mechanism.
- 05Added date, latest review, and internal owner.
- 06Notification and objection channel before a material change.
Atlassian is not automatically our subprocessor.
The host product is chosen and contracted by the customer. The legal relationship will depend on the real architecture, accessible data, and additional services used by the app.
The site and apps keep two registers.
A blog or email provider must not be presented as receiving Jira data. Conversely, a remote product service must not disappear inside the site's general policy.
No provider receives data because its logo looks reassuring.
Inspect the data flow, then require one register row for every connected service before launch.