Data Processing Agreement

This Data Processing Agreement ("DPA") forms part of the Terms of Service between SerOps ("Processor") and the customer ("Controller"). It applies where the Processor processes personal data on behalf of the Controller under the GDPR or equivalent laws.

1. Subject matter and duration

The Processor tests the restorability of the Controller's PostgreSQL backups. This processing lasts for the term of the agreement.

2. Nature and purpose

• Hosted runs: the Processor downloads the newest backup from the Controller's storage, restores it into a temporary, isolated database, runs aggregate checks, and deletes the temporary environment at the end of the run.
• Results: results contain metadata (table names, row counts, checksums, timings), never row data.

3. Categories of data and data subjects

Whatever personal data the Controller's backups contain (customers, users, employees). It is processed only transiently, inside a run, and never stored by the Processor beyond the run.

4. Processor obligations

The Processor shall:

• process personal data only on documented instructions (configuring a target and its checks is such an instruction);
• ensure its personnel are bound by confidentiality;
• implement the technical and organisational measures in Annex 1;
• assist with data-subject requests and with security and impact assessments, as far as possible given that it doesn't store backup contents;
• notify personal-data breaches without undue delay, and in any case within 48 hours of becoming aware;
• delete or return personal data at the end of the agreement.

5. Sub-processors

The Controller authorises the sub-processors listed here. The Processor gives 30 days' notice of changes, during which the Controller may object. Sub-processors are bound by equivalent obligations.

6. International transfers

Backup contents are processed only in the EU (Scaleway, France). Any transfer of other personal data outside the EEA uses Standard Contractual Clauses.

7. Audits

The Processor makes available the information needed to demonstrate compliance: its security page, signed run evidence, and a summary of external security reviews. On-site audits may be agreed, with reasonable notice, at the Controller's expense.

Annex 1 — Technical and organisational measures

• A dedicated runner cluster, a namespace per run, the gVisor sandbox runtime enforced by an admission policy, the restricted Pod Security Standard, non-root read-only containers without capabilities.
• Deny-all network policies; egress only to DNS, the Controller's bucket hostname and the Processor's API.
• Temporary environments deleted at the end of every run; an orphan sweeper deletes anything older than its deadline plus 15 minutes.
• Read-only, prefix-scoped storage credentials, encrypted at rest with a key hierarchy whose master key is held in a secret manager. They are decryptable only by the orchestrator and never readable through the application.
• Results restricted by schema to metadata; secrets scrubbed from logs; result signatures and countersignatures.
• Encryption in transit (TLS) and at rest (database, object storage, Kubernetes Secrets).
• Least-privilege access, an audit log, and key rotation procedures.

Signature blocks: [to be completed].