Data processing agreement

The customer is the controller for the personal data it stores on the platform, for example rows in its databases, files in its storage and log output of its applications. The operator is the processor for that data and processes it only on the customer's documented instructions.

The operator remains the controller for the data it needs to run the platform itself, such as the customer's account, sessions, audit log and billing records. That processing is described in the privacy notice, not here.

The subject of the processing is the hosting and operation of databases, applications, background functions, storage and realtime channels for the customer. The nature of the processing is storage, transmission and execution of the customer's own code against the customer's own data. The purpose is the provision of the platform as described in the terms of service.

The duration of the processing matches the term of the main contract, extended by the thirty day export window agreed there.

The categories are determined by the customer, because the customer decides what to store. The operator does not restrict them technically and does not inspect them.

Where the customer intends to store special categories of personal data under Article 9 GDPR, the customer informs the operator in advance so that the measures in the annex can be reviewed for adequacy.

The customer's instructions are given by the customer's use of the platform, by the configuration in the dashboard and by written instructions to the operator's contact address. The operator informs the customer without delay if it believes an instruction infringes data protection law, and may suspend that instruction until it is confirmed.

The operator processes personal data only within the European Economic Area, apart from the transfers described in the annex, which rest on standard contractual clauses.

The operator commits every person who may access the customer's data to confidentiality and instructs them on the requirements of data protection law. Access is limited to what is necessary to operate the platform and to answer the customer's support requests.

The operator maintains the measures set out below under Article 32 GDPR. They are described concretely rather than as a list of badges, because the customer has to be able to check them.

• Transport encryption: TLS on every public endpoint, HSTS on the production origin, no plaintext HTTP path to the API.
• Credential storage: passwords hashed with bcrypt at cost twelve, session and ticket tokens stored only as SHA-256 hashes, database credentials encrypted at rest with a key identifier so that keys can be rotated.
• Tenant separation: one PostgreSQL login role per database with its own connection limit, row level security available for the customer's own tables, project scoped API keys with an optional IP allow list.
• Workload isolation: applications and functions run as rootless containers with a read only root filesystem, all Linux capabilities dropped, no new privileges, a process limit and a hard memory limit enforced by the kernel.
• Least privilege on the host: the backend service runs as a dedicated unprivileged user, its release directory is read only to the service, and only the data directory is writable.
• Traceability: every control plane mutation is written to an append only audit log with the acting account, the address and the payload.
• Availability: on demand database dumps that the customer can download, and an automatic rollback to the previous container when a deployment fails its health probe.
• Change control: every change to the platform passes typecheck, lint, unit tests and a route contract in continuous integration before it can be deployed, and deployment runs from the pipeline rather than from a workstation.

The customer generally authorises the subprocessors listed below. The operator informs the customer at least four weeks before adding or replacing a subprocessor, and the customer may object on reasoned data protection grounds; if the objection cannot be resolved, either party may terminate the affected service.

The operator assists the customer in fulfilling requests from data subjects, in carrying out a data protection impact assessment and in consultations with a supervisory authority, to the extent the customer cannot do so itself through the dashboard and the API.

Because the customer holds full read access to its own databases and storage, most access and portability requests can be answered by the customer without the operator's involvement.

The operator notifies the customer without undue delay, and in any event within forty eight hours of becoming aware, of a breach of the security of the customer's personal data. The notification describes the nature of the breach, the categories and approximate number of records concerned, the likely consequences and the measures taken.

The operator does not notify a supervisory authority on the customer's behalf; the obligation under Article 33 GDPR remains with the customer as controller.

The operator provides the customer, on request, with the information required to demonstrate compliance with this agreement. An on site inspection is possible after reasonable notice, during business hours, without disrupting the operation of the platform and without exposing other customers' data.

After the main contract ends, the customer has thirty days to export its data. After that period the operator deletes the databases, containers, storage volumes and backups belonging to the account, unless a statutory retention obligation prevents deletion of a specific record.

Deletion of a resource in the dashboard removes it from the platform. Copies inside backups the customer has taken remain until those backups are deleted.