A data processing agreement lands in your inbox: from your hosting provider, your payroll processor or the service that writes your reports. Sign it and move on? This article is not a template to download but a reading check for the document you have just received: what the law requires it to contain, where most documents go vague, and which route to take when the content falls short.
One thing first: this is general guidance based on GDPR Article 28 and publications by the Dutch Data Protection Authority (Autoriteit Persoonsgegevens). It is not legal advice; when in doubt, consult your data protection officer or a lawyer.
What is a data processing agreement?
A data processing agreement is the written agreement in which an organisation and its processor set out what may happen to personal data. Article 28(3) GDPR requires, among other things, that the processor acts only on instructions, guarantees confidentiality and appropriate security, engages sub-processors only with authorisation, and deletes or returns the data once the engagement ends. The common abbreviation is DPA; if you searched for "DPA" or "GDPR DPA", this is the same agreement. It is not a formality or an annex you sign along with the rest, but the arrangement that determines what someone else may do with your people's data.
A common assumption: the supplier includes the data processing agreement, so it must be fine. Receiving a document is not the same as receiving a good one, though. In 2020 the Dutch Data Protection Authority examined data processing agreements in practice and reached an uncomfortable conclusion: "the" data processing agreement does not exist. It is bespoke work, and the regulator found documents that did not quite live up to the requirements. An agreement that neatly copies out the legal text looks complete, and on paper it is, but it says little about what happens when things go wrong.
That is why you read it yourself, even when the processor provides it. The minimum content is set out in Article 28(3), and those eight elements are easiest to read as a sign-off checklist.
Processor or controller: who is who?
The controller decides why and how personal data is used; the processor acts on instructions and may do nothing with the data other than what was agreed. The data processing agreement is exactly the line between those two roles: it records that the processor carries out what the controller decides, and nothing more.
An example close to everyday practice. When an organisation has an external service write the reports of its meetings, that service processes personal data on the organisation's behalf. The organisation remains the controller and sets the purpose; the service is the processor and does the work. The data processing agreement between the two records who decides what.
That distinction is the foundation. Without clear roles the rest of the document makes little sense, because every element says something about what the processor must do on your behalf.
What must a data processing agreement contain?
Article 28(3) lists eight elements (a to h) that belong in every data processing agreement. On the left is what the law requires; on the right is what that means for you when you go through a supplied agreement. Work through them like a checklist you sign off point by point.
| Element | What the law requires (art. 28(3)) | What this means for you |
|---|---|---|
| a) Instructions | The processor processes the personal data only on documented instructions from the controller (including transfers outside the EU, unless required by law). | The supplier may not use your data for its own purposes. With an AI service, check that it says the supplier does not train on customer data. |
| b) Confidentiality | Everyone processing the data on the processor's behalf is committed to confidentiality. | Is the duty of confidentiality stated explicitly, including for the supplier's staff and any contractors? |
| c) Security | The processor takes all the appropriate security measures required by Article 32. | Are the measures named concretely (encryption, access, retention), or does it just say "appropriate" with nothing behind it? |
| d) Sub-processors | The processor meets the conditions of paragraphs 2 and 4 for engaging another processor. | Is there a sub-processor list, how do you give authorisation, and do you have a right to object when the list changes? We expand on this below. |
| e) Assistance with data subject rights | The processor assists the controller with requests from data subjects (access, rectification, erasure). | How, and within what timeframe, does the supplier help when someone requests access to their data or has it erased? |
| f) Assistance with obligations | The processor assists with security, breach notification and DPIAs (Articles 32 to 36). | Within what timeframe, and to which contact point, does the supplier report a data breach? We expand on this below too. |
| g) Deletion or return | Once the engagement ends, the processor deletes the data or returns it, at the controller's choice. | Does it say what happens to the data after termination, and within what timeframe that is settled? |
| h) Audits | The processor makes information available and allows audits and inspections. | May you (or an auditor on your behalf) verify that the supplier keeps to what was agreed? |
Source: GDPR Article 28(3) (privacy-regulation.eu). Paraphrased, faithful in substance to the regulation text.
Almost every data processing agreement you receive ticks off the left-hand column neatly and sags in the right-hand one. All eight elements are there; it just stops at "appropriate security" instead of encryption and access management, and at "the processor reports a data breach" without a timeframe or a contact point. Complete on paper is not the same as concrete in practice, and only that right-hand column tells you which of the two you are holding.
Two of those eight elements deserve extra attention, because that is exactly where most data processing agreements go vague.
Sub-processors: may the processor bring in someone else?
A processor may only engage another party, a sub-processor, with your written authorisation, and afterwards remains fully liable itself for what that sub-processor does (Article 28(2) and (4)). Liability therefore stays with the party you sign with, even when something goes wrong further down the chain. This is what you look for in the document:
- Sub-processor listIs there a list of the parties the processor itself engages? That list often also shows where the data ends up.
- Form of authorisationDo you approve each new sub-processor in advance (specific authorisation), or are you informed beforehand so that you can object (general authorisation)?
- Right to objectCan you object, and cancel, when the list changes? Changing it unilaterally without a duty to notify or a right to object is a red flag.
Article 28(2) provides for two forms of authorisation. Under specific authorisation the processor may only engage a new sub-processor once you have approved it. Under general authorisation the processor may switch, but must inform you beforehand so that you can object. The decision point you look up in the document: may the main processor change the sub-processor list unilaterally, and what right do you have in return? Also check that every sub-processor is bound by the same obligations as the main processor.
If the sub-processor list includes a party outside the EU, that is a separate point to verify on its own: which law your data then falls under, and which American parties sit in the chain. How to weigh that wider question is covered at secure notetaking. Here we stick to the clause: who may enter the chain, and what right that leaves you.
The second element where agreements go vague is the data breach clause, and that is precisely the one you may need badly later on.
The data breach clause: the rule you'll need most when it matters.
The data processing agreement must lay down that, and how, the processor reports a data breach to you, because when a breach happens on the supplier's side you, as the controller, are the one who may have to notify the supervisory authority. You bear the notification duty, even when the breach starts at your supplier; that supplier then has to inform you in time, and in enough detail, for you to meet your own deadline. Three things to look up:
- Notification deadlineHow soon after discovery does the supplier report a data breach to you?
- Contact pointWho does the report go to, or through which channel, so it doesn't sit unread?
- Content of the reportDo you get enough information to meet your own deadline with the supervisory authority?
That this arrangement is often too vague is not an assumption. In 2025 the Dutch Data Protection Authority examined five major cyberattacks on service providers that together affected more than 1,250 organisations and an estimated 10.5 million people, and concluded that precisely these notification arrangements are often too vague to be of any use during an attack (Dutch DPA, 12 November 2025). A clause that only says "the processor reports a data breach", without a timeframe, contact point or content, is exactly such a vague arrangement.
When do you need a data processing agreement, and when not?
You conclude a data processing agreement as soon as you have an external party process personal data on your behalf. You don't need one when that other party is a controller in its own right, or when no personal data is involved at all. The question is therefore not "is this a big supplier", but "does this party process my people's data on my instructions".
When you do need one
- An external service that processes your reports or conversation recordings.
- A hosting provider that puts your files on its servers.
- A payroll firm that processes your staff data.
When you don't
- An accountant working on its own legal basis, as a controller in its own right.
- Two organisations exchanging data as independent controllers. Different arrangements apply in that case, not a data processing agreement.
And if the answer is no?
Suppose you read through the data processing agreement and something is off: what then? The agreement a SaaS supplier offers is usually a standard document you cannot negotiate line by line; checking it does not automatically mean you can change it. At document level you have roughly three options. You can ask the supplier for an addition or addendum on the point that falls short, for instance the breach deadline or a sub-processor clause. You can knowingly accept the residual risk and put that on record. Or you conclude that the agreement is not good enough and look for a different tool. Which tool to choose, and how to weigh that, is covered in choosing a GDPR-compliant AI tool; for the is-it-allowed status of a public AI tool, read is ChatGPT GDPR compliant.
What if the data processing agreement is missing or falls short?
Having no data processing agreement is a breach of GDPR Article 28, and the Dutch Data Protection Authority can take enforcement action against it; for such a breach the GDPR provides for fines of up to 10 million euros or 2% of worldwide annual turnover, whichever is higher (Article 83(4)). That is the maximum, not the standard, and whether it comes to that depends on the situation. The fine is just not the part that affects you day to day.
What matters more in practice is this: without concrete arrangements you're on your own when a data breach or an audit hits. When a breach occurs at your supplier, the notification clause decides whether you meet your own deadline with the supervisory authority or end up chasing the facts. When a regulator asks for evidence during an audit, what counts is what's in writing, not what you had assumed. That is why you read the data processing agreement beforehand rather than afterwards.
How to assess a supplied data processing agreement: six reading checks.
Work through these six points as soon as a supplier sends you a data processing agreement. Each point is a concrete question to the document, not to yourself.
- Instructions and own useRead whether the supplier processes the data only on your instructions and doesn't use it for its own purposes. With an AI service, the key question is whether it says the supplier doesn't train on your data.
- Security in concrete termsCheck whether the security measures are named (encryption, access, retention) or whether it just says "appropriate measures". Restating the law is not an arrangement.
- Sub-processors and the right to objectLook for the sub-processor list, check whether you give authorisation in advance, and whether you have a right to object when the list changes. An agreement that lets the list change unilaterally, without a duty to notify or a right to object, is a red flag.
- Data locationThe sub-processor list often also shows where the data ends up. If a party outside the EU is on it, that's a separate point to verify on its own.
- Breach notification arrangementCheck within what timeframe the supplier reports a data breach, to which contact point and with what content. You bear the notification duty, so that arrangement has to enable you to meet your own deadline.
- Deletion or return afterwardsRead what happens to the data after termination and within what timeframe. If it says the data is deleted or returned at your choice, that element is in order.
How Notuly puts the eight elements into practice.
This is what the right-hand column of the checklist looks like when a supplier takes the eight elements seriously. Notuly is the AI notetaker for every conversation, discreet in-person, hybrid and online: in the room, you put your phone in the middle of the table, and for meetings on Teams, Zoom or Google Meet you use the desktop app for macOS and Windows. The organisation that has a meeting captured remains the controller; Notuly is the processor, and what the processor may do is in the document.
- Processed in AmsterdamThe entire AI chain, from speech to text through to the summary, runs on Notuly's own models on Dutch servers. Your conversation never leaves the EU. That covers elements a, c and d of the checklist.
- No training on your dataYour conversations are not used as training data. That is in the data processing agreement you can request in advance, not just on this page.
- Audio deleted within a minuteRecord, process, the report in your email, and the audio is deleted within a minute of processing. No searchable audio archive at Notuly. That ties element g of the checklist to something concrete.
The shortest answer to what happens to the data is the life cycle: within ten minutes the report is in everyone's inbox, with the full transcript as an attachment. So the text stays; only the audio disappears, and what happens to the report after that is your decision. Who the sub-processors are is stated in the data processing agreement itself: that is where such a thing belongs.
The data processing agreement (GDPR Article 28) is available on Team and above and can be requested before you sign. Feel free to read it against the six checks above; the wider policy is at Privacy & Security.
Read how Notuly takes notes securely →
Sources.
- GDPR Article 28 (paragraphs 2, 3 and 4), verbatim regulation text. The eight elements a to h and the sub-processor paragraphs. Consulted 10 June 2026.
- Autoriteit Persoonsgegevens (Dutch DPA), Three recommendations for a strong data processing agreement during a cyberattack. Source for the data breach clause and the figures (five cyberattacks, 1,250+ organisations, around 10.5 million people). Published 12 November 2025.
- Autoriteit Persoonsgegevens (Dutch DPA), basic guidance on the data processing agreement. Source for the roles, the required content and the obligation. Consulted 10 June 2026.
- Autoriteit Persoonsgegevens (Dutch DPA), Research in the private sector: "the" data processing agreement does not exist, with the PDF Werkende verwerkersovereenkomsten. Source for the myth in the opening: data processing agreements vary widely in practice; it is bespoke work, not a standard template. Published 12 October 2020; consulted 10 June 2026.
General guidance based on the sources listed, not legal advice. When in doubt, consult your data protection officer or a lawyer.