Data Processing Addendum

1. Roles

For Customer Content routed through the Service, you are the Controller and Prismux is the Processor. For account, billing and security data described in the Privacy Notice, Prismux is a Controller in its own right.

Model vendors and hosting substrates that serve your requests are Sub-processors. The complete list is the catalogue — published as a single document precisely so the legal list and the routing filter cannot drift apart.

2. Processing instructions

We process Customer Content only to perform the Service: to translate between wire protocols, to select an eligible endpoint according to your policy, to relay the request and response, to count tokens for billing, and — where you enable it — to encrypt the exchange under your key.

We do not process Customer Content for any other purpose. Not for model training, not for service improvement, not for analytics, not for routine security classification. Where an instruction from you would infringe applicable data protection law, we will inform you rather than act on it.

One exception, stated rather than buried: at the open and mdr tiers we retain an encrypted copy for the contracted window solely to investigate an abuse report, a vendor request or a legal demand. Access requires documented cause and two authorised people; at zdr_escrow it additionally requires a second key-share holder who is not us. Every access — attempted, refused or granted — is written into the Controller's own receipt chain with its reason and outcome, so the processing is auditable by the Controller without our cooperation. At zdr_absolute no such copy exists and this exception does not apply.

2.1 The policy envelope as an instruction

Your policy envelope — retention floor, residency, fallback rung — is a processing instruction expressed in a form the system enforces at the moment of processing rather than a term we undertake to observe. An endpoint that would violate it is not eligible; if none remains, the request is refused and the content is not transferred at all.

3. Security measures

Technical and organisational measures, described in full on the Trust page. In summary:

• TLS 1.3 in transit to clients and to every upstream; no plaintext hop.
• Content held in per-request memory and written to persistent storage only as a sealed envelope under the Controller's contracted retention tier — never in plaintext, on any path — enforced by an automated build guard rather than by review.
• Optional vault: AES-256-GCM with envelope encryption under a Controller-held KMS key. Prismux holds no unwrapping key. Customer-bucket mode leaves the ciphertext outside our infrastructure entirely.
• Append-only, kernel-immutable receipt log for the audit record; no content.
• Hash chaining of every record, verifiable offline, plus an Ed25519 signature over each record's own hash. The router prints its public key at start-up as a line you pin, every receipt names the signing_key_id that signed it, and prism verify --keys checks the signatures against the key you pinned. A rotation history is not yet published; today there is one key and you read it from the process you are talking to.
• Least-privilege access with MFA; production access audited. Support personnel cannot read Customer Content because no readable copy exists.

4. Sub-processors

You give general authorisation for the Sub-processors listed in the catalogue and on the Trust page. We will give 30 days' notice before adding one, on the catalogue page and by email to administrators. You may object on reasonable data-protection grounds; if we cannot accommodate the objection you may terminate the affected portion of the Service without penalty.

Two properties worth noting, because they are unusual:

• A policy restricting posture or residency also restricts your Sub-processor set, enforced automatically. A Controller who permits only contractual-ZDR EU endpoints has, by that setting, excluded every other Sub-processor.
• Each receipt names the Sub-processor that actually processed that request, so the Article 30 record is generated rather than asserted.

5. International transfers

The place of processing is the jurisdiction of the endpoint that serves the request, and the Controller sets that with the residency directive. Where a transfer outside the EEA or UK occurs, Standard Contractual Clauses (Module Two, Controller-to-Processor) apply, with the UK Addendum where relevant.

A transfer impact assessment is materially easier here than usual: the set of possible destinations is enumerated in the catalogue with jurisdictions attached, and the actual destinations are enumerated in your own receipts.

6. Assistance to the Controller

• Data subject requests. We will assist within the limits of what we hold, which is defined by the contracted tier. At zdr_absolute we hold no content to search and will say so rather than perform a search that cannot exist.
• DPIAs and prior consultation. We will provide the architecture documentation, posture evidence and Sub-processor detail needed.
• Records of processing. Generated from the receipt log and exportable at any time.

7. Personal data breach

We will notify you without undue delay and within 72 hours of becoming aware, with the nature of the breach, the categories and approximate number of records concerned, likely consequences and measures taken.

Scoping is a query rather than an investigation: receipt records carry an interval (t0, t1) rather than a single timestamp, specifically so that “which requests were in flight concurrently on endpoint X between T1 and T2” can be answered. A point-in-time log cannot express concurrency, which is exactly what makes an incident unscopeable.

8. Audit

You may audit our compliance once per year, or after a breach, on reasonable notice — by reviewing our documentation and any third-party attestation, and by submitting a security questionnaire.

Independently of that, you can verify our billing and routing conduct at any time and without our involvement: run the open-source verifier against your own receipt export and the published signing key. That is a stronger audit right than most DPAs grant, and it costs us nothing to give because the record is designed to be checked.

9. Deletion and return

On termination we will delete or return Customer Content at your election. In practice: in off mode there is nothing to delete or return; in customer_bucket mode it is already in your possession; in managed mode we delete the ciphertext, which we could not read in any case. Receipt metadata is retained for the period you configure, or as required by law for billing records.

10. Annexes

Annex I — parties, categories of data subject, categories of personal data, and processing operations. To be completed on incorporation with the contracting entity's details.

Annex II — technical and organisational measures. Section 3 above, together with the Trust page, forms this annex.

Annex III — Sub-processors. The catalogue, as at the date of the agreement, with the notice mechanism in section 4.