How to read a supplier's DPA under GDPR Article 28

Every supplier that handles personal data for you — hosting, e-mail, CRM, payroll — is a processor under the GDPR, and you are the controller. Article 28(1) says you may use only processors that give “sufficient guarantees”, and Article 28(3) says the relationship must rest on a contract with a specific list of contents. That contract is the DPA. This guide is how to read one in half an hour: what each required clause looks like when it is done properly, what it means when the DPA says nothing, and which questions to send the supplier before you rely on it.

Why the DPA is your problem, not only the supplier’s

The obligation to have a DPA sits on both sides: the controller must not process through a processor without one, and the processor must not process without instructions. Article 83(4)(a) puts a defective or missing Article 28 contract in the fine bracket of up to 10 million euro or 2 % of worldwide turnover, for controllers and processors alike. Article 28(9) requires the DPA to be in writing, which includes electronic form: a DPA published as a page on the supplier’s site and incorporated in the terms you accepted satisfies that — and can be changed by editing the page.

What Article 28(3) says a DPA must contain

The article has two parts. The introduction requires the contract to set out the subject-matter and duration of the processing, its nature and purpose, the types of personal data and categories of data subjects, and the obligations and rights of the controller — a good DPA puts these in an annex; “personal data processed in connection with the Services” is a placeholder, not a description. Then eight lettered points list what the contract must stipulate that the processor does:

• (a) processes only on your documented instructions, including for transfers to a third country, unless law requires otherwise;
• (b) ensures the people who process the data are bound by confidentiality;
• (c) takes all the security measures Article 32 requires;
• (d) respects the conditions in Article 28(2) and (4) for engaging another processor — the sub-processor rules;
• (e) assists you, as far as possible, in answering data subjects’ requests under Chapter III;
• (f) assists you in meeting Articles 32 to 36: security, breach notification, data protection impact assessments and prior consultation;
• (g) deletes or returns all personal data at the end of the service, at your choice, and deletes existing copies unless law requires storage;
• (h) gives you the information needed to demonstrate compliance, allows for and contributes to audits, and tells you if it thinks an instruction breaks the law.

Every one of these is a clause you should be able to point at in the DPA. If you cannot, the DPA is incomplete, whatever else it promises. The Commission’s standard clauses for controller–processor contracts (Implementing Decision (EU) 2021/915) are the benchmark: a DPA that covers less deserves a question.

Reading it clause by clause

Read the DPA with the list above beside it and mark each point stated, stated weakly or not stated.

Instructions (a). Look for the sentence that the agreement and your use of the service are the documented instructions. Watch for the reverse: a clause that lets the supplier process for “its own legitimate business purposes” such as analytics or product improvement. That is the supplier acting as a controller for those purposes — legal, but it must be spelled out, and it belongs in your record.

Security (c). The DPA should reference a security annex or a public security page with concrete measures — encryption in transit and at rest, access control, logging, backups. “Appropriate technical and organisational measures” without any list restates the law and commits to nothing you can check.

Sub-processors (d). There should be a current list, a notice mechanism for changes and a right to object. The details are in the sub-processor guide; for the DPA itself, check that the list is referenced and dated.

Assistance (e) and (f). Check the breach notification window. Article 33(2) requires the processor to notify you “without undue delay”; good DPAs say 24, 48 or 72 hours, the shorter the better, because your own 72-hour clock to the authority under Article 33(1) starts when you become aware.

Deletion or return (g). Look for a period (“within 30 days of termination”) and for what happens to backups. “Deleted in accordance with our retention policy” without a period is not a commitment.

Audit (h). Small suppliers often offer third-party audit reports and written answers instead of on-site audits. Acceptable, as long as the right to an audit exists on paper and is not priced out of reach.

Transfers. The DPA should state where the data is processed and, for any processing outside the EU or EEA, the Chapter V mechanism: an adequacy decision under Article 45, the 2021 standard contractual clauses under Article 46(2)(c), or binding corporate rules under Article 47. An EU supplier with sub-processors in the United States needs this too.

What silence means

Silence in a DPA is a gap, not consent and not a promise, and the gap is the controller’s as much as the processor’s: Article 28(3) says the contract shall stipulate these things. Three rules make silence readable.

First, silence is specific to the document kind. A DPA owes you a deletion clause; a supplier’s general terms do not. Before you write down that a supplier “has no deletion commitment”, check the documents you have not read — the security page, the sub-processor page, the terms.

Second, “not stated” is a question, not a verdict. A missing breach notification window means you do not know the supplier’s window, not that the supplier has none. Ask, in writing, and record the answer beside the DPA.

Third, silence dated is evidence; silence remembered is not. Note the version or date you read and what was missing on that date, so that when the supplier adds or removes a clause you can show what changed and when.

The questions to put to the supplier

Send these when the reading leaves gaps. A supplier who cannot answer them in a week has told you something.

1. Which document is your current DPA, what is its version or date, and where is the change history?
2. Do you process any of our data for your own purposes? Which, and on what legal basis?
3. Where is our data processed and stored, including backups, and which transfer mechanism covers any processing outside the EU and EEA?
4. Where is the current sub-processor list, how are changes announced, and how do we object?
5. Within how many hours of becoming aware of a personal data breach do you notify us, and through which channel?
6. What happens to our data, including backups, after termination, and within what period?

Where the DPA belongs in your own record

Article 30(1)(d) requires the categories of recipients in your record of processing activities, and Article 5(2) requires you to demonstrate compliance; a DPA you read once and cannot find again demonstrates nothing. Keep, per supplier: the DPA version, the date you read it, what it states and does not state on the points above, and the supplier’s answers. Then re-read it when it changes — the subject of watching suppliers’ terms for changes.

How Maditon does this

This is the first thing Maditon does for a supplier: it fetches the DPA the supplier publishes, or the signed one you upload and can mark private, and reads it in the order above. Every fact it extracts — the breach window, the deletion period, the transfer mechanism — is shown with the passage it rests on, and a second pass lists what a DPA owes that this one does not state. Each finding is a question to put to the supplier, never a verdict, and the reading is a draft until a named user in your organisation accepts it. When the supplier edits the page, the daily check tells you what changed.

How the reading works: How does Maditon read a supplier’s document? Why it does not flag every omission: Why does Maditon not flag everything a document leaves out? Or add your first supplier in the app.