# How to Draft and Review a Data Processing Agreement (DPA)

> What a DPA must contain under UK GDPR Article 28, the clauses that are actually negotiated, international transfer mechanisms, and what to check when a suppli

**Author:** Imad Mohammed Nazar  
**Category:** Guides  
**Published:** 2026-08-12  
**Reading time:** 13 min

An AI drafting tool can produce a workable data processing agreement in minutes by generating the Article 28 clauses, populating your processing details, and flagging where a supplier's version departs from a defensible baseline. The value is not the speed. It is that the tool holds a consistent standard across every DPA you sign, so you stop accepting weak terms because you were busy.

But a DPA is only as good as the facts behind it. The clauses are largely mandated by UK GDPR Article 28, so drafting them is the easy part. The hard part is describing the processing accurately, choosing the right international transfer mechanism, and reading what a supplier sends you closely enough to catch the sub-processor and liability terms they have quietly rewritten in their favour. This article covers all three.

## What a DPA is and when you actually need one

A data processing agreement is the contract that governs what a processor may do with personal data on behalf of a controller. Under UK GDPR Article 28(3), processing by a processor must be governed by a written contract that binds the processor to the controller and sets out specific terms. If you share personal data with a supplier who processes it for you, you are legally required to have one in place.

Work out your role before you draft anything, because the clauses follow from it:

- **Controller to processor.** You decide why and how personal data is processed; the supplier processes it on your instructions. This is the classic DPA and what Article 28 addresses. Example: you use a payroll bureau.
- **Controller to controller.** Both parties determine their own purposes independently. You do not need an Article 28 DPA; you need a data sharing agreement instead.
- **Joint controllers.** You jointly determine purposes and means. Article 26 applies and you need an arrangement setting out respective responsibilities.

Getting the role wrong is the most common early mistake. A supplier who calls itself a processor but reserves the right to use your data for its own product development is behaving as a controller for that activity, and your DPA will not cover it. Read what they actually do, not the label they use.

## The clauses UK GDPR Article 28 requires

Article 28(3) sets a mandatory floor. Every compliant DPA must contain these, and any version missing one is defective regardless of how polished it looks:

1. **Processing on documented instructions only.** The processor acts only on your written instructions, including on international transfers, unless required by law to do otherwise.
2. **Confidentiality.** Persons authorised to process the data are bound by confidentiality obligations.
3. **Security measures.** The processor takes all measures required under Article 32, meaning technical and organisational measures appropriate to the risk.
4. **Sub-processor controls.** The processor does not engage another processor without prior authorisation, and imposes the same data protection obligations on any sub-processor it does engage.
5. **Assistance with data subject rights.** The processor helps you respond to access, erasure, rectification and other data subject requests.
6. **Assistance with compliance obligations.** The processor assists with security, breach notification, data protection impact assessments and prior consultation with the ICO.
7. **Deletion or return at end of contract.** On termination, the processor deletes or returns the data at your choice, and deletes existing copies unless law requires retention.
8. **Audit and information rights.** The processor makes available all information needed to demonstrate compliance and allows audits and inspections.

Beyond the eight, a usable DPA also needs the processing details required by Article 28(3): the subject matter, duration, nature and purpose of processing, the types of personal data, and the categories of data subjects. These usually sit in a schedule. If that schedule is blank or generic, the DPA is not doing its job, because it fails to define what the processor is actually permitted to do.

A tool built to [generate first-draft contracts from your own standards](https://www.genieai.co/use-case/create-contracts) matters here precisely because these eight are non-negotiable in substance. You want them present and correctly worded every time, without relying on someone remembering the list.

## The clauses that are actually negotiated

The Article 28 floor is rarely where the argument happens. Suppliers accept the mandatory obligations and then push back on how burdensome they are in practice. These are the terms worth your attention, roughly in order of how often they get contested:

### Sub-processor authorisation

There are two models. **Specific authorisation** means the processor names each sub-processor and needs your consent to add one. **General authorisation** means you consent to a list and the processor may add new ones provided it notifies you and gives you a chance to object. Most suppliers want general authorisation with a short objection window. Negotiate the notice period and be clear on what happens if you object: does the supplier find an alternative, or can it terminate and leave you to migrate?

### Audit rights

You have a right to audit under Article 28, but suppliers resist on-site inspections at will. A common compromise: the supplier provides a recognised third-party audit report or certification annually, and on-site audits are permitted only where that is insufficient, on reasonable notice, at your cost, and not more than once a year absent a breach. That is usually acceptable. What is not acceptable is a clause that limits you to reviewing a self-assessment questionnaire.

### Liability and indemnities

This is where the real money sits. Watch for a data protection liability cap set at a trivial figure, or the whole DPA being swept under a general liability cap in the master agreement that is too low for a data breach. Data breaches carry regulatory fines and third-party claims that dwarf typical contract values. Push for a separate, higher cap for data protection breaches, or at least an uncapped carve-out for the supplier's breach of its confidentiality and security obligations.

### Breach notification timing

You must notify the ICO within 72 hours of becoming aware of a reportable breach. You cannot do that if your processor takes a week to tell you. Insist on notification "without undue delay and in any event within 24 to 48 hours" of the processor becoming aware, with enough detail for you to assess your own obligations.

### Cost of assistance

Suppliers increasingly try to charge for assisting with data subject requests and impact assessments. Some assistance cost is reasonable for high-volume or complex requests. A blanket right to charge for everything, including routine breach cooperation, is not.

| Clause | Supplier-friendly position | Balanced position to aim for |
| --- | --- | --- |
| Sub-processors | General authorisation, no meaningful notice | General authorisation with prior notice and a genuine right to object |
| Audit | Self-assessment questionnaire only | Third-party report plus on-site audit where justified |
| Liability | Data claims under a low general cap | Separate higher cap or carve-out for security and confidentiality breaches |
| Breach notice | "Without undue delay", undefined | Fixed window of 24 to 48 hours with required detail |
| Assistance costs | Chargeable across the board | Free for routine cooperation, chargeable only for disproportionate effort |

## International transfer mechanisms you need to get right

If personal data leaves the UK, or a sub-processor sits outside it, the DPA needs a lawful transfer mechanism. This is the part suppliers most often leave blank or handle wrongly. Your options under the UK regime:

- **Adequacy.** The UK government has decided certain countries offer adequate protection. Transfers to those countries need no additional mechanism. The EU/EEA is covered, as are countries on the UK adequacy list. Check the current list rather than assuming.
- **UK Addendum to the EU Standard Contractual Clauses.** The most common route. You use the EU SCCs and bolt on the UK's International Data Transfer Addendum issued by the ICO.
- **International Data Transfer Agreement (IDTA).** The UK's standalone standard clauses, used instead of the EU SCCs plus Addendum. Both are valid; the choice is often about what the counterparty already uses.
- **US transfers.** There is a UK extension to the EU-US Data Privacy Framework covering certified US recipients. Whether a specific US supplier is covered is a fact you must verify against the framework list, not assume from a clause.

Whichever mechanism applies, a transfer risk assessment is expected. That means checking whether the laws of the destination country undermine the protection the clauses promise, and documenting your conclusion. For most routine SaaS suppliers in adequate countries this is light-touch. For data going somewhere without adequacy, it needs real thought. Do not let a supplier tell you the SCCs alone are enough; the clauses are the mechanism, and the assessment is a separate obligation on you.

## What to check when a supplier sends you their DPA

Most of the time you will not be drafting from scratch. A supplier sends you their standard DPA and asks you to sign. Their draft is written to protect them. Work through this checklist before you agree:

1. **Is the processing schedule filled in and accurate?** Blank or boilerplate schedules are the single most common defect. It must reflect your actual data and purposes.
2. **Does it restrict processing to your instructions only?** Watch for language letting the supplier use "anonymised" or "aggregated" data for its own purposes. That may be fine, but decide deliberately, and check the anonymisation is real.
3. **What is the sub-processor model and objection right?** Confirm you get notice and can object. Ask for the current sub-processor list before signing.
4. **How fast must they notify you of a breach?** Pin down the window. "Without undue delay" alone is too soft.
5. **Where is your data processed and stored?** Identify every country involved, including sub-processors, and confirm the transfer mechanism for each.
6. **How is liability capped?** Trace the cap through to the master agreement. Make sure data breaches are not buried under a low general limit.
7. **What happens to data on exit?** Confirm deletion or return, the format of any return, and the timescale.
8. **Do the security measures actually say anything?** A schedule that lists concrete controls is worth more than one that repeats "appropriate technical and organisational measures" and stops there.

Running this consistently across dozens of incoming DPAs is where teams slip, because the twentieth supplier draft gets less attention than the first. This is exactly the kind of repetitive, high-stakes review where an AI tool earns its place: it reads each supplier's version against your positions and surfaces the deviations, so a human reviews the exceptions rather than re-reading the same boilerplate. GenieAI supports this [review and negotiation workflow](https://www.genieai.co/use-case/review-negotiate) against a playbook you define, and because it works [inside Word](https://www.genieai.co/use-case/word-add-in), the redlining happens where your team already sits. GenieAI is certified to ISO/IEC 27001:2022, which matters when the documents themselves concern data protection.

## How AI drafting and review actually fit into DPA work

Used well, an AI tool does three distinct jobs on DPAs, and it helps to keep them separate:

1. **Generation.** Produce a first draft that already contains all eight Article 28 obligations, your preferred negotiated positions, and the correct transfer mechanism, populated with the processing details you supply.
2. **Review against a standard.** Take an incoming supplier draft and compare it to your baseline, flagging missing mandatory clauses and terms that fall below your positions on sub-processors, liability, breach notice and audit.
3. **Consistency across a portfolio.** Apply the same standard every time, so the DPA you sign in December is as robust as the one you scrutinised in January.

The point is risk management, not turnaround. A DPA that is signed quickly but caps data breach liability at a month's fees has cost you nothing in time and a great deal in exposure. The teams that get the most from tooling are the ones who first agree their negotiated positions, write them down as a playbook, and then let the tool enforce that playbook at scale. Sectors with heavy supplier chains and sensitive data, such as [technology](https://www.genieai.co/industry/technology) and [energy businesses](https://www.genieai.co/industry/energy), tend to feel this most, because the volume of DPAs makes manual consistency impractical. For a view of how this sits within wider commercial contracting, see how [sales and commercial teams](https://www.genieai.co/legal-ai-for-teams/sales) handle agreements at volume, and the underlying [security posture](https://www.genieai.co/security) that makes it appropriate for data protection documents.

None of this removes the need for judgement. Whether to accept a particular liability cap, or whether a transfer to a given country is defensible, is a decision that depends on your risk appetite and the facts. The tool makes sure you are making that decision knowingly, on a complete and correctly drafted document, rather than discovering the gap after an incident.

## Frequently asked questions

### Can an AI tool draft a legally compliant DPA?

Yes, an AI tool can generate a DPA containing all the mandatory Article 28 clauses and populate the processing details you provide. What it cannot do is verify the facts for you, such as which countries your data touches or whether a given liability cap suits your risk. Treat the output as a strong first draft that a knowledgeable person confirms against your actual processing arrangements.

### What must a DPA contain under UK GDPR?

Article 28(3) requires eight core terms: processing on documented instructions, confidentiality of authorised staff, Article 32 security measures, sub-processor controls, assistance with data subject rights, assistance with wider compliance obligations, deletion or return of data at the end, and audit and information rights. It must also record the subject matter, duration, nature and purpose of processing, the types of personal data and the categories of data subjects.

### Do I need a DPA if my supplier is in an adequate country?

Yes. Adequacy affects only whether you need an extra transfer mechanism for personal data leaving the UK. It does not remove the requirement for a written Article 28 contract. If a supplier processes personal data on your behalf, you need a DPA regardless of where they are located.

### What is the difference between the IDTA and the UK Addendum?

Both are valid UK mechanisms for restricted international transfers. The IDTA is a standalone UK transfer agreement. The UK Addendum is a short document that bolts onto the EU Standard Contractual Clauses so they work under the UK regime. Which you use is usually driven by what the counterparty already has in place; the protection is comparable.

### What is the most common problem in a supplier's DPA?

An empty or generic processing schedule, closely followed by a liability cap that puts data breaches under a low general limit. The schedule defines what the processor is actually allowed to do, so a blank one makes the whole agreement vague. Always check the schedule reflects your real data and purposes, and trace the liability cap through to the master agreement.

### How quickly must a processor tell me about a data breach?

The law does not set a fixed processor deadline, but you must report qualifying breaches to the ICO within 72 hours of becoming aware. To meet that, negotiate a firm notification window into the DPA, typically 24 to 48 hours from the processor becoming aware, with enough detail for you to assess your own reporting duties. Vague "without undue delay" wording alone is not enough.

### Can GenieAI review a DPA a supplier sent us?

Yes. Many teams use GenieAI for review alone, comparing an incoming supplier DPA against their agreed positions and flagging missing Article 28 clauses and terms that fall short on sub-processors, liability, audit or breach notice. It works inside Word so redlines happen where your team already drafts, and it applies the same standard to every supplier draft.

### Is a DPA the same as a data sharing agreement?

No. A DPA governs a controller-to-processor relationship under Article 28, where the processor acts on your instructions. A data sharing agreement governs a controller-to-controller relationship, where each party decides its own purposes. Using the wrong one leaves the actual relationship uncovered, so confirm each party's role before you pick the document.

---

This is the Markdown representation of [https://www.genieai.co/blog/how-to-draft-and-review-a-data-processing-agreement](https://www.genieai.co/blog/how-to-draft-and-review-a-data-processing-agreement), provided for AI agents and crawlers. The HTML page is canonical. See [/llms.txt](https://www.genieai.co/llms.txt) for the full content map.