How to create a DPA: clauses, templates, and what to include

Sooner or later, the moment arrives. Either you need to issue a Data Processing Agreement to a partner, or a vendor slides one across the table and waits for your signature. I have sat on both sides of that exchange, and the work comes down to the same thing every time: knowing what a good DPA contains, and recognising where the weak spots tend to hide.

A DPA is not a formality you sign to make the procurement form go green. It is the document that defines how someone else handles your customers' and employees' personal data, what they promise about keeping it safe, and what recourse you have when something goes wrong. Get it right and it quietly protects you for years. Get it wrong and you find out at the worst possible moment.

This guide walks through the anatomy of a solid DPA, section by section, then gives you a checklist to run before you sign or send one.

This is practical guidance, not legal advice. Have a qualified professional review any agreement before you rely on it.

By the end of this guide, you will:

• Understand every section a GDPR Article 28 DPA should contain
• Know when Standard Contractual Clauses come into play
• Be able to spot the red flags in a vendor's "standard" template
• Have a pre-signing checklist you can use immediately

The anatomy of a DPA

A DPA built to GDPR Article 28 generally covers the following ground. I find it useful to read any agreement against this list, because the gaps tell you as much as the text.

Scope and roles

Who is the controller and who is the processor, plus the subject matter and duration of processing and its nature and purpose. This sounds basic, and yet I have seen agreements where the roles are muddled or simply assumed. Get this wrong and the rest of the document rests on sand.

Categories of data and data subjects

What types of personal data are processed, and whose: customers, employees, end users. Specificity here protects everyone, because it bounds what the processor is actually allowed to touch.

Processing on instructions

The processor acts only on the controller's documented instructions, and not on its own initiative. This is the clause that stops your data being quietly repurposed.

Security measures

The technical and organisational measures required: encryption, access controls, resilience, regular testing. The word to watch for is "appropriate" standing alone. Appropriate measures with no detail is a promise to decide later, which in practice often means a promise to do little. Good security clauses are specific, and they should map to the kind of protections you would expect from any serious platform, the EU hosting, encryption, and role-based access that underpin our own security approach.

Confidentiality

Anyone with access to the data is bound to keep it confidential. Short clause, real consequences.

Sub-processors

Whether sub-processors are permitted at all, the requirement to flow equivalent terms down to them, and your right to be notified of changes and to object. Personal data rarely sits with one company anymore. It moves down a chain, and this clause is how you keep sight of the chain.

Assistance

The processor helps you respond to data subject rights requests and meet your own security, breach, and impact-assessment obligations. When a customer exercises their right to deletion, you will be glad this is written down.

Breach notification

A clear, short timeframe for the processor to tell you about a personal data breach. "Without undue delay" is the standard you want. Anything measured in weeks is a problem you will inherit.

International transfers

A valid transfer mechanism, such as Standard Contractual Clauses, wherever data leaves the EEA, along with the related assessments. More on this below, because it is the piece most often missing.

Deletion or return

What happens to the data when the relationship ends: deletion or return, at your choice, with certification on request. Open-ended retention is one of the quieter risks in a weak DPA.

Audits

Your right to verify that the processor is actually doing what it agreed to. Real audit rights, not a polite gesture.

Standard Contractual Clauses: when you need them

If personal data will be processed outside the EEA, or by a sub-processor that is, the DPA usually needs to incorporate SCCs and reference a transfer impact assessment. This is one of the most frequently missed pieces I come across.

The trap is subtle. A vendor's "standard" DPA often assumes EU-only processing because that was true when the template was first written, or because it was simply easier to draft that way. Then the vendor adds a US-based support tool or an analytics sub-processor, and the reality no longer matches the paperwork. Nobody updates the DPA, because nobody is looking at it. The transfer happens anyway, uncovered.

So when you review a DPA, look past whether SCCs are mentioned. Check whether the data flows the contract describes actually match where processing happens. The mismatch is where the exposure lives.

Red flags when accepting a vendor's DPA

When a vendor's DPA lands in front of you, these are the warning signs I scan for first:

• Breach-notification windows measured in weeks rather than "without undue delay"
• Blanket sub-processor rights with no notice or objection mechanism
• Vague security language with no specific measures named
• Deletion terms that let the processor keep data indefinitely
• No transfer mechanism at all, despite processing that clearly leaves the EEA

Any one of these is worth a conversation before signing. Two or more, and you are looking at a template that was written to protect the vendor, not you.

A pre-signing checklist

Before you sign, or before you send, run through this. I keep a version of it close whenever a DPA crosses my desk.

Check	Confirm that
Roles	Controller and processor are correctly identified
Security	Measures are specific, going beyond "appropriate"
Sub-processors	Notice and objection rights exist
Breach	Notification is prompt ("without undue delay")
Transfers	A valid mechanism is in place if data leaves the EEA
Deletion	End-of-relationship terms are clear
Audits	Verification rights are real, not decorative

If you are negotiating these terms regularly as part of procurement or broader vendor contract management, it pays to standardise this checklist so every agreement gets the same scrutiny rather than depending on who happened to review it.

The DPA does not end at signature

Here is the part that gets forgotten. Once signed, a DPA becomes an ongoing obligation, not a closed task. The sub-processor list changes. The annual review comes due. A legal development means the SCCs need revalidating. None of that announces itself.

Keeping the DPA alongside the vendor contract, with its review dates, sub-processor terms, and transfer obligations tracked, is exactly what data processing agreement management is for. It means the agreement you negotiated so carefully does not quietly go stale in a folder. A contract repository keeps the document findable, and automated expiration and renewal reminders make sure the review dates actually surface instead of slipping past. If you want to feel how that works without committing to anything, our free data processing agreement reminder sets one up in a couple of minutes.

Reviewing one faster

If you are staring at a vendor's DPA right now and want a fast read on whether it is solid, our free data sharing agreement analyzer extracts the permitted-use, security, retention, breach-notification, and transfer terms and flags where they look insufficient. It is a useful first pass before a detailed legal review, the kind of thing that tells you within a minute whether you are looking at a careful agreement or a problem in waiting. If you want the wider picture of how AI is changing this kind of work, our piece on legal AI is a good companion read.

Drafting and reviewing DPAs is genuinely satisfying work once you have a clear picture of what good looks like, and I am always glad to help someone get there. Do reach out if you have questions. I read every message myself and answer it personally.