How do you spot the clauses that will hurt you later? This guide walks through the most common DPA red flags, the minimum content GDPR actually requires, and why AI-assisted review has become the realistic answer for legal teams drowning in vendor paperwork.

Introduction

Almost every modern business relies on external service providers to process personal data: cloud hosting, CRM platforms, payroll systems, customer support tools, analytics, HR software. Every one of those relationships triggers the same legal requirement: a Data Processing Agreement (DPA) under Art. 28 GDPR.

In theory, a DPA is a standard contract. In practice, it is one of the most demanding, time-pressured and error-prone documents that legal, privacy and procurement teams handle. Vendor-form DPAs are long, technically dense, often unbalanced, and frequently land on a reviewer's desk hours before a tool is supposed to go live.

This article covers:

• What a DPA is and when it is legally required
• The minimum content GDPR mandates
• The biggest red flags to watch for when reviewing a vendor DPA
• Why manual review consistently falls short
• How AI-assisted review changes the picture

‍

Sign up for our free Newsletter about transforming Legal Workflows with our Legal Tech Software

1. What is a Data Processing Agreement?

A Data Processing Agreement is a legally binding contract between two roles:

• The controller — the company that decides why and how personal data is processed.
• The processor — the service provider that processes that data on the controller's behalf.

Under Art. 28 GDPR, this contract is mandatory whenever a processor handles personal data for a controller. It sets out the conditions of processing, the security measures the processor must apply, the rights the controller retains, and what happens to the data when the relationship ends.

A DPA is not optional paperwork. Missing or inadequate DPAs are a documented source of regulatory fines across the EU, and the absence of a DPA is itself a sanctionable infringement, regardless of whether anything else went wrong with the data.

2. When is a DPA required?

A DPA must be in place before processing begins, in any situation where an external provider processes personal data on instruction. Typical scenarios include:

• Cloud-based software (CRM, HR, collaboration, analytics)
• Hosting and infrastructure providers
• IT maintenance and remote support
• Payroll and finance outsourcing
• Customer support and call centres
• Marketing automation, email and tracking tools
• Data destruction and archiving providers

If a vendor touches personal data on your behalf, you need a DPA and the obligation rests on the controller to make sure one exists. In practice, the processor usually provides the DPA as a templated document drafted in their favour, which makes the controller's job one of careful review and negotiation rather than drafting from scratch; except in enterprise procurement or regulated industries, where large controllers typically impose their own template.

3. Minimum content of a DPA under Art. 28 GDPR

A compliant DPA must address, at minimum:

• Subject matter, nature, duration and purpose of processing
• Categories of personal data and categories of data subjects
• Obligations and rights of the controller
• Processor obligations: confidentiality, technical and organisational measures (TOMs), duty to assist
• Right to issue instructions
• Sub-processor governance (authorisation, notification, flow-down obligations)
• Return or deletion of personal data at the end of processing
• Documentation and audit rights
• Support for data subject rights requests
• Support for breach notification and security incident handling

These are the legal minimums. Real DPAs are far longer and more complex typically 20 to 30 pages with technical annexes, sub-processor lists, separate transfer mechanisms (SCCs, TIAs), and SLA cross-references. The complexity is precisely where reviewers miss things.

4. The biggest red flags in vendor DPAs

This is where most of the practical risk sits. Vendors draft their DPAs in their own favour, and the boilerplate that ends up in your inbox often contains clauses that look reasonable on first read but quietly shift risk back onto the controller. The most frequent red flags fall into six categories.

Red flag 1: Vague processing scope

The single most common deficiency. Generic language like "processing as required to deliver the services" does not satisfy Art. 28(3) GDPR. The DPA needs to specify the subject matter, duration, nature, purpose, type of personal data and categories of data subjects. If the commercial section of the agreement carefully describes the service but the data protection section is silent on what data is actually processed, that is a gap the controller has to close.

Watch also for the description of the service itself being absent from the DPA. As it is essential and without it, you cannot perform a proper risk assessment.

Red flag 2: Sub-processor clauses with no meaningful control

Sub-processors are where many DPAs quietly weaken controller rights. Look for:

• Notice periods that are too short. Many SaaS vendors list sub-processors on a webpage annex and reserve the right to update it with minimal notice, sometimes just a few days. A reasonable window is 1 to 3 months, or at least 15 to 30 days.
• No genuine right to object. A right to object that comes with no remedy (such as termination) is illusory.
• No flow-down obligation. The processor must contractually impose the same Art. 28 obligations on its sub-processors. If that is missing, the chain of accountability breaks.
• Blanket pre-approval. "The processor may engage sub-processors at any time" without notice or objection rights should not be accepted.

Critical sub-processing — hosting, support, analytics — deserves particular scrutiny, including where data will sit and what transfer mechanism applies.

Red flag 3: Audit rights that exist on paper only

Article 28(3)(h) GDPR requires the processor to allow for and contribute to audits conducted by the controller or an auditor mandated by the controller. The text is short; what it means in practice has been worked out in detail by the European Data Protection Board and the European Data Protection Supervisor in their joint opinions on the EU Art. 28 standard contractual clauses. Two principles from that work matter for spotting red flags:

• The choice of auditor belongs to the controller. The processor may propose one, but cannot impose one. Clauses that let the processor decide who audits it — or that limit verification exclusively to a third-party certification chosen by the processor (ISO 27001, SOC 2) — go too far. Certifications are a legitimate way to narrow the scope of audits, but they cannot replace the right entirely.
• The GDPR does not regulate audit costs, so the parties are free to allocate them by contract. What is not acceptable is an allocation so unbalanced that it defeats the right in practice. A processor that unilaterally sets the requirements for audit materials and at the same time refuses any cost-sharing, or attaches fees so disproportionate that the controller would never realistically exercise its right, has crossed that line. The EDPB and EDPS have been explicit that disproportionate or excessive fees cannot be used to dissuade the controller from auditing.

A separate red flag sits next to this: processors charging the controller for delivering documentation about the processor's own compliance with the DPA and the GDPR. Supplying such evidence is a baseline Art. 28 obligation and should not be billed as an extra service.

A fair audit clause balances the controller's right to verify with reasonable limits — working hours, prior notice, confidentiality undertakings, the right to object to a competitor as auditor, and a sensible cadence (usually once per year plus on cause).

Red flag 4: Missing or weak deletion and return clause

The DPA must say what happens to the data at termination. Is it returned, deleted, or both, on what timeline, and with what evidence. A vague reference in a service agreement ("we delete data after 90 days") is not the same as a contractual obligation in the DPA. Look for explicit handling of backups, certification of deletion, and a clear cut-off.

Red flag 5: Vague TOMs, unclear breach notification, unbalanced liability

A cluster of clauses worth singling out:

• TOMs that just say "appropriate measures." Security measures must be specific: encryption, access controls, logging, pseudonymisation, testing regimes.
• Breach notification without teeth. No deadlines, no contact persons, no required content. "Without undue delay" on its own — the GDPR's own phrasing — is increasingly treated as too soft in DPA negotiations because it leaves the timing open to interpretation and consumes the controller's own 72-hour regulatory window. Controllers should push for a concrete backstop: typically "without undue delay, and in any event within 24 to 48 hours of the processor becoming aware," together with a defined contact point and a minimum content list (nature of the breach, data categories and approximate number of records, likely consequences, mitigation measures taken).
• Liability capped at the annual fee. Standard for commercial risk, but inappropriate in data protection contexts where fines and damages can vastly exceed the contract value.

Red flag 6: Stale DPAs after scope changes

A non-clause red flag, but a common compliance failure: the DPA is signed, filed, and never revisited even when processing changes substantially. If a vendor starts processing a new data category (e.g. health data when they previously handled only contact data), or moves hosting regions, or adds an AI feature that processes personal data in a new way, the DPA needs to be updated. Many do not get touched.

5. Why manual DPA review keeps failing

Because of their legal nature, DPAs tend to be structured in a very similar way from one vendor to the next, and that is precisely where the trap sits. The devil is in the detail, and the detail lives in long documents that are tedious to read in full. In most cases the DPA is broadly fine, or only needs minor iterations, and the immediate risk feels low. But the work still has to be done with full precision: if one of the red flags above slips through, the consequences can be severe. There could be regulatory exposure, breach liability, an audit right you cannot exercise, sub-processors you never approved. That is what makes DPA review so awkward in practice. It is high-stakes work that is mostly low-yield per page read, which is a poor match for how human attention actually behaves.

On top of that, three structural factors compound the problem:

No uniform internal standard. Many teams lack a written playbook with preferred, fallback and unacceptable positions. Reviews depend on whoever happens to pick up the contract, which produces inconsistent risk assessments, no comparability between vendors, and discretion in places that should be hard-coded.

Length and technical complexity. TOM annexes, sub-processor lists, SCCs, transfer impact assessments and SLA cross-references push a single DPA to 30 pages plus. Under time pressure, reviewers read selectively. Important clauses buried in Exhibit C get scanned, not analysed.

Time pressure during onboarding. Procurement is pushing. IT is waiting. Marketing wants the tool live this week. DPA review almost always sits on the critical path of a launch, and the time available rarely matches the work required.

The result: even teams that genuinely understand DPAs end up signing agreements with vague scope, weak sub-processor controls, illusory audit rights, or missing deletion clauses. The legal expertise exists; the review capacity does not.

6. How AI changes DPA review

Of course, AI-assisted review does not replace legal judgment. But it is able to change what legal teams spend their time on. Used with a proper playbook, it addresses each of the three structural failure modes above.

Consistent standards on every review

With AI applying a defined playbook to every incoming DPA, the same clauses are checked against the same preferred, fallback and unacceptable positions regardless of who is reviewing or how busy they are. Each item is categorised (typically major, minor, low risk), and the review becomes reproducible and comparable across vendors. Subjective, case-by-case decisions become an objectified risk assessment.

Speed against length

The DPA review process — depending on the tool you are using — works directly inside Word: load the document, the system detects document type, language and jurisdiction, applies a standard playbook plus any custom DPA playbook, and runs every checklist item against the contract — generating redlines and explanatory comments inline. What takes a human reviewer a few hours to do thoroughly takes minutes. More importantly, the AI reads every clause, not just the ones a tired reviewer remembered to check.

Legal and technical knowledge applied together

A well-built playbook combines Art. 28 GDPR requirements, technical security expectations (encryption, IAM, logging), sub-processor governance, and international transfer mechanisms (SCCs, TIAs). The AI applies that combined knowledge to every DPA in the same way — bringing the legal and technical perspectives together that, in manual review, often sit in different heads on different teams.

A practical playbook to start from

If you are building one, the core items every DPA playbook should cover:

• Scope and purpose of processing
• Fair, workable audit rights with reasonable limits
• Breach notification timelines and obligations
• Termination, deletion and return mechanics
• Sub-processor authorisation, notice periods and flow-down
• TOMs at a specific (not generic) level
• International transfer mechanisms

Secondary items worth including: duration of processing, data categories, data subject categories, controller/processor rights and obligations, and any industry-specific requirements.

Scalable, documented quality

The downstream effect is what matters operationally: faster approvals, fewer back-and-forth queries to legal, clear decision bases for procurement and business owners, and a documented trail of how every DPA was reviewed against the company's standard which is exactly what auditors and supervisory authorities want to see.

DPA review alone is not a business case

A final point worth making honestly: it does not make sense to invest in a legal tech tool just to review DPAs. DPA review is one use case, and a good one, and a high-volume one, but a single use case is rarely enough to justify the cost, the change management, and the onboarding effort of a new platform. The right way to think about it is broader. Most in-house legal work splits into two categories: judgment-heavy work that requires a lawyer's brain (negotiating a strategic deal, advising on a regulatory grey area, structuring a transaction) and high-volume, repetitive work that mostly requires consistency and attention (NDAs, vendor terms, DPAs, employment templates, supplier contracts, MSAs against a playbook, intake triage, first-pass redlining). The second category is where AI earns its keep. It is the work that fills calendars, blocks faster business decisions, and burns out legal teams. And, it is also the work where AI is genuinely strong, because consistency, completeness and speed are exactly what it brings. A legal tech tool worth adopting should handle DPAs and NDAs and vendor MSAs and employment paperwork and whatever other recurring contract type a team sees regularly. DPA review is a good place to start and prove the value, but it should never be the whole reason to buy.

Picking the right first use case is half the battle. Our Legal Tech Adoption Guide walks through how to assess your team's bottlenecks, prioritise what to automate, and run a structured pilot — so you invest in the tool that actually fits your workflow.

‍

Conclusion

The Data Processing Agreement is generally an important contract in business interactions, and easy to get wrong. The legal requirements are not subtle — Art. 28 GDPR is explicit about what a DPA must contain — but vendor-form drafting, time pressure, technical complexity and inconsistent internal standards push real-world DPAs well below that bar.

The biggest red flags repeat across vendors: vague scope, weak sub-processor controls, illusory audit rights, missing deletion clauses, generic TOMs, and DPAs that are never updated when processing changes. Spotting them is not hard for a trained reviewer who has time. The problem is that the time is almost never there.

AI-assisted review, anchored to a lawyer-built playbook, is the realistic answer: it standardises the review, accelerates it, and surfaces the clauses that matter. This leaves the legal team doing the judgment work the AI cannot do. It is not a replacement for expertise. It is what makes expertise scale.

‍