A firm signs up a new transcription tool that runs on AI. Procurement handles it. The vendor sends its standard pack, someone skims the commercial terms, and the data processing agreement, a two-page annex at the back, gets signed with everything else. Nobody reads it closely, because it is "just the DPA."
Six months later the vendor has a security incident, or the ICO asks a routine question about how the firm governs its suppliers. Now someone reads the annex properly, and finds it does not require the vendor to tell the firm about a breach within any fixed time, does not stop the vendor bringing in new sub-processors, and does not say what happens to the firm's data when the contract ends.
That is the problem with treating Article 28 as a formality. The DPA is not paperwork that proves a relationship exists. It is the only mechanism that binds your supplier to the obligations you carry. When a term is missing, you have not saved time. You have removed a control you are legally required to have.
What Article 28 actually is
Under the UK GDPR, if your firm decides why and how personal data is processed, you are a controller. Anyone who processes that data on your behalf is a processor. The moment you hand personal data to a third party to do something with it, you have engaged a processor, and Article 28 applies.
That net is wider than most firms assume. Your cloud storage provider is a processor. Your practice management host is a processor. An outsourced typing service is a processor. An e-disclosure platform is a processor. An AI vendor that ingests documents containing personal data to summarise, review, or analyse them is a processor. Each one is handling your clients' personal data, which means each one needs a contract that meets Article 28.
Two obligations sit at the top. Article 28(1) says you may only use processors that provide "sufficient guarantees" they will meet the UK GDPR's requirements, so the diligence comes before the signature. Article 28(3) says the processing "shall be governed by a contract," in writing, that binds the processor and contains a specific list of terms. Not a handshake, not an assumption, not the vendor's marketing about how seriously it takes security. A contract, with the terms the article names.
Why it is not just a formality
Three reasons the DPA earns its place, none of them administrative.
The first is that it is the law, and the penalty is real for both sides. Failing to put a compliant Article 28 contract in place is itself an infringement, and it is one the ICO can act on independently of any breach. Both the controller and the processor can be liable for not having the required terms. You do not need anything to go wrong for the absence to be the problem.
The second is that the DPA is how your obligations flow downhill. You remain responsible to the ICO and to your clients for personal data even after it leaves your building. The only thing that translates that responsibility into control over the supplier is the contract. Without the deletion term, you cannot compel return or destruction of your data. Without the sub-processor term, you have no say in who else touches it. The contract is the leash; a missing term is a length of leash that was never attached.
The third is specific to law firms. Client data is not just personal data, it is confidential, and SRA rule 6.3 requires you to keep the affairs of current and former clients confidential. A processor arrangement that does not properly bind a supplier to confidentiality and security is a data-protection gap and a professional-conduct gap at the same time. Two regulators, one weak contract.
Field note: When I look at a firm's supplier stack, the question that finds the gap fastest is not "do you have DPAs?" Almost everyone does. It is "for your three most data-heavy suppliers, can you point to the clause that says they delete our data when we leave, and the clause that stops them adding a new sub-processor without telling you?" The DPA usually exists. Those two clauses often do not.
What Article 28(3) requires, term by term
A compliant contract has two layers. First it must set out the shape of the processing: the subject-matter and duration, the nature and purpose, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. Then Article 28(3) requires eight specific stipulations. Miss any one and the contract is not compliant.
| The required term | What the contract must bind the processor to | What breaks if it is missing |
|---|---|---|
| Documented instructions | Process only on your documented instructions, including on international transfers | The processor can use your data for its own ends, including training its models |
| Duty of confidence | Ensure the people it authorises to process the data are under a duty of confidentiality | No contractual confidentiality obligation on the individuals handling client files |
| Security | Take all measures required by Article 32 (appropriate technical and organisational security) | No agreed security baseline to hold the supplier to after an incident |
| Sub-processors | Not engage another processor without your authorisation, and flow the same terms down | The supplier moves your data to a new sub-processor you never approved |
| Data subjects' rights | Assist you, by appropriate measures, to respond to requests to exercise rights | A DSAR reaches data held by the processor and you cannot get it out in time |
| Assisting the controller | Help you meet Articles 32 to 36: security, breach notification, DPIAs | No obligation to tell you about a breach, so your own 72-hour clock starts late |
| End-of-contract provisions | Delete or return all the personal data at the end, and delete existing copies | Your data lingers on a former supplier's systems indefinitely |
| Audits and inspections | Make available the information needed to demonstrate compliance, and allow audits | No right to verify anything the supplier claims about how it handles your data |
The eight are cumulative, not a menu. A DPA that nails seven and omits the sub-processor term is still a non-compliant contract, and the omitted term is usually the one that bites.
What a missing term looks like in practice
Take the sub-processor clause, because it is the one AI has made urgent. An AI vendor that has no binding sub-processor obligation in your DPA can route your documents through a new model provider, a new hosting region, or a new analytics partner, and the first you hear of it is when you read a press release. Your clients' data has moved to a party you never assessed, and you have no contractual footing to object.
Or take the breach-assistance term. If the contract does not require the processor to notify you of a personal data breach without undue delay, your own Article 33 obligation to report certain breaches to the ICO within 72 hours becomes impossible to meet, because your clock only starts when you find out, and you have not obliged anyone to tell you.
Or the deletion term. Without it, "we've stopped using that vendor" does not mean the vendor has stopped holding your data. Years of client personal data can sit on a decommissioned supplier's storage with no contractual route to compel its destruction. That is a live risk you cannot close, created by a clause that was never negotiated.
None of these is exotic. Each is a specific, foreseeable failure that the corresponding Article 28 term exists precisely to prevent.
How you check this at volume
Reading one DPA against the eight requirements is a careful hour. The problem is that a firm does not have one DPA. It has dozens: every cloud service, every outsourced function, every practice tool, every AI vendor, each with its own annex written by the supplier to favour the supplier, and each renewed or amended on its own cycle. Reviewing all of them by hand, thoroughly, against the same checklist, is the kind of task that gets started and never finished.
This is where a structured review earns its keep. Instead of one-by-one manual reading, you run each processor agreement against the exact Article 28(3) requirements, flag the terms that are missing or weak, and produce a draft for the DPO that says which supplier is short which clause. The reading is consistent, the checklist never drifts, and the output is a prioritised list of gaps rather than a vague sense that "the DPAs need looking at."
That is what the Privacy and Data Protection Agent does with processor agreements: batch review against the UK GDPR Article 28 requirements, missing terms surfaced in a draft for the DPO, nothing signed off automatically. It is the same governed pattern that runs the firm's DSAR clock and its PIA-versus-DPIA triage. And when the supplier under review is an AI tool, the contract question sits next to the harder one of whether client data should be leaving your environment at all, which we cover in self-hosted LegalAI Space.
LegalAI Space builds AI agents for legal teams with a governance layer that makes every output verifiable, compliant, and audit-ready. Sign up for early access or book a pilot call with Founder Daman Kaur.
FAQ
What is Article 28 of the UK GDPR? Article 28 governs the relationship between a controller and a processor. It requires that any processing carried out on a controller's behalf be governed by a written contract containing a specific set of terms, and that controllers only use processors offering sufficient guarantees of compliance. For a law firm, most third-party suppliers that handle client personal data, from cloud hosts to AI vendors, are processors caught by Article 28.
Is a data processing agreement legally required? Yes. Article 28(3) requires the processing to be governed by a binding written contract. Not having a compliant contract in place is itself an infringement of the UK GDPR that the ICO can act on, independently of whether any data has been mishandled.
What must an Article 28 contract include? It must set out the subject-matter, duration, nature and purpose of the processing, the type of personal data and categories of data subjects, and the controller's obligations and rights. It must then bind the processor to eight terms: processing only on documented instructions, confidentiality, Article 32 security, sub-processor conditions, assisting with data subjects' rights, assisting with Articles 32 to 36, deletion or return at the end, and making information available for audits and inspections.
Who is liable if there is no compliant DPA? Both parties can be. The obligation to have a compliant Article 28 contract falls on the controller and the processor, so the absence of required terms can expose both to regulatory action, separately from any liability for a breach that follows.
Is an AI vendor a processor? Usually yes. If an AI tool processes personal data on your instructions, for example ingesting documents that contain personal data to review or summarise them, it is acting as your processor and needs an Article 28 contract. The sub-processor and documented-instructions terms matter especially, because they govern whether the vendor can reuse your data or route it to further providers.
Do we need a new agreement for each sub-processor? You do not sign each sub-processor directly, but your contract with the processor must require it to obtain your authorisation before engaging any sub-processor and to impose the same data-protection obligations on it. Without that term, sub-processing happens outside your control.
Sources
-
UK GDPR, Article 28. Article 28(1) requires controllers to use only processors providing sufficient guarantees; Article 28(3) requires a binding written contract setting out the subject-matter, duration, nature and purpose of processing, type of personal data and categories of data subjects, and stipulating the eight terms: documented instructions, confidentiality, security (Article 32), sub-processor conditions, assistance with data subjects' rights, assistance with Articles 32 to 36, deletion or return, and audits and inspections.
-
ICO, Contracts and liabilities between controllers and processors: what needs to be included in the contract. Sets out the mandatory contract terms and confirms that both controllers and processors have obligations under Article 28.
-
UK GDPR, Article 33. Requires notification of a personal data breach to the ICO without undue delay and, where feasible, within 72 hours of the controller becoming aware of it, which depends on processors notifying the controller promptly.
-
SRA Code of Conduct for Firms, rule 6.3. Requires firms to keep the affairs of current and former clients confidential unless disclosure is required or permitted by law or the client consents, an obligation that a processor arrangement must not undermine.