The DPA when you are the processor: what to accept from an enterprise client

What Article 28 requires, and why you should not argue with it

When an enterprise client sends a thirty-page data processing agreement, most of it is not the client’s idea. Article 28(3) of the GDPR sets out what a controller-to-processor contract must contain, and a competent client template simply writes it out at length.

The mandatory content: you process only on documented instructions; you keep the data confidential and ensure your personnel are bound to confidentiality; you implement appropriate technical and organisational measures; you engage sub-processors only under the conditions in Article 28(2) and (4); you assist with data-subject requests; you assist with security, breach notification and impact assessments; you delete or return the data at the end of the service; and you make available the information necessary to demonstrate compliance and allow audits.

Objecting to any of that marks you as a vendor who has not done this before, and it will cost you goodwill you need for the clauses that matter. Read it, confirm you can actually do it, and move on. The exception is where the template goes beyond Article 28 and dresses it up as a legal requirement — which is where the rest of this guide lives.

Sub-processors: general versus specific authorisation

Article 28(2) gives two options: prior specific authorisation for each sub-processor, or general written authorisation with notice of changes and a right to object. Client templates default to the first because it is more protective. For a software vendor it is operationally painful: every change of hosting region, monitoring tool or support platform becomes a contractual amendment.

Ask for general authorisation with a maintained list, thirty days’ notice before a new sub-processor starts processing, and an objection right on reasonable data-protection grounds. Two sub-points decide how workable it is. First, what happens on objection — the reasonable position is that the parties discuss it in good faith and, if it cannot be resolved, the client may terminate the affected service without penalty. Avoid drafting that lets the client veto a sub-processor and keep the contract running: that leaves you contractually obliged to deliver a service you can no longer operate. Second, an emergency exception for security or continuity, with notice as soon as practicable.

Audit rights: frequency, cost, remote first

Templates commonly grant an unlimited right to audit on short notice, at your cost, including on-site inspection by third parties of the client’s choosing. For a sixty-person vendor with fifty enterprise clients, that is an unmanageable liability if even a fraction exercise it.

The negotiated shape is consistent across the market. Documentation first: certifications, audit reports and completed questionnaires satisfy the obligation in the ordinary case. One on-site audit per year, on thirty days’ notice, during business hours, subject to the auditor signing a confidentiality undertaking and not being a competitor. Additional audits at the client’s cost, except following a confirmed personal-data breach affecting their data. That last carve-out is what makes the package acceptable to a serious client: when something has actually gone wrong, they get access without arguing about who pays.

Liability: linking the DPA to the MSA cap

This is the clause that matters most and gets the least attention. A DPA with no liability provision of its own may sit outside the carefully negotiated cap in the master agreement, or its relationship to that cap may simply be undefined. Some client templates go further and state expressly that liability under the DPA is unlimited.

The position to hold: liability under the DPA is subject to the limitations and exclusions in the master agreement, and the caps are aggregate across both documents rather than separate. Without the aggregation point, a client can recover the cap twice for the same incident by framing it once as breach of contract and once as breach of the DPA.

Expect the client to ask for a higher cap for data incidents specifically. A super-cap — two or three times the annual fees for breaches of the data-protection obligations, still inside an overall aggregate limit — is a reasonable concession and often the trade that unlocks the rest. What to refuse is uncapped liability for data protection generally: regulatory fines under the GDPR fall on the controller in the first instance, and an uncapped indemnity for them transfers a risk that is not proportionate to your fee.

The TOMs annex: promise what you do

The annex of technical and organisational measures is the one part of the DPA that a client can check against reality, and the one part vendors are most tempted to inflate. Do not. A TOMs annex describing encryption at rest that you have not implemented is a contractual misrepresentation sitting in writing, waiting for the first audit.

Write it in the present tense for what you operate today, and use a dated commitment for anything in flight: “multi-factor authentication is enforced for all administrative access” alongside “field-level encryption for the reporting database will be implemented by 30 June 2026”. Clients accept dated commitments far more readily than vendors expect, because their own security teams recognise the honesty and can plan around it.

Keep the annex consistent with your security addendum and with the answers in the client’s security questionnaire. Three documents in the same deal saying different things about incident notification timing is the most common finding in a vendor audit.

Deletion, return and the retention exception

Article 28 requires deletion or return at the end of processing. Two practical caveats belong in the drafting. You need a reasonable window — thirty days is standard — rather than deletion “immediately on termination”. And you need a retention exception where law requires you to keep records: accounting and anti-money-laundering rules in your own jurisdiction do not give way to a client’s deletion request. State the exception, state that retained data stays protected by the DPA’s confidentiality and security terms, and the client’s privacy team will recognise it as correct.

Backups deserve a sentence of their own. Deletion from live systems is immediate; deletion from rotating backups happens on the backup cycle. Say so, give the cycle length, and you avoid an argument about whether you complied.

International transfers when part of your team is outside the EEA

If a developer on the project sits in Ukraine, Serbia, Georgia or the UK, the client’s data is being transferred outside the EEA and the DPA needs a transfer mechanism. As a processor engaging a sub-processor, the relevant Standard Contractual Clauses are Module 3, processor to processor. The client will usually want the SCCs incorporated into the DPA by reference, with the annexes completed for your specific arrangement.

What clients actually check in diligence is narrow: whether the sub-processor list names the countries, whether a transfer impact assessment exists, and whether the contractor agreement with the individual carries the SCC obligations down. Have all three and this section of an audit takes ten minutes.

What a good DPA negotiation looks like

One pass, four asks: general sub-processor authorisation with notice; audits documentation-first with one on-site a year; liability aggregated with and capped by the master agreement, with a data super-cap if needed; and a TOMs annex you wrote rather than one you accepted. Everything else in the template, accept. That negotiation takes one round and does not put the deal at risk, which is the entire objective.