What Is a Data Processing Agreement? – Definition and How It Works
Learn what a DPA is, which clauses it must contain, and when a data collection vendor relationship requires one.
A data processing agreement is a contract between a controller — the party deciding why and how personal data is processed — and a processor acting on its instructions. Under GDPR it is mandatory whenever a processor handles personal data. This page is a general explanation, not legal advice.
1. Controller and Processor
The distinction determines who needs what.
| Role | Decides | Example |
|---|---|---|
| Controller | Purposes and means of processing | The business collecting the data |
| Processor | Nothing; acts on instructions | A hosting provider, a scraping service |
| Joint controllers | Purposes together | Two businesses running a shared programme |
Misclassifying the roles is the most consequential mistake, because obligations differ substantially and the paperwork required follows from the classification rather than from the commercial framing.
2. What a DPA Must Contain
GDPR sets out required terms. A compliant agreement covers:
- Subject matter and duration of the processing.
- Nature and purpose of the processing.
- Types of personal data and categories of data subjects.
- The controller's obligations and rights.
- Processing only on documented instructions.
- Confidentiality obligations on personnel.
- Security measures, appropriate to the risk.
- Sub-processor rules — authorisation, and flow-down of equivalent terms.
- Assistance with data-subject rights.
- Assistance with breach notification and impact assessments.
- Deletion or return of data at the end of the relationship.
- Audit and information rights for the controller.
3. When Data Collection Needs One
Not every collection arrangement involves personal data, and that is the first question rather than the last.
No DPA needed — collecting prices, product specifications, aggregate ratings, weather data, or public company financials. No personal data, no processor relationship over personal data.
A DPA is needed — where a vendor collects or processes data about identifiable people on your instructions: named contacts, review text with author names, profile data, or anything whose combination re-identifies a person.
Roles need care — where a vendor decides what to collect and sells the result to many customers, it may be a controller in its own right rather than your processor, which changes the instrument required.
4. International Transfers
Where personal data moves outside the EEA, a DPA alone is not sufficient. A transfer mechanism is also required — an adequacy decision, standard contractual clauses, or another recognised route — usually with a transfer impact assessment.
This is directly relevant to distributed collection, because proxy exits and processing nodes in multiple countries mean personal data may be crossing borders as a side effect of the architecture rather than as a deliberate decision.
Worth checking against your own infrastructure rather than assuming.
5. Sub-processors Are the Practical Weak Point
Vendors use vendors. A scraping service may use a proxy provider, a cloud host, and a queue service — each a sub-processor.
The chain must carry equivalent obligations end to end, and the controller retains responsibility for the whole of it. Two things to insist on: a current list of sub-processors, and notice before it changes with a right to object.
An unlisted sub-processor is the gap through which a compliance programme quietly fails.
6. Reviewing a Vendor's Standard DPA
Most vendors offer a standard document. The clauses worth reading closely:
- Scope. Does it actually cover the processing you are buying?
- Sub-processor notice. Notification, and a real right to object.
- Security commitments. Specific measures, or unenforceable generalities?
- Deletion. A defined period, and backups addressed.
- Audit rights. A meaningful mechanism, or only a certificate?
- Breach notification. A defined timeframe you can meet your own deadline with.
- Transfer mechanism. Named, current, and applicable.
- Liability. Caps that bear some relation to the risk.
Breach notification timing is the one most often too loose: a vendor promising notice "without undue delay" with no number leaves you unable to meet your own regulatory deadline.
7. Beyond Compliance
A DPA is also an operational document. It records what data a vendor holds, why, for how long, where, and who else touches it — which is exactly the inventory needed to answer a data-subject request or to reason about a breach.
Treating it as a filing exercise wastes that. Treating it as documentation of your actual data flows makes it useful.
8. Summary
A data processing agreement governs a processor handling personal data on a controller's instructions, and GDPR makes it mandatory with a specific set of required terms covering scope, instructions, security, sub-processors, rights assistance, deletion, and audit.
Establish first whether personal data is involved at all and whether the vendor is genuinely a processor, check that a transfer mechanism covers cross-border flows your architecture creates incidentally, and scrutinise sub-processor notice and breach-notification timing — the two clauses most likely to leave a real gap.