A data processing agreement, usually shortened to DPA, is the contract that GDPR requires whenever one company processes personal data on behalf of another. If a buyer sends customer names, employee records or support tickets to a SaaS vendor, that vendor is acting as a processor, and Article 28 of the regulation sets out, in detail, what the contract between the two parties must contain. This article checks what a DPA actually has to say under GDPR, compares that list against what vendors typically publish, and shows where to find the document: a legal hub, a trust centre, or behind a sales gate that only opens once a deal is signed.
What a data processing agreement actually is
Under GDPR, every organisation handling personal data is either a controller, which decides why and how the data is processed, or a processor, which processes data on the controller's instructions. A SaaS vendor hosting a customer's HR records, an analytics tool processing user events, or a payroll provider running payslips is a processor. A data processing agreement is the written contract between the controller and the processor that records those instructions and sets binding rules for the processor's conduct. It is separate from the main commercial contract and separate from a data protection impact assessment, which is an internal risk exercise the controller runs before processing begins. The DPA exists so that if something goes wrong, both sides can point to exactly what was agreed. For background on how GDPR applies more broadly to vendor relationships, see what GDPR asks of your vendors and what GDPR compliance actually shows.
The Article 28(3) checklist: what the clause must contain
Article 28(3) of GDPR is specific. It does not merely say a contract is needed, it lists the clauses that must be in it. A processor contract missing any of these points is not meeting the regulation's requirements, whatever else it contains.
- Subject matter and duration of the processing
- The nature and purpose of the processing
- The type of personal data and categories of data subjects involved
- The controller's obligations and rights, including the right to issue instructions
- A duty of confidentiality for anyone authorised to process the data
- Appropriate technical and organisational security measures, referencing Article 32
- Conditions for engaging sub-processors, including authorisation and notice
- Assistance to the controller in responding to data subject rights requests
- Assistance with breach notification and data protection impact assessments
- Deletion or return of personal data at the end of the contract
- Information and audit rights so the controller can verify compliance
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 subjects, and the obligations and rights of the controller.
Where vendors actually publish their DPA
In practice a DPA sits in one of three places. Some vendors post it as a static PDF or web page in a legal hub, usually alongside the master subscription agreement and acceptable use policy. Others fold it into a trust centre next to SOC 2 reports, ISO 27001 certificates and subprocessor lists, treating it as another piece of security evidence rather than a legal document on its own. A third group keeps the DPA out of public view entirely and only shares it once a deal reaches procurement or legal review, sometimes gated behind an NDA. None of these placements is wrong under GDPR itself, the regulation does not say where the document must sit, but placement affects how quickly a buyer's legal and procurement teams can do their job. A DPA buried inside a sales process adds days to a deal that a public one would not. Reading a vendor's trust centre in ten minutes usually tells you which of these three patterns applies before you ever speak to sales.
Checking a vendor's DPA against Article 28
The table below maps each Article 28(3) element against what buyers commonly find when they actually open a vendor's published DPA. It is a reasonable first pass, not a substitute for your own legal review. Sub-processor rows deserve particular attention, since checking a vendor's subprocessor list separately from the DPA itself often reveals the list named inside the contract is out of date.
| Article 28(3) element | What to look for | Commonly missing or weak |
|---|---|---|
| Subject matter and duration | A description tied to the main contract term, not a vague reference | A defined duration when the DPA is a standalone template |
| Security measures (Article 32) | A named annex or schedule listing controls | A specific annex, often replaced by a link to a trust centre that can change without notice |
| Sub-processor rules | A named list and a process for notifying new sub-processors | A real objection window with a stated notice period |
| Assistance with data subject rights | A clear timeframe for the processor to respond to controller requests | Any timeframe at all, left to 'reasonable efforts' |
| Deletion or return of data | A stated period after contract termination | A period, left as 'in accordance with applicable law' |
| Audit rights | A direct audit right or an accepted substitute such as a SOC 2 report | A direct audit right, usually replaced entirely by a reference to third-party reports |
How published DPAs typically compare with the Article 28(3) checklist.
Notion's trust centre is a useful example of why a DPA needs to be read as evidence, not taken on faith. It shows a public DPA sitting next to a subprocessor list and a Data Privacy Framework listing that has lapsed rather than an active one, alongside SOC 2 Type II and ISO 27001 statements. The combination is worth looking at directly rather than assuming every document on a trust centre page is current, because the card below renders what is actually published at the time you check it.
Notion · Trust report
Collaboration · Public evidence as of 1 Nov 2026
Framework overview
CertReports state for each framework with public evidence: 11 vendor-stated, 1 expired.
GDPRVendor-statedTrust centre · 1 Nov 2026
HIPAAVendor-statedBadge only, BAA not captured
SOC 2Vendor-statedType II report
PCI DSSVendor-statedTrust centre · 1 Nov 2026
ISO 27001Vendor-statedTrust centre · 1 Nov 2026
ISO 27701Vendor-statedTrust centre · 1 Nov 2026- SOC 3Vendor-statedTrust centre · 1 Nov 2026
ISO 27017Vendor-statedTrust centre · 1 Nov 2026
DPFExpiredListing inactive
3Documents and agreements
Legal and review documents Notion publishes or offers, as of 1 Nov 2026.
- Data processing agreement · Public
- Subprocessor list · Public
- Privacy policy · Public
31Subprocessors
Named on Notion's public subprocessor list, last seen 1 Nov 2026.
Anthropic
AssemblyAI
AWS- BABaseten
- BRBrowserbase
- CSCerebras Systems Inc.
- CICinder
Cloudflare- and 23 more on the evidence page
Signed vs referenced: when a DPA needs a signature
A DPA does not have to be a separately signed PDF to be legally effective. Many vendors incorporate the Article 28 terms by reference inside the main order form or terms of service, with a clause stating that the processing terms published at a given URL form part of the contract. That is legally workable provided the referenced page is stable, version-controlled and does not change without notice to the customer. Some regulated buyers, particularly in financial services, healthcare and the public sector, will still insist on a counter-signed DPA as a standalone document, often because internal audit or a regulator expects one. Where personal data includes health information, a DPA sits alongside, not instead of, the obligations covered by the BAA checklist for US healthcare data under HIPAA.
When buyers need a DPA
Not every vendor relationship needs a DPA. The trigger is whether personal data is processed, not whether money changes hands or the data feels sensitive. Treat the DPA as part of a 30-minute vendor security review rather than a document that only legal ever opens.
- 1
Confirm the data flow
Work out whether the vendor will see, store or process personal data at all. A tool that only receives aggregated, anonymised metrics may not need one.
- 2
Identify the controller and processor roles
In most SaaS relationships the buyer is the controller and the vendor is the processor, but some vendors act as independent controllers for certain data, such as their own product analytics.
- 3
Request the published DPA or current template
Ask for the document before signing the main contract, not after, since procurement has far less leverage to negotiate missing clauses once a deal has moved on.
- 4
Check the Article 28 content
Run the published document against the checklist above and flag anything missing, particularly sub-processor notice periods and audit rights.
- 5
Confirm execution
Decide whether your organisation needs a counter-signed copy or whether incorporation by reference in the main contract is acceptable.
Common gaps in the public record
Vendors that publish a DPA do not always keep every clause current, particularly the sub-processor list referenced inside the agreement and the security annex that is meant to describe Article 32 measures. A DPA that references a trust centre page for its security schedule is only as reliable as that page's update history, which is one reason to check both documents together rather than treating the DPA as the final word on its own.
- 3
- typical DPA locations
- legal hub, trust centre, or sales-gated, pattern seen across vendor pages in the CertReports index on 2026-10-29
- 11
- clauses GDPR Article 28(3) lists
- see the checklist above
- 1
- document doing two jobs
- a DPA has to work as a binding legal contract and as evidence a buyer can audit
People also ask
What is a data processing agreement?
Is data processing agreement mandatory?
Yes, where a processor handles personal data on a controller's instructions, GDPR Article 28 requires a written contract covering specific clauses. There is no size or sector exemption. A vendor processing personal data without those clauses in place is showing no public evidence of meeting that requirement, whatever other security evidence it publishes elsewhere, such as SOC 2 reports or ISO 27001 certificates.
Does a data processing agreement need to be signed?
Not always as a standalone document. GDPR requires the Article 28 terms to be agreed in writing, which can include incorporation by reference inside a main contract or order form, provided the referenced terms are stable and version controlled. Some regulated buyers still insist on a separately counter-signed DPA, often to satisfy an internal audit team or a regulator rather than because GDPR demands that specific format.
When is data processing agreement required?
A DPA is required whenever a vendor processes personal data on a customer's behalf, regardless of data volume or sensitivity. Request it before the main contract is signed, since procurement has far less leverage to negotiate missing clauses afterwards. Check it covers the Article 28 elements, including sub-processor notice periods, security measures and data deletion at contract end.
Solomon Amos · Founder, CertReports
Solomon builds CertReports, the public evidence index for vendor security reviews. PhD in machine learning and cybersecurity, two years embedded at HMRC digital programmes, founder of TapTax. He writes about what registries, trust centres and auditors actually publish, and how buyers can use it before the questionnaire goes out.
Read next on CertReports
You might also like
What Is GDPR Compliance, and What Can a Vendor Actually Show You?
Solomon Amos · 1 Oct 2026 · 9 min read