Processors, sub-processors and the contracts that decide your architecture
Read your own customer data processing agreement before you next choose a vendor, because you have probably already promised things your platform cannot do. A signed DPA commits you to specific breach notice periods, a right for customers to object to new sub-processors, deletion on termination, audit cooperation and a list of technical measures. Each of those is a system requirement. Most are discovered during a security review, after the architecture is fixed.
What does Article 28 actually require in the contract?
A written contract with a defined content list. Article 28(3) requires the processor to act only on documented instructions, to impose confidentiality on staff, to implement Article 32 security measures, to assist with subject rights and with the controller's own security and breach obligations, to delete or return data at the end of the service, and to make available the information needed to demonstrate compliance and allow audits. Sub-processors need prior authorisation, and the same obligations must flow down to them.
The flow-down clause is the one with architectural consequences. Whatever you promise your customers, you must be able to obtain from every vendor beneath you, which means a commitment you accept easily becomes a constraint on every component you can use. A 24 hour breach notification promise is only meetable if your hosting provider, log platform and error tracker will tell you inside that window.
Determine your role honestly before drafting anything. Controller, joint controller and processor carry different duties, and describing yourself as a processor in a contract does not make you one if you decide the purposes. The role question is decided by who determines why the data is processed, not by which party wrote the agreement.
Which clauses turn into engineering requirements?
The ones that promise capability rather than intent. Each row below is a common DPA term and the thing your platform has to be able to do to honour it, which is a more useful reading than the legal summary.
| Clause | What it obliges | Architectural consequence | Common failure |
|---|---|---|---|
| Sub-processor notice and objection | Tell customers before adding one, allow objection | Any vendor must be swappable, and vendor use must be tracked | Engineers add tools on a card, no notice possible |
| Breach notification in a fixed window | Notify the controller within stated hours | Detection and an out of hours decision route | Window shorter than your own vendors give you |
| Assistance with subject requests | Find, export and delete on the controller's instruction | Per-tenant export and delete by subject, on demand | Only bulk export exists, nothing per subject |
| Deletion or return on termination | Remove all copies within a stated period | Tenant deletion covering backups, logs and warehouse | Account disabled, data retained indefinitely |
| Data residency or region commitment | Keep processing within a named region | Region pinning for every dependency, including support access | CDN, error tracker or on-call tooling outside the region |
| Technical and organisational measures annex | Deliver the named controls | Encryption, MFA, logging, testing as stated | Annex copied from a template, controls never verified |
| Audit and information rights | Provide evidence or accept an audit | Evidence generated by the control, not reconstructed | Requests met with a scramble each time |
How do sub-processors get added without anyone noticing?
With a credit card and an SDK. An engineer adds an error tracker to catch a production issue, a growth team adds a session replay tool, someone wires a model provider into a support workflow, and each one becomes a sub-processor receiving personal data with no contract, no notice to customers and no entry in the register. This is the most common source of a breach of your own DPA, and it is almost never malicious.
The control that works is technical rather than procedural. A default deny egress policy in your container platform, with an explicit allowlist of external destinations, means a new vendor cannot receive data until someone changes the policy, and that change is reviewable. Procurement controls catch the vendors with invoices; egress controls catch the ones with free tiers.
Pair it with a published sub-processor page generated from the same allowlist, so the customer-facing list and the enforced list cannot drift. Where they are maintained separately they always diverge, and the direction of the error is that the page is missing entries.
What does a region commitment really cover?
Access, not just storage. If you have promised EU-only processing, then storage in Frankfurt is the easy part and the difficult part is every dependency that touches the data: the CDN and its log destination, the error tracker, the log and metrics platform, the email sender, the support desk, the on-call paging tool and any AI feature calling an external model. Each is a separate region decision and several vendors offer no regional option at all.
Human access is the clause people forget, and the label matters less than the consequence. Your own employee viewing production data from outside the region is not a Chapter V transfer: EDPB Guidelines 05/2021 require disclosure to another controller, joint controller or processor, and Example 5 covers exactly this case. It is still a breach of the residency clause you signed, and it still has to be answered under Articles 24, 25 and 32. Where the engineer sits in a separate entity, an outsourced support provider or a group affiliate, it is a transfer as well and needs a mechanism. Either way it is the finding an experienced reviewer will look for first. If your on-call rota spans continents, your region commitment and your operating model are in conflict and one of them has to change.
Sidecars and agents count too. An APM or profiling agent injected into every pod that ships request attributes to a vendor's regional endpoint is a processor relationship with a real data flow, and it is usually configured once by a platform team and never revisited when a residency commitment is signed later.
What should you check before signing a vendor DPA?
Six things, in this order. Where the sub-processor list is published and whether changes are notified. What the breach notification window is, in hours, to you. Whether deletion on termination covers backups and within what period. Which regions the service can be pinned to, and whether support access is included in that. What transfer mechanism they rely on and for which entities. And whether the technical measures annex is specific enough to be tested or is generic prose.
The revealing question to ask a vendor is what happens to your data in their own backups after you terminate, and how they would evidence it. Vendors who have thought about this give a period and a mechanism. Vendors who have not describe their deletion API, which is a different question.
Then run the same six questions against your own DPA and mark the ones you could not answer for a customer today. That short list is your privacy engineering backlog, ordered by contractual exposure rather than by preference, and it is more useful than any maturity assessment.
Where does this constrain AI features specifically?
At the sub-processor and the training clauses. Sending customer data to an external model provider adds a sub-processor, which triggers your notice obligation, and the provider's terms decide whether inputs may be retained or used to improve their models. Enterprise arrangements commonly offer zero retention and no training on inputs, but that is a contractual setting rather than a default, and the default matters if a team started on a self-service tier.
The architectural implication is that the model provider must be swappable. If a customer objects to a newly added sub-processor and your only option is to remove the feature, the objection right you granted is unusable. Routing model calls through an internal abstraction with more than one supported provider is a compliance requirement as much as an engineering preference.
Log carefully as well. Prompt and response logging is genuinely useful for debugging and quality, and it creates a new store of personal data with a purpose, a basis and a retention rule of its own. It is one of the fastest growing personal data stores in most estates that have added AI features in the last two years.
Common questions
- What must a data processing agreement contain?
- Article 28(3) sets out the required terms: processing only on documented instructions, staff confidentiality, Article 32 security measures, assistance with subject rights and with the controller's security and breach duties, deletion or return of data at the end of the service, information sufficient to demonstrate compliance, and cooperation with audits. Sub-processors require prior authorisation and the same obligations must flow down to them.
- Do you need customer permission to add a sub-processor?
- You need authorisation, which is commonly given in the contract as general written authorisation with a duty to notify changes in advance and allow objection. That makes the notice mechanism an engineering requirement: you must know which vendors receive personal data, be able to announce a change before it happens, and be able to swap the vendor if a customer objects. A vendor you cannot replace makes the objection right unusable.
- How do vendors become sub-processors by accident?
- Through free tiers and SDKs. An error tracker added during an incident, a session replay script added by a growth team, or a model provider wired into a workflow all begin receiving personal data without a contract or a register entry. Procurement controls catch vendors with invoices. The technical control that catches the rest is a default deny egress policy with an explicit allowlist, so a new destination requires a reviewable change.
- Does a data residency promise cover support access?
- It should, and this is where most residency commitments fail. Your own support or reliability engineer viewing production data from outside the committed region is not a Chapter V transfer under EDPB Guidelines 05/2021, but it does breach the residency clause and it still has to be answered under Articles 24, 25 and 32. Where that engineer works for an outsourced support provider or a group affiliate, it is a transfer too. The dependencies people forget break the commitment as well, and because they are separate entities they are genuine transfers: CDN logs, error trackers, log and metrics platforms, paging tools, email senders and injected monitoring agents that ship request attributes to a vendor endpoint.
- What should you ask a vendor about deletion on termination?
- Ask what happens to your data in their backups after termination, over what period, and how they would evidence it. A vendor that has thought this through will give a retention window and a mechanism. One that has not will describe their deletion API instead, which answers a different question. Also confirm whether deletion covers derived copies: logs, analytics, search indexes and any support tooling holding exported records.
