GDPR Article 28: what a data processing contract must contain

GDPR Article 28 sets out what the contract must contain between a business and each supplier that processes personal data on its behalf. In a small business these suppliers are far more numerous than people think: email, payroll software, the sales management tool, e-signature, the website host. Almost every online tool is a processor within the meaning of the regulation — and most businesses have never reread their contracts from that angle.

The data processing agreement almost always arrives at the same moment: at the end of the negotiation, as an annex, once the price is settled and nobody wants to reopen anything. It is signed without being read.

That is a misjudgement about who carries the risk. Where there is a breach, the controller — you — answers for its choice of processor. The agreement is not administrative paperwork: it is the only document recording what you required.

Controller and processor: who is who

The GDPR distinguishes two roles. The controller determines why and how personal data is processed. The processor processes it on the controller’s behalf, on its instructions. A small business is the controller for its customer files, its staff and its prospects; the suppliers it entrusts that data to are its processors.

The line is not always clear. A vendor hosting your customer data acts as a processor for that data; if it also uses the data for its own purposes — improving its product, producing statistics — it becomes a controller for that part, which falls outside the processing contract. This is Article 28(10): a processor that determines the purposes and means of processing is considered a controller in respect of that processing.

Before negotiating clauses, you have to agree on what is being bought. Hosted software and a managed service do not carry the same obligations: in one, the supplier provides a tool you administer; in the other, it runs the processing on your behalf.

That distinction moves the scope of regulatory validation, the split of responsibilities when something goes wrong, and even the list of sub-processors to declare. It is settled at the start, not at inspection.

Before arguing over clauses, you need to know what you are buying. Classification governs everything else.

What GDPR Article 28 requires

The text of Article 28 sets three obligations before the contract’s content even comes into it. The controller uses only processors providing sufficient guarantees. The processor does not engage another processor without prior specific or general written authorisation. And the contract is in writing — electronic form is enough.

The contract must then set out the subject matter and duration of the processing, its nature and purpose, the type of personal data and categories of data subjects, and the controller’s obligations and rights. Above all, it must stipulate that the processor:

• processes the data only on documented instructions, including for transfers outside the Union;
• ensures that authorised persons are committed to confidentiality;
• takes the security measures required by Article 32;
• respects the conditions for engaging another processor;
• helps the controller respond to data subject requests;
• helps it meet its obligations on security, breach notification and impact assessment;
• deletes or returns the data at the end of the service, at the controller’s choice;
• makes available the information needed to demonstrate compliance, and allows for audits.

Two provisions complete this base. A processor that hands part of the work to another must impose the same obligations on it, and remains fully liable to you for what that second supplier does. And the European Commission has adopted standard contractual clauses (Implementing Decision 2021/915 of 4 June 2021) that meet the requirements of Article 28: using them avoids reinventing a contract the legislator has already written.

The DPA: the clauses to check one by one

The processing contract often goes by its English name, Data Processing Agreement, or DPA. Large vendors offer it as standard terms, rarely negotiable. The work then lies less in rewriting it than in reading it, and knowing what one is accepting.

• Scope. Do the data and data subjects described match your actual use of the tool?
• Sub-processors. Is their list published, are you notified of changes, and can you object?
• Location and transfers. Where is the data hosted, and on what legal basis does it leave the Union, if it does?
• Security. Are the measures described precisely, or referred to in general terms?
• Data breaches. The processor must notify the controller without undue delay after becoming aware of one. Does the contract set a concrete deadline, compatible with your own obligations?
• Audit. How does it work in practice: on documents, on site, through a third party, how often and at what cost?
• End of contract. Return in what format, within what time, then certified deletion?

Transfers outside the Union deserve particular attention, because the framework has already changed twice. Transfers to the United States currently rely on the EU–US Data Privacy Framework adopted on 10 July 2023, upheld by the EU General Court on 3 September 2025. Its two predecessors were struck down by the Court of Justice, the second by the Schrems II judgment of 16 July 2020. A contract relying on this framework should say what happens if it falls.

Finally, three omissions come up in almost every review:

• Sub-processing. Your supplier almost always relies on others. Without an authorisation clause, you discover the chain at the moment of the incident.
• Audit. A right to audit with no mechanics — notice, frequency, scope, who pays — is a right nobody will exercise.
• The end of the contract. Return in what format, within what time, at what cost. Unwritten, it gets negotiated at the worst moment: when you are leaving.

Mapping your processors: the method

That said, you can only require by contract what you have first inventoried. Knowing which processing activities actually exist, and which rely on a third party, is the work done by a GDPR audit — and it comes before the negotiation, not after.

The method comes down to five steps, and the first almost always surprises.

• Start from spending, not from the IT list. Card statements, recurring invoices, subscriptions: that is where tools signed up for by one department without anyone else knowing show up.
• Qualify each tool. What data goes into it, about whom, for what use. This information feeds the record of processing activities.
• Find and read the contract. Does a DPA exist, does it cover the actual use, and what does it say on the points above?
• Record location and chain. Hosting country, sub-processors, legal basis for transfers.
• Prioritise. Start with the tools processing the most sensitive or the largest volumes of data, rather than in alphabetical order.

A map is not a frozen inventory — mapping is not inventorying. It is kept up to date with every new tool, and it is the job of the IT usage policy to say who may sign up for one, and on what terms. The most common case today is that of online artificial intelligence tools, used by teams before any decision has been made: ChatGPT and the GDPR raise exactly the question of the processor nobody chose.

A well-drafted processing agreement does not protect you from a failure — it determines who bears it, and what you can demand to put it right. It is a contractual exercise before it is a legal one, and it is conducted with the same instinct as any negotiation: knowing what you are asking for, and recognising an inadequate answer.

It is this work — listing, qualifying, reviewing, prioritising — that Maeliom Consulting carries out with management teams who want to know what they have committed to, before an incident tells them.

Common questions

Sources: GDPR, Articles 28 and 33 (CNIL); Implementing Decision (EU) 2021/915; processor guide and sample clauses (CNIL); adequacy decision (EU) 2023/1795.