Data Sovereignty / Source date:

Data Processing Agreements Become Standard Practice

Formal DPAs turned vague vendor promises into enforceable, auditable obligations.

Illustrative scene of a data processing agreement's security, sub-processor, incident and deletion schedules beside a supplier register.

For most of the outsourcing boom, the contract that governed personal data was a schedule nobody read. Service levels, pricing and termination were negotiated line by line. Data protection appeared as a single clause promising that the supplier would comply with applicable law — a sentence that allocated no obligations, specified no controls and survived no audit. By the end of the decade that had started to change, and the change was driven less by conscience than by a mechanism: European law made the customer permanently responsible for what its suppliers did, and the only way to discharge that responsibility was in writing.

Under the European framework, the organization deciding why and how personal data is processed is the controller, and the supplier acting on instructions is the processor. That distinction has a consequence most buyers found unwelcome: responsibility to data subjects and regulators stays with the controller regardless of who performs the work. You can outsource payroll, service desk, collections or claims handling. You cannot outsource accountability for what happens to the data those functions touch. The law therefore required the relationship to be documented — the processor acting only on the controller's instructions, with appropriate technical and organisational security measures. In practice, through most of the decade, that requirement was met with a paragraph. The paragraph did not say which measures, who verified them, what happened after an incident, or what the supplier would do when its own subcontractor lost a laptop.

The Cross-Border Layer

The second driver was transfer law. Offshore delivery models put personal data in countries without an adequacy finding, which required a lawful transfer mechanism, and the machinery for that matured in this period. In February 2010 the European Commission adopted Decision 2010/87/EU on standard contractual clauses for transfers of personal data to processors established in third countries, replacing the 2001 version. The update mattered for outsourcing specifically because it addressed what the earlier clauses had fudged: the chain of sub-processors behind a single service. Onward transfers to subcontractors were brought inside the framework, with the data importer remaining liable for its subcontractors' performance and supervisory authorities given audit rights. That was the first widely used instrument that acknowledged how outsourcing actually works — a prime contractor with delivery centres, shared service providers, infrastructure suppliers and specialist subcontractors, each handling the same records. For multinational groups moving data internally rather than to third parties, binding corporate rules offered an alternative. The Article 29 Working Party had set out the concept in WP74, adopted in June 2003, with later papers adding an application procedure and a model checklist. The framework was demanding — approval required coordination across multiple national authorities, and the Working Party noted bluntly that for loose conglomerates, binding corporate rules are very unlikely to be a suitable tool — but it gave large groups a route that did not depend on signing clauses with themselves.

What a Real Data Processing Agreement Contains

The shift from clause to agreement was a shift from assertion to specification. A usable agreement answers questions the one-liner never did. Scope and purpose. Which categories of data, whose data, for what processing, for how long. Without this, "only on documented instructions" is unenforceable because the instructions do not exist. Security measures, named. Encryption in transit and at rest, access control, logging, segregation, personnel vetting, secure development. Specific enough to test, not a reference to the supplier's general policy. Sub-processors. A current list, notification before changes, a right to object, and flow-down of equivalent obligations. This is the clause most often missing and most often the source of the actual exposure. Incident handling. Notification within a defined and short period, minimum content of that notification, cooperation duties, and who communicates with regulators and data subjects. Audit rights that can be exercised. A right to audit that requires twelve months' notice and mutual agreement on scope is decorative. Recognised third-party reports plus a targeted right after an incident work better than an unusable general right. Return and deletion. What happens at termination, in what format, on what timetable, with what certification — including backups, which are where data quietly survives deletion. Location. Named processing and storage countries, restrictions on movement, and the transfer mechanism relied upon.

Make processor obligations testableThe agreement areas described in the article. This summary is not a current legal template and needs jurisdiction-specific review.
Agreement areaWhat to specify
Scope and purposeData categories, people concerned, processing purpose and duration
SecurityNamed technical and organisational measures that can be tested
Sub-processorsCurrent list, change notice, objection rights and equivalent obligations
IncidentsNotification timing, required information and cooperation duties
AuditEvidence and targeted rights that can actually be exercised
ExitReturn format, deletion timetable and backup treatment
LocationProcessing and storage countries and applicable transfer mechanism

Qualitative summary of this article's source text, not a measured outcome or performance estimate.

Negotiating These Agreements Well

  • Start from your paper, not theirs. Supplier templates allocate risk to the supplier's advantage, and the differences are in the detail of sub-processing and incident timing.
  • Make sub-processor change a notification with a right to object. Silent substitution of a subcontractor is how data ends up somewhere you never approved.
  • Set incident notification in hours, not "without undue delay". Regulatory clocks are short. A supplier that learns on Monday and tells you on Friday has consumed your deadline.
  • Tie the agreement to the service description. Data protection obligations drift out of alignment when the service changes and the schedule does not.
  • Check the transfer mechanism is current. Clauses signed years ago may reference superseded decisions. This is a periodic maintenance task, not a one-off.
  • Test the audit clause once. Exercise it early in the relationship. A right never used is a right you do not know you have.
  • Cover deletion of backups explicitly. Ask for the retention period of backups and certification of eventual destruction, not just deletion from production.
  • Keep the register current. Knowing which suppliers process which data, in which countries, under which mechanism, is the prerequisite for everything else — and for most regulated sectors, it is now itself a requirement.

Why This Still Matters More Each Year

The modern successor framework made these agreements mandatory in substance, not just in form, and raised the penalties for getting them wrong. It also made the register of processors a supervisory expectation rather than good practice — a direction now echoed in operational resilience regimes that require financial firms to maintain a register of contractual arrangements with third-party providers. The current test case is AI. When a supplier introduces an AI capability into a service you already buy, the processing changes: new sub-processors, new locations, new retention behaviour, and in some cases the possibility that your data contributes to model training. If your agreement does not require notification of material changes in processing, you will find out afterwards. The discipline that emerged around 2009 — write down who does what to which data, where, and what happens when it goes wrong — was never about paperwork. It was the only mechanism that makes accountability enforceable when the work is done by someone else.

Common Questions

What is a data processing agreement?

A contract between a data controller and a processor specifying the scope and purpose of processing, required security measures, sub-processor rules, incident notification, audit rights, data location and return or deletion at termination.

Can an organization outsource responsibility for personal data?

No. The controller remains accountable to regulators and data subjects for processing carried out by its suppliers. The agreement allocates obligations between the parties but does not transfer accountability.

What did the 2010 standard contractual clauses change?

Commission Decision 2010/87/EU replaced the 2001 processor clauses and addressed onward transfers to sub-processors, keeping the data importer liable for subcontractor performance and providing supervisory authority audit rights.

What are binding corporate rules?

An internal transfer framework for multinational groups, set out by the Article 29 Working Party from 2003, approved by data protection authorities and suited to closely integrated corporate groups rather than loose conglomerates.


DPA Template Review — Outpace rewrites your processor agreements so sub-processing, incident timing, deletion and data location are specified rather than asserted, and builds the supplier register that makes them enforceable.

Continue reading

Talk to OPS

Start with the operating problem.