On this page
A data processing agreement is the contract that has to exist whenever someone else handles personal data on your behalf. If you are the business deciding what happens to the data you are the controller; the tool doing the work is the processor; and under GDPR Article 28 the contract between you is not optional. In practice you almost never write one. Every serious vendor publishes a DPA you accept, so your real job is knowing which of the eight required terms to check, spotting the two that are usually missing, and keeping a record of who processes what. The template below is for the one case where you do need to supply it: when a client asks you for yours. It covers all eight terms, and the checklist after it is what to read before you sign anybody else's.
Most people meet this document the same way. A client sends a contract with an annex titled Data Processing Agreement, or a vendor's signup flow asks you to accept one, and the question is not what it means in the abstract. The question is whether you can sign it and move on.
So this starts with the decision rather than the definition, then gives you the document. The whole job, start to finish, is six steps:
- Work out which side you are on. You are the controller when you decided the data would be collected, and the processor when you are handling somebody else's. Most small businesses are both, on different contracts.
- List everyone who touches the data. Every tool, contractor and platform. This list is the thing every later step depends on, and it is the one nobody has ready.
- Collect the DPAs you need to accept. For each vendor on that list, find their published DPA. You are checking it, not negotiating it.
- Check each one against the eight required terms. The ten-point list further down is the working version of this check.
- Write your own, for when a client asks. That is what the template below is. Fill in the highlighted values once and reuse it.
- Re-read the sub-processor list every few months. It goes out of date the moment you add a tool, which is the failure that catches people.
Step 1 and 2: Do You Actually Need One
The test is a single question: does anyone outside your business touch personal data that you decided to collect? Personal data means anything identifying a living person, which includes a client's email address, a customer list, a support ticket, a CV, or a photograph.
If yes, a DPA is required between you and them. GDPR Article 28(3) states the processing must be governed by a contract that is binding in writing. There is no threshold below which it stops applying, no small business exemption, and no version of it that turns on your revenue or headcount.
Where people get this wrong is assuming it only applies to big platforms. A business of one running a newsletter through an email tool, storing files in cloud storage, and using a freelance VA to answer support is a controller with three processors. That is the common case, not the exotic one.
Two situations that look like they need a DPA and do not. An employee is not a processor, because they act under your direct authority rather than as a separate business. And a party who decides for themselves why they are processing the data is not your processor either; your accountant filing your returns has their own legal duties, which makes them a separate controller, and the right document there is a controller-to-controller arrangement rather than a DPA.
Aziz's take: I spent a long time assuming this was enterprise paperwork that would find me eventually if it mattered. It does not work that way. The moment a client's legal team sends you a vendor questionnaire, you either have this document or you spend a week improvising it while they wait. Writing it once, before anyone asks, took me an afternoon. Being asked for it with nothing prepared is what costs you the deal.
The Data Processing Agreement Template
Use this when a client needs a DPA from you, meaning you are the processor. Fill in every highlighted value. It covers all eight terms Article 28(3) requires, in the order a reviewer expects to find them.
How to use this
Fill in
- Every highlighted value. Nothing else needs changing.
- Be specific in section 02. "All customer data" is not a description; "name and email of newsletter subscribers" is.
- List every sub-processor in section 05, including the ones you think are too small to matter.
Check before sending
- The retention period in 06 is one you can actually meet.
- The breach window in 04 is 72 hours or less, matching what the controller owes their regulator.
- Section 05 names a country for each sub-processor, not just a company.
What goes wrong
- Describing the data as "as necessary". A reviewer reads that as you not knowing what you hold.
- Promising deletion on request while your backups keep it for another 90 days. Say so instead.
- Signing your own document without checking it against the sub-processors you actually use this month.
- The processor acts only on documented instructions from the controller, including on international transfers, unless required otherwise by law.
- The processor ensures all persons authorised to process the data are under an obligation of confidentiality.
- The processor implements the technical and organisational measures listed in section 04.
- The processor engages no sub-processor without the controller's prior authorisation, and imposes these same obligations on any it does engage.
- The processor assists the controller in responding to data subject requests within the period stated in section 03.
- The processor assists the controller with security, breach notification and impact assessments.
- At the controller's choice, the processor deletes or returns all personal data at the end of the contract, on the terms in section 06.
- The processor makes available all information necessary to demonstrate compliance and allows for audits by the controller or an auditor it appoints.
The Eight Terms It Has to Contain
Those eight numbered terms are not stylistic. They are the list in GDPR Article 28(3), and a DPA missing one is incomplete regardless of how long it is. When you are reading somebody else's document, this is the list you are checking it against.
Rather than restate them, here is what each one is actually protecting you from, because that is what tells you whether the wording in front of you is adequate.
Documented instructions stops the processor doing anything else with the data. Without it a tool could lawfully use your customer list to train something, or to market to those people directly.
Confidentiality extends the duty past the company to the individuals inside it, which matters most with small vendors and contractors where there may be no employment contract doing that work.
Security measures is where vague wording is most common and least useful. "Industry standard measures" tells you nothing. You want named controls.
Sub-processor control is the one people skip and the one that bites. Your processor's processors also hold your data. If a vendor can add sub-processors without telling you, you cannot answer the question of where your client's data is.
Data subject assistance matters because the deadline for responding to a subject access request is one month and it falls on you, not the processor. If they take three weeks to export the data, you have missed it.
Breach notification matters for the same reason. You have 72 hours to tell your regulator, and that clock starts when you become aware. A processor with a vague notification term hands you a deadline you cannot meet.
Deletion or return decides what happens when you leave. Without it, the default is that they keep it.
Audit and information is the term that makes the other seven verifiable rather than declared.
Reading a DPA Somebody Sends You
This is the common direction of travel. A vendor publishes theirs, and you accept it as part of signing up. You will not negotiate it and there is no point trying, so the exercise is deciding whether to accept it at all.
Four things are worth the ten minutes.
Find the sub-processor list. It is usually a separate page linked from the DPA rather than in it. If there is no list, that is the finding. If the list exists, look at which countries appear, because that is what you will have to tell a client who asks where their data goes.
Check the sub-processor change notice. Thirty days with a right to object is normal and reasonable. Notification with no objection right means you find out after the fact. No notification at all means the list you just read is a snapshot with no shelf life.
Check the breach window against 72 hours. "Without undue delay" alone is weaker than it sounds. A named number is what lets you meet your own deadline.
Check what deletion actually means. Most say deletion within 30 to 90 days with backups expiring on their own cycle. That is honest and fine. What is not fine is silence on backups, because it means nobody has thought about it.
Five Mistakes That Cost Real Money
Assuming the vendor's DPA covers you both ways. It makes them your processor. It says nothing about you being your client's processor. Those are two separate documents and clients ask for the second one. It is also separate from your main client contract, which covers the work rather than the data.
Treating a signed DPA as the end of it. Article 30 also expects you to keep a record of your processing activities. The DPA is the contract; the record is the inventory. A client questionnaire usually asks for both.
Letting the sub-processor list drift. Most small businesses add a tool every few months. A list assembled once and never revisited becomes wrong quietly, and you only discover it under questioning.
Promising a deletion timeline the backups contradict. If your storage keeps deleted files for 90 days, a 30-day deletion promise is one you break by default.
Signing before checking who else already has the data. Nothing in a DPA changes what your existing tools have been doing for two years. If you are bringing on a new client, the point to ask these questions is during onboarding, not after.
One related trap worth naming: AI tools are processors like any other. If you paste a client's customer list into a chatbot, that vendor is now processing personal data on your behalf, and the same eight terms apply. Legal AI tools are no exception, and their terms of service are not a substitute for a DPA.
Aziz's take: The sub-processor list is the part I would check first and the part almost nobody reads. It is the only section that tells you something concrete rather than something contractual. Everything else is a promise about behaviour; that list is a statement of fact about where data physically goes, and it is the answer to the only question a nervous client actually asks.
The Ten-Point Check Before You Sign
- Both parties are named with legal entity names, not trading names.
- The data types are described specifically enough that you could list them.
- The processing purpose is limited to the service, not open-ended.
- Processing on documented instructions is stated explicitly.
- Confidentiality binds individuals, not only the company.
- Security measures name actual controls rather than "industry standard".
- A sub-processor list exists and you have read it.
- Sub-processor changes come with notice and a right to object.
- Breach notification names a period of 72 hours or less.
- Deletion terms say what happens to backups.
If a document fails points 7 through 10, the gap is real rather than cosmetic. Those four are where the difference between a DPA that protects you and one that decorates the contract actually sits.