Data Processing Agreement
Definition
Data Processing Agreement
A data processing agreement is the contract required whenever one organisation processes personal data for another, setting out the subject matter, duration, purpose and each party’s duties. It is a legal requirement, not an option where personal data is involved.
In outsourcing terms the client is almost always the controller and the provider the processor — the controller decides why and how personal data is processed, and the processor acts on instructions and nothing more.
The agreement can be a standalone document or a schedule to the services contract — its form matters less than its content, which is prescribed rather than negotiable in its essentials.
Where it goes wrong is usually scope creep — a provider that starts deciding what data to collect or how long to keep it has stopped being a processor, and the agreement no longer describes what is happening.
Key takeaways
- A written data processing agreement (DPA) is mandatory wherever a processor handles personal data.
- Subject matter, duration, nature, purpose, data types and data subjects must all be stated.
- The processor acts only on documented instructions from the controller.
- A processor that starts determining purposes becomes a controller in its own right.
How it works
The controller sets out what processing is permitted, and the processor commits to acting only on instruction, securing the data, restricting access, assisting with data subject rights, and deleting or returning everything at the end.
The requirement itself is unambiguous. The UK regulator states that “Whenever a controller uses a processor to process personal data on their behalf, a written contract needs to be in place between the parties”.
The contents are prescribed too. The contract must set out “the subject matter and duration of the processing; the nature and purpose of the processing; the type of personal data and categories of data subject; and the controller’s obligations and rights”.
| Required element | What it fixes | Common weakness |
|---|---|---|
| Subject matter and duration | What is processed and for how long | Copied from a template, not the service |
| Nature and purpose | Why the processing happens | Described too broadly to be meaningful |
| Data types and data subjects | Whose data and which categories | Omits special category data entirely |
| Security measures | The controls applied | Cross-references a policy that can change |
| Sub-processor terms | Who else may be involved | General authorisation with no notice period |
| Deletion or return | What happens at the end | Choice left to the processor, not the controller |
Statutory audit rights sit alongside all of this. The processor must allow for and contribute to “audits, including inspections, conducted by the controller or another auditor mandated by the controller”.
Examples
Data processing agreements are strongest when they describe the actual service being delivered, and weakest when they are generic. The four cases below show what that difference looks like.
A bank annexes a processing agreement to each statement of work, describing that specific service’s data types and retention. Audits are straightforward because the paperwork matches reality.
A retailer uses one group-wide template across eleven providers. Three of them process special category data that the template never mentions.
An insurer requires thirty days’ notice of any new sub-processor, with a right to object. It exercises the right once, and the provider proposes an alternative.
A healthcare buyer lets its provider choose between deletion and return at exit. The provider retains records for its own analytics, and the choice was never the controller’s to give away.
Related terms
Data protection obligations arrive through statute, contract and certification, and the layers are easily confused with one another. The entries below separate the regimes from the instruments that implement them.
- GDPR: the regulation that makes the agreement mandatory in the first place.
- GDPR outsourcing: how the regime applies specifically to outsourced delivery.
- CCPA outsourcing: the California regime, with its own service-provider contract terms.
- PDPA outsourcing: the Singapore and Thai regimes governing much Asian delivery.
- LGPD outsourcing: the Brazilian regime relevant to Latin American delivery.
- Philippine data privacy: the regime covering the largest offshore delivery market.
- ISO 27001 outsourcing: certification that evidences the security measures the agreement requires.
FAQ
How is a DPA different from a sub-processor clause?
The data processing agreement is the whole instrument between controller and processor. The sub-processor clause is one provision inside it, governing the processor’s own suppliers.
Is a data processing agreement always required?
Wherever a processor handles personal data on a controller’s behalf, yes. The obligation follows the processing, not the size or formality of the arrangement.
Can it be a schedule rather than a separate contract?
Yes. A schedule to the services agreement is perfectly valid provided it contains everything the law requires.
What makes a processor become a controller?
Determining the purposes or essential means of processing. A provider deciding what to collect or how long to keep it has crossed that line.
Who chooses between deletion and return at the end?
The controller. A clause leaving that choice to the processor gets the statutory position backwards.
Does one template work across all providers?
Rarely. Data types, special categories and retention differ by service, and generic templates fail exactly where scrutiny lands.
Compare providers who can evidence Article 28 compliance in the Outsource Accelerator directory.
Independent
