Who is responsible for putting a DPA in place — the controller or the processor?

Both. Article 28(3) obliges the controller to only use processors bound by a compliant contract, and processors have their own direct obligations under the same article. In practice the processor usually supplies the template, because they need one consistent agreement across thousands of customers rather than negotiating each one. That does not shift the risk: if a vendor's standard DPA omits required terms, the controller is still non-compliant for having engaged them on it. Read what you sign rather than assuming a published DPA is complete.

GDPR Data Processing Agreement: The Article 28 Clause Checklist

Q: What is the data processing agreement for GDPR?

A GDPR data processing agreement (DPA) is the written contract Article 28 requires between a controller and any processor handling personal data on the controller's behalf. It has to state the subject matter, duration, nature and purpose of the processing, the types of personal data, the categories of data subjects, and the controller's rights and obligations. It then has to impose eight specific obligations on the processor, covering documented instructions, confidentiality, security, sub-processors, assistance with data subject rights, assistance with breach and DPIA duties, deletion or return of the data, and audit rights. Without one, both parties are non-compliant — the obligation is not just on the vendor.

Q: Is a DPA the same as an NDA?

No, and one does not substitute for the other. An NDA is a confidentiality agreement: it stops a party disclosing your information to outsiders. A DPA is a data protection agreement: it constrains what the party may do with personal data internally, requires specific security measures, restricts sub-processing, mandates deletion at contract end, and grants you audit rights. An NDA is silent on all of that. Confidentiality is one clause inside a DPA, not a replacement for it. You commonly need both, and many vendors bundle the DPA as an annex to the main services agreement.

Q: Does GDPR apply in the USA?

The GDPR is EU law, so it does not apply to US companies simply for being US companies. It applies to them extraterritorially under Article 3(2) when they offer goods or services to people in the EU, or monitor the behaviour of people in the EU — which includes analytics and behavioural advertising. A US SaaS vendor processing EU personal data on behalf of a customer is a processor under GDPR and needs a DPA, regardless of where its servers sit. The DPA will normally also need Standard Contractual Clauses attached, because sending EU data to the US is a restricted transfer.

Q: What are the 7 processing principles of GDPR?

Article 5 sets out lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. A DPA is one of the main instruments through which a controller demonstrates accountability, because it evidences that processing by third parties is governed, purpose-limited, and secured. A well-drafted DPA maps to the principles directly: documented instructions serve purpose limitation, deletion-at-termination serves storage limitation, and Article 32 measures serve integrity and confidentiality.

Q: Do I need a DPA with every vendor?

You need one with every vendor that processes personal data on your behalf — which is far more vendors than most teams assume. Cloud hosting, CRM, email tools, support desks, analytics, error monitoring, payroll, recruiting platforms, and AI services all typically qualify. You do not need a DPA with a party that acts as an independent controller, such as your bank or your auditor, because they determine their own purposes. Joint controllers need an Article 26 arrangement instead. The classification, not the vendor's size, decides which document applies.

A GDPR data processing agreement is the contract that has to exist before anyone else touches personal data on your behalf. It is also the single most common gap we find in an otherwise credible privacy program, because teams treat it as a procurement formality rather than a control.

This is what Article 28 actually requires, how a DPA differs from the agreements it gets confused with, and which clauses vendors leave out when nobody reads carefully.

What a DPA Is, in One Paragraph

Article 28(3) of the GDPR says that processing by a processor must be governed by a binding written contract. That contract is what everyone calls a data processing agreement.

It exists to convert your instructions into enforceable obligations. Without it, a vendor holding your customers' personal data is operating under nothing more specific than a services agreement and good intentions — and you, the controller, are the one out of compliance for engaging them that way.

When You Need One (and When You Need Something Else)

The document you need depends on the relationship, not the size of the vendor.

Relationship	Who decides purpose and means	Document required
Controller → Processor	You do; they act on instructions	DPA (Article 28)
Joint controllers	Both, together	Article 26 arrangement
Controller → Controller	Each independently	Data sharing agreement (no Article 28 DPA)
Processor → Sub-processor	Controller, flowed down	Back-to-back DPA

Practical test: if the vendor may use the data for their own purposes — improving their own models, building their own product analytics, marketing to your users — they are not acting solely on your instructions. Either the contract has to shut that down, or they are a separate controller and a DPA is the wrong instrument.

That distinction is where AI vendors deserve close reading. A clause permitting use of customer data for model training is a purpose the vendor determines, not one you instructed.

The Article 28 Clause Checklist

A compliant DPA needs both a description block and eight obligations. Use this as a review checklist against any DPA you are handed.

The description block

Article 28(3) requires the contract to set out:

The subject matter of the processing
The duration of the processing
The nature and purpose of the processing
The type of personal data involved
The categories of data subjects
The obligations and rights of the controller

These usually live in an annex. An annex left blank, or filled with "as described in the Agreement," fails the requirement. Regulators have called this out specifically: the description must be sufficiently specific to define the boundary of lawful processing.

The eight processor obligations

1. Process only on documented instructions Including for transfers to third countries, unless required by law — in which case the processor must tell you first, unless that law prohibits notice.

2. Ensure personnel are bound by confidentiality Contractual or statutory. This is the one clause an NDA genuinely overlaps with.

3. Implement Article 32 security measures Pseudonymisation and encryption, confidentiality/integrity/availability/resilience, restoration after incident, and regular testing of effectiveness. A good DPA annexes the actual technical and organisational measures. A weak one says "industry standard security," which is unenforceable.

4. Respect the conditions for engaging sub-processors Either specific prior authorisation or general written authorisation with advance notice of changes and a right to object. Sub-processors must be bound by the same obligations, back to back.

5. Assist with data subject rights Taking into account the nature of processing, the processor must help you respond to access, erasure, rectification, portability, restriction, and objection requests. Vague "reasonable assistance" language becomes a real problem on day 25 of a 30-day clock.

6. Assist with Articles 32–36 Security, breach notification to the authority, breach communication to individuals, DPIAs, and prior consultation. Push for a defined breach notification window here. "Without undue delay" is the statutory floor; your own 72-hour clock starts when you become aware, so a vendor taking five days to tell you has already spent your budget.

7. Delete or return the data at the end of the contract At the controller's choice, and delete existing copies unless law requires retention. Check whether backups are addressed. Most DPAs are silent, and silence means an unbounded retention tail.

8. Make available information to demonstrate compliance, and allow audits Including inspections conducted by you or an auditor you mandate.

Plus one duty that sits outside the list: the processor must immediately inform you if an instruction infringes the GDPR.

What Vendors Actually Leave Out

Reviewing a few hundred vendor DPAs, the same five weaknesses recur:

Audit rights reduced to a certificate. Many DPAs replace inspection rights with "processor will provide its most recent SOC 2 report." That is often a reasonable commercial compromise, and for a large cloud provider it is the only realistic answer. But confirm the report's scope covers the services and systems you actually use — a SOC 2 report scoped to a different product line proves nothing about yours.

Sub-processor objection rights with no remedy. You may object, the vendor may proceed anyway, and your only recourse is termination — sometimes without refund. Negotiate the exit terms, since the objection right alone is decorative.

Undefined breach notification windows. See obligation 6. Ask for a number.

Security measures by reference to a webpage. A URL the vendor can edit unilaterally is not a contractual commitment. Ask for the measures as a dated annex, with change notification.

Missing or stale transfer terms. If EU data reaches a third country, Standard Contractual Clauses must be incorporated with the annexes completed. Pre-2021 SCCs are no longer valid; a DPA still referencing them has not been maintained.

DPA vs NDA vs BAA

These get conflated constantly, and they do different jobs.

An NDA stops disclosure to outsiders. It says nothing about internal use, security controls, sub-processing, deletion, or audits.
A DPA governs how personal data may be handled on your behalf under GDPR.
A BAA (Business Associate Agreement) is the HIPAA analogue for protected health information in the US.

If you process EU health data as a US-facing business, you may need the substance of both a DPA and a BAA. They can be combined into one agreement if it carries every required element from each — but a standard DPA template does not satisfy BAA requirements, and the reverse is equally untrue. We cover the combined-template approach in GDPR HIPAA compliance.

Not because a company is American — because of what it does.

Article 3(2) reaches organisations outside the EU that offer goods or services to people in the EU, or monitor their behaviour. A US SaaS vendor whose customer uploads EU employee data is processing EU personal data and needs a DPA with that customer, wherever its servers are.

This is why a Data Processing Agreement template for USA use is not a different legal instrument. It is the same Article 28 contract, with two additions that matter more for US recipients:

Standard Contractual Clauses, because EU-to-US is a restricted transfer — unless the recipient is certified under the EU-US Data Privacy Framework, in which case adequacy covers it.
A Transfer Impact Assessment documenting whether US surveillance law undermines the safeguards, and what supplementary measures (encryption with customer-held keys, for example) address the gap.

Signing SCCs without the transfer assessment behind them is the post-Schrems II equivalent of an unrecorded lawful basis: the paperwork exists, the reasoning does not.

On Templates, Samples, and PDFs

Searching for a GDPR data processing agreement template, sample, or PDF is a reasonable starting point, and the official-adjacent versions are genuinely good starting drafts. The European Commission's standard contractual clauses include a controller-processor module, and several supervisory authorities publish model clauses.

Use a template to check completeness. Do not use it to skip the two decisions it cannot make for you:

The annexes. The description of processing, the sub-processor list, and the technical and organisational measures are the parts that describe your arrangement. They are also the parts templates leave blank, and the parts regulators read first.
The classification. A template assumes you are the controller and they are the processor. If that is wrong, the entire document is the wrong instrument.

A signed template with empty annexes is not better than no DPA. It is the same gap with a false sense of coverage.

Operationalising It

The contract is step one. The program around it:

Keep a processor register. Every vendor, its classification, DPA status and date, transfer mechanism, and sub-processor list. This feeds your Record of Processing Activities directly.
Gate procurement. No personal data flows before the DPA is signed. The gate has to sit with whoever provisions access, not with legal, or it will be routed around.
Watch sub-processor notices. Vendors email these and everyone ignores them. Someone has to own the objection window.
Re-paper on change. New processing purpose, new data category, new region — the annexes need updating. A DPA describing a 2023 arrangement does not cover a 2026 one.
Diary the exit. Deletion or return at termination is an obligation you have to actually exercise and evidence.

For the full program context, see the GDPR compliance checklist and GDPR for SaaS. The GDPR service page covers how we scope this work, and GDPR and CCPA compliance covers vendor terms when US state privacy law applies alongside.

Frequently Asked Questions

What is the data processing agreement for GDPR? The written contract Article 28 requires between a controller and a processor. It describes the processing (subject matter, duration, nature, purpose, data types, data subjects) and imposes eight obligations covering instructions, confidentiality, security, sub-processors, assistance with data subject rights, assistance with breach and DPIA duties, deletion or return, and audit rights.

Is a DPA the same as an NDA? No. An NDA restricts disclosure to outsiders. A DPA restricts internal use, mandates security measures, controls sub-processing, requires deletion at termination, and grants audit rights. Confidentiality is one clause within a DPA, not a substitute for it.

Does GDPR apply in the USA? Not by nationality, but extraterritorially under Article 3(2) where a US company offers goods or services to people in the EU or monitors their behaviour. A US processor handling EU personal data needs a DPA plus a transfer mechanism — SCCs with a transfer impact assessment, or Data Privacy Framework certification.

What are the 7 processing principles of GDPR? Lawfulness/fairness/transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. A DPA is a primary way controllers evidence accountability for third-party processing.

Who is responsible for putting a DPA in place? Both parties. The controller must only engage processors under a compliant contract; processors have direct obligations under the same article. Processors usually supply the template, but that does not move the controller's risk if the template is incomplete.

Do I need a DPA with every vendor? With every vendor processing personal data on your behalf — hosting, CRM, email, support, analytics, error monitoring, payroll, recruiting, AI services. Not with independent controllers such as your bank or auditor. Joint controllers need an Article 26 arrangement instead.

Need Your Vendor Agreements Reviewed?

ShieldKey Solutions audits processor agreements against Article 28 clause by clause, classifies every vendor as processor, joint controller, or independent controller, checks transfer mechanisms and annexes, and gives you a prioritised list of which contracts to re-paper first. Most teams find gaps in their three largest vendors.

Schedule a scoping call →