Data processing agreement: the clauses that are not negotiable

A data processing agreement — a DPA, sometimes a data processing addendum — is the contract required whenever one organisation processes personal data on behalf of another. The GDPR does not merely encourage it: Article 28 requires a written contract and sets out what it must contain, so a DPA missing a required term is deficient regardless of how commercially sensible the rest of it is.

Most organisations meet it from both sides. You sign your customers’ DPAs as a processor, and you sign your vendors’ as a controller — and the two stacks are usually managed by different people who never compare them, which is how a company ends up promising customers something its own subprocessors have not promised it.

What Article 28 requires a data processing agreement to say

• The subject matter, duration, nature and purpose of the processing, the type of personal data and the categories of data subject — usually as an annex rather than in the body.
• That the processor acts only on documented instructions from the controller, including on international transfers.
• A confidentiality commitment binding the people who process the data.
• Security measures appropriate to the risk.
• The conditions for engaging subprocessors: prior authorisation, and flow-down of the same obligations.
• Assistance with data subject rights requests.
• Assistance with breach notification, DPIAs and prior consultation.
• Deletion or return of the data at the end of the service, at the controller’s choice.
• Provision of information needed to demonstrate compliance, and submission to audits or inspections.

Subprocessors are where the disputes are

Two models exist. General authorisation, where the processor may add subprocessors provided it notifies the controller and gives them a chance to object, and specific authorisation, where each addition needs consent. Vendors prefer the first; enterprise customers ask for the second and rarely get it. What matters more than which model you agree is whether the notice mechanism actually works: a subprocessor list on a web page with an email subscription is standard and acceptable, a clause saying you will be notified with no channel specified is a clause that will never operate. Check the list you rely on, and check that your own list is current — an unnotified addition is a breach of contract that surfaces during an audit.

Read the audit clause on both sides before signing. Customers ask for on-site audit rights; processors offer a third-party report instead. Both are common and both are workable, but a small vendor that has promised fifty enterprise customers an on-site audit right has promised something it cannot survive being asked for.

The annexes are the part that ages

The body of a DPA rarely changes; the annexes describing the processing, the security measures and the subprocessors change constantly and are almost never updated after signature. That gap is what an auditor finds. Give the annexes an owner and a review date, keep the version that was signed with each customer, and treat a change to your security measures or subprocessor list as a trigger to check what you have promised — which is easier when the promises are in one register rather than in fifty PDFs.

Signing and keeping them

Ettex Signature collects the signatures without a printing round, Ettex Records keeps the executed agreements per customer and per vendor with the annexes and review dates visible, and Ettex Docs holds your own template with version history so you can tell which version a customer signed. The transfer terms that usually sit alongside it are covered in standard contractual clauses, and the underlying inventory in record of processing activities.

Plainly: not legal advice, and a DPA is not a document to assemble from a blog. Article 28 sets the required content, your own risk position sets the rest, and the audit and liability clauses in particular are worth having drafted properly once.