How to Review a Data Processing Agreement (2026 Checklist)

A data processing agreement (DPA) is the contract that lets one organisation process personal data on behalf of another. The customer (the controller) decides why and how the data is used; the vendor (the processor) acts on documented instructions. Under the GDPR and UK GDPR this contract is mandatory, and its minimum contents are set by Article 28. Reviewing a DPA well means checking that those required terms are present, that the security and sub-processor rules are real rather than decorative, and that the transfer and audit mechanics will actually work if you ever need them. This is a general checklist, not legal advice on your specific processing. ## The fast answer: what to check first Before the clause-by-clause read, confirm four things. First, the roles are stated correctly (who is controller, who is processor, and whether any activity is joint control). Second, there is a completed schedule describing the processing: subject matter, duration, nature and purpose, types of personal data, and categories of data subjects. A DPA with an empty or vague processing schedule is not finished. Third, the processor only acts on your documented instructions. Fourth, international transfers are covered by a valid mechanism. If any of these is missing, stop and fix it before reading further. ## Clause-by-clause review checklist ### Roles, scope and the processing schedule Read the schedule first. It should name the subject matter, the duration, the nature and purpose of processing, the data types and the data subject categories. These are not boilerplate; they define the boundary of what the processor may lawfully do. Check the purpose matches the main services agreement and nothing broader has crept in. ### Instructions and purpose limitation The processor must process only on your documented instructions, including for transfers, unless a law requires otherwise. If a law forces the processor to act, it should tell you first unless legally barred. Watch for language that lets the vendor use your data for its own analytics, product improvement or AI training; if that is intended it must be called out, not buried. ### Confidentiality Everyone the processor allows to access the data, including temporary and agency staff, must be under a duty of confidence. A single line ("personnel are bound by confidentiality") is acceptable if it clearly covers all such people. ### Security measures (Article 32) Look for specific technical and organisational measures, usually in an annex: encryption in transit and at rest, access controls, logging, backup and recovery, personnel vetting, and a tested incident process. Beware vague promises ("industry-standard security") with no annex. Security should be assessed against the risk of the processing, so sensitive data deserves stronger controls. ### Sub-processors This is where most DPAs are weak. Check three things: a current list of sub-processors (usually linked, with a date), a requirement that each sub-processor is bound by equivalent data-protection terms, and your right to be told of changes and to object. "General authorisation with prior notice and a right to object" is common and workable; "the processor may appoint any sub-processor at its discretion" is not. ### International transfers If data leaves its home jurisdiction, identify the transfer mechanism: an adequacy decision, the EU or UK standard contractual clauses, the UK International Data Transfer Agreement or Addendum, or binding corporate rules. For high-risk destinations a transfer impact assessment may be needed. Confirm the SCCs are the current version and the annexes are completed, not left blank. ### Assisting the controller The processor should help you respond to data subject rights (access, deletion, correction, objection) and help with your security, breach-notification and impact-assessment duties. Check whether this help is included or billed as a chargeable extra, and whether the response times are workable. ### Breach notification There should be a clear trigger ("without undue delay after becoming aware") and a defined set of information the processor will give you. Avoid soft wording like "as soon as reasonably practicable" with no outer limit. You are the one on a regulatory clock, so the processor's notice has to reach you fast enough to meet it. ### Audit and information rights You should be able to verify compliance, through information on request and, where justified, an audit or inspection. Many vendors offer a recognised third-party report (for example SOC 2 or ISO 27001) in place of on-site audits; that is reasonable, but keep a backstop right to audit where a report is not enough. ### End of contract: return and deletion At termination you should be able to choose return or deletion of the data, with deletion of copies unless retention is legally required. Check the time window and whether you get written confirmation. ### Liability and indemnity DPAs sit alongside the main agreement, so check how the liability cap and any carve-outs interact. Data-protection breaches are often where the heaviest exposure is, so confirm whether data claims sit inside the general cap, a separate cap, or are uncapped. ## Red flags to push back on Blank annexes or an empty processing schedule. "The processor may use aggregated or anonymised data for any purpose" without a clear definition of anonymisation. Sub-processors appointed with no notice. Breach notice with no outer time limit. Transfers mentioned but no named mechanism. Audit rights removed entirely in favour of a certificate you have not seen. ## How the law changes by jurisdiction Contract law is national, so the same words do not behave the same everywhere. In common-law systems (India, the UK, Singapore, Australia, the US) courts lean on the written terms and read ambiguity against the drafter. Governing-law and jurisdiction clauses decide which country's rules apply and where disputes are heard; check they match where the parties and the assets actually are. In India, stamp duty and, for many instruments, registration are live concerns, and the Indian Contract Act 1872 governs formation. In the US, state law varies and the Uniform Commercial Code may apply where goods are involved. Across the EU and UK, data and consumer rules add mandatory terms you cannot contract out of. When in doubt, take local advice; this page is general information, not legal advice. ## A simple review workflow Read the processing schedule and roles first, then the sub-processor and transfer clauses, then security, then breach and audit, then deletion, then liability. Compare the DPA against the main services agreement so definitions and caps line up. Keep a short issues list with the clause reference, the risk and your proposed change, and track it to closure. ## One workspace for drafting, review and tracking Everything above is work you can do by hand: read the draft, mark the risky positions, line up your redlines, remember the dates. The friction is rarely the reading. It is that the draft, the comments, the versions, the signed copy and the renewal date usually live in five different places. The simple idea behind an AI contract workspace is to keep that work together: draft from your own catalogue, see each clause flagged favourable, neutral or unfavourable to you, edit clauses in plain English and get a clean diff, keep a live activity timeline so every version is traceable, and track key dates and obligations so renewals and notices do not slip. Adira is one such workspace, built on Anthropic's Claude and tuned to how your company contracts. It is India-first today; deeper support for other jurisdictions and a single legal health pane (the Company Command Centre) are on the roadmap. None of that replaces legal advice on a specific deal. It just means the review you ran once does not have to be rebuilt from scratch next quarter.