Data Processing Agreement

Data Processing Agreement

Draft pending counsel review — not legal advice, not in force until approved by the owner

This page summarises the Data Processing Agreement template (v0.1, 2026-10-20) from the operator’s trust documents. It is the document a customer’s lawyer reads before asking for the signed DPA; the signed instrument is produced from it (source: ops/docs/trust/DPA-subprocessors.md, header). Reviewed by: (pending) · Reviewed on: (pending).

1. Roles

• Customer: controller (or processor for its own customers).
• Operator ([[REGISTERED-ENTITY]]): processor for the personal data described below.
• Sub-processors: listed in the sub-processors register; each is engaged under a written contract with data-protection terms equivalent to Article 28(3) GDPR (source: ibid., §1).

No service is offered that makes the operator a controller of customer content. Account email and billing records are controller data for the customer’s own account administration, not content processed on the customer’s behalf (source: ibid., §1).

2. Article 28(3) terms

The terms a signed DPA carries, from the template (source: ibid., §3):

1. Subject matter and duration: inference routing for the term of the customer agreement, plus the deletion window in the retention schedule.
2. Nature and purpose: authenticating the caller, routing the request to an upstream model, metering usage, preventing abuse.
3. Data categories and data subjects: the categories in the privacy policy §2; the customer’s end users and personnel.
4. Controller instructions: process only on documented instructions, including transfers, unless required by law (then notice first, where lawful).
5. Confidentiality: personnel authorised to process are bound by confidentiality; access is limited to the operator and the tailnet.
6. Security (Article 32): the measures below.
7. Sub-processors: authorisation, the register, and 30 days’ notice of a change with a right to object.
8. Assistance: help with data-subject requests, DPIAs and prior consultations, taking into account the nature of the processing.
9. Breach notification: notify the controller without undue delay and within 48 hours of becoming aware, with the facts then known. The 72-hour authority clock belongs to the controller.
10. Deletion or return: at the end of the agreement, delete or return content and metadata except records a law requires be kept (accounting: six years), and certify deletion on request.
11. Audit: answer a security questionnaire annually and allow an audit on reasonable notice, subject to confidentiality; the current evidence set is the status page, the sub-processor register, the retention schedule and the security policy.
12. International transfers: see below.

3. Article 32 security measures

From the template (source: ibid., §7): TLS at the edge for every public host; operator surfaces bind loopback or the tailnet only; API keys issued per customer and revocable; the operator console not reachable from the public internet; host firewalling, a deterministic deployment gate, and an append-only harness ledger for gate verdicts; metrics and logs bounded by the retention schedule with no content scraped into the observability stack. Gaps stated in the source, not hidden here: mail is backed up encrypted off-host, but the acumen database has no scheduled off-host backup (source: ibid., §7).

4. Sub-processors

The register, its change log and the transfer mechanism are on the sub-processors page.

5. International transfers

Service data is stored in Germany. Where a sub-processor is in the US, the transfer relies on the EU Standard Contractual Clauses and, where the recipient is certified, the EU-US Data Privacy Framework. The DPF’s legal basis was under political review during 2026; the Commission’s published position is that it remains valid, but a transfer story that depends on the DPF alone is fragile. SCCs are the primary mechanism, not the fallback (source: ibid., §6).

6. Template status

Per the source, this template is not yet contract-ready. Open actions (source: ibid., §8): conclude Hetzner’s order-processing contract; catalogue upstream inference providers (entity, region, DPA/terms link, whether content is retained for training) and publish the customer-facing list; name the payment processor once billing exists; and turn this summary into the signable instrument. Nothing on this page claims the template has been reviewed or signed.

Questions: security@tcp.systems (source: ibid., §9).