A Data Processing Agreement review should confirm who controls the processing, what personal data the vendor handles, why and where it is processed, which safeguards apply, how subprocessors are governed, how incidents and rights requests are handled, and what happens to data when the service ends. TPRM analysts should translate those clauses into operational controls and evidence, not treat the DPA as a legal document that can be filed without review.
Under Article 28 of the EU GDPR, a controller using a processor must put a binding contract or other legal act in place. Similar controller-processor requirements apply under the UK GDPR. Privacy counsel owns legal interpretation, but TPRM, security, procurement, and business owners supply much of the evidence needed to decide whether the processing is acceptable.
This guide explains how to review a DPA practically. It is an operational risk framework, not legal advice; organizations should involve qualified privacy or legal professionals for jurisdiction-specific conclusions.
What Is A Data Processing Agreement?
A DPA defines how a processor may handle personal data on behalf of a controller. It normally forms part of the main services contract and describes the processing, documented instructions, confidentiality, security, subprocessors, assistance, deletion or return, and audit rights.
A DPA does not decide the parties’ roles merely because its heading says “controller” and “processor.” The EDPB Guidelines 07/2020 explain that controller and processor are functional concepts based on the parties’ real activities. The organization deciding the purposes and essential means of processing is generally the controller. A service provider acting only on documented instructions is generally a processor.
That role determination is the first control. If the facts and contract use different roles, the rest of the DPA may be unreliable.
Documents To Collect Before Review
- The proposed DPA and main services agreement.
- Processing schedule or data-processing details annex.
- Technical and organizational measures, often called the TOMs annex.
- Current subprocessor list and change-notification method.
- Data-flow or architecture diagram showing collection, storage, access, and transfers.
- Data-retention and deletion schedule.
- Relevant security assurance, such as a SOC report, ISO certificate, test summary, or control responses.
- International-transfer mechanism and transfer assessment where required.
- Incident-response, rights-request, business-continuity, and offboarding procedures.
Review these as one evidence set. Strong language in a DPA does not compensate for a contradictory product design, and strong technical controls do not cure missing contractual duties.
Data Processing Agreement Review Checklist
1. Confirm the parties and privacy roles
Match the legal names in the DPA to the customer and vendor entities signing the main agreement. Identify whether each party acts as controller, joint controller, independent controller, processor, or a combination for different activities. Marketing, account management, fraud prevention, telemetry, and product improvement may involve roles different from core service delivery.
Escalate vague language that allows the vendor to determine new purposes for customer data without a clear legal basis, instruction, or role allocation.
2. Define the processing accurately
The contract should describe the subject matter and duration, nature and purpose, types of personal data, categories of data subjects, and controller rights and obligations. Avoid schedules that simply say “all data necessary to provide the services.” The description should be specific enough to test minimization, retention, transfers, security, and subprocessor use.
Compare the schedule with intake answers, product documentation, integrations, and actual data flows. Include support logs, backups, derived data, metadata, test environments, and administrator access where relevant.
3. Restrict processing to documented instructions
Article 28 requires processors to act on documented controller instructions unless law requires otherwise. Review whether the main agreement, order form, configuration choices, support requests, and written procedures collectively define those instructions. Check how new instructions are approved, recorded, and priced.
Watch for broad rights to use personal data for analytics, benchmarking, AI training, advertising, or unrelated product development. If the vendor needs data for its own purposes, privacy counsel should determine the correct role and disclosure rather than hiding that use inside processor language.
4. Check confidentiality obligations
Confirm that personnel authorized to process personal data are bound by confidentiality and receive appropriate training. Ask how privileged access is approved, logged, reviewed, and removed. For high-risk services, connect the clause to joiner-mover-leaver controls, background screening where lawful, and support-access restrictions.
5. Review technical and organizational measures
The TOMs should match the processing risk and service architecture. Typical areas include:
- Identity, authentication, least privilege, and privileged access.
- Encryption in transit and at rest, with appropriate key management.
- Tenant separation and production-data controls.
- Logging, monitoring, vulnerability management, and secure development.
- Backup, restoration, availability, resilience, and recovery testing.
- Incident detection, response, evidence preservation, and lessons learned.
- Data minimization, retention, deletion, and non-production masking.
- Physical, personnel, and supplier-security controls.
Reject annexes that permit unilateral material weakening without notice. A reasonable change mechanism can allow control evolution while preserving an equivalent or stronger protection level.
6. Govern subprocessors and fourth parties
Confirm whether authorization is specific or general, what information the vendor provides about subprocessors, how changes are notified, and whether the customer has a meaningful opportunity to object. Article 28 requires the processor to impose equivalent data-protection obligations on subprocessors and remain accountable for their performance.
The EDPB Opinion 22/2024 states that controllers should have the identity information for processors and subprocessors readily available and that processors should keep it current. A link to a list is useful only if the list is complete, monitored, and tied to a notification process.
7. Test incident-notification language
The processor should notify the controller without undue delay after becoming aware of a personal-data breach. The DPA should support the controller’s own statutory deadlines by defining a contact path, initial notification trigger, information to be supplied, update cadence, cooperation, evidence preservation, and post-incident reporting.
A fixed 72-hour vendor-to-customer deadline may be too slow where the controller itself may have 72 hours to notify a regulator. Avoid clauses that delay notice until the vendor completes its full investigation or independently decides materiality.
8. Cover data-subject rights and regulatory assistance
Define how the vendor supports access, correction, deletion, restriction, objection, portability, and other applicable rights. Check intake channel, identity controls, search capability, response format, timing, and deletion across active systems and backups.
The DPA should also address assistance with security obligations, breach assessments, data-protection impact assessments, regulator consultations, and information needed to demonstrate compliance. High-risk processing may require tighter response times and testing.
9. Address international transfers
Map where personal data is stored, remotely accessed, supported, backed up, and disclosed by the processor and its subprocessors. A data center in one country does not eliminate transfer risk if administrators in another country can access the data.
Where required, identify the transfer mechanism, such as an adequacy decision or the applicable module of the EU Standard Contractual Clauses. Confirm responsibility for transfer assessments, supplementary measures, government-access requests, and change notification. A DPA and SCCs solve related but different contract needs.
10. Define retention, return, and deletion
At termination, the controller should be able to choose return or deletion unless law requires retention. Review export format, assistance, timeline, backup handling, deletion verification, legal holds, and subprocessor deletion. Connect the clause to the vendor’s technical deletion process rather than accepting “commercially reasonable” language without a measurable outcome.
11. Preserve audit and assurance rights
The processor should provide information necessary to demonstrate compliance and allow audits or inspections. A practical assurance model may start with independent reports, certifications, questionnaires, and remediation evidence, with direct audit rights reserved for material incidents, credible control concerns, regulatory requests, or insufficient standard evidence.
Check scope, frequency, notice, confidentiality, cost, regulator access, and whether the audit can cover relevant subprocessors. A clause that lets the vendor supply only a marketing summary may not provide enough evidence.
12. Align hierarchy, liability, and survival
Confirm which document controls if the DPA conflicts with the main agreement, security schedule, SCCs, or product terms. Review whether confidentiality, deletion, audit cooperation, claims handling, and transfer duties survive termination as needed. Legal teams should assess liability caps, indemnities, exclusions, and mandatory statutory rights.
Practical DPA Review Matrix
| Area | Evidence | Escalation trigger |
|---|---|---|
| Roles | DPA, product purpose, data flow | Contract role conflicts with actual behavior |
| Scope | Processing schedule and intake | Data or purpose is vague, incomplete, or excessive |
| Security | TOMs and assurance reports | Material control gap or unilateral weakening right |
| Incidents | DPA and response procedure | Notice waits for full investigation or vendor materiality test |
| Subprocessors | List, locations, notice process | Unknown chain, no flow-down, or ineffective objection route |
| Transfers | Locations, SCCs, assessment | No valid mechanism or unassessed remote access |
| Deletion | Retention schedule and procedure | No timeline, proof, backup approach, or subprocessor coverage |
| Assurance | Reports, audit clause, remediation | Evidence cannot demonstrate contractual compliance |
Eight-Step Analyst Workflow
- Confirm service owner, legal entity, privacy roles, and intended use.
- Map personal data, people, purposes, systems, integrations, and locations.
- Compare the DPA schedule with intake and architecture evidence.
- Review mandatory clauses and translate them into operational controls.
- Test security, incident, rights, transfer, subprocessor, and deletion evidence.
- Record deviations using approved clause positions and risk rationale.
- Route legal questions to privacy counsel and operational gaps to accountable owners.
- Approve, reject, mitigate, or accept residual risk with a complete decision record.
Common DPA Review Mistakes
Reviewing the DPA without the service facts
Contract language cannot be evaluated without knowing the data, purpose, product architecture, access, and locations.
Assuming the vendor template is compliant
A familiar clause may still be incomplete or unsuitable for the processing. Test every obligation against your exposure.
Confusing data residency with transfer compliance
Storage location is only part of the analysis. Remote support, administration, backups, and subprocessors can create additional transfers.
Negotiating a promise the vendor cannot perform
Confirm that deletion, notification, access, and rights-assistance clauses match real technical procedures.
Failing to monitor after signature
Track subprocessor changes, policy updates, control evidence, incidents, product features, and transfer mechanisms through the relationship.
Analyst Takeaway
A defensible DPA review connects legal obligations to the vendor’s real processing and controls. Confirm roles, describe the data accurately, restrict purposes, test TOMs, expose the full subprocessor chain, verify transfer and incident arrangements, and make deletion provable. The strongest review record shows not only what the clause says, but why the available evidence supports the decision.
LearnTPRM’s practical assessment exercises and templates can help teams standardize DPA issue logs, evidence requests, and residual-risk decisions without turning the process into a legal checklist alone.
Frequently Asked Questions
Who should review a Data Processing Agreement?
Privacy or legal counsel should interpret law and negotiate legal positions. TPRM, security, procurement, technology, and business owners should validate data flows, controls, service impact, evidence, and operational feasibility.
Is a DPA required for every vendor?
Not every vendor processes personal data on a controller’s behalf. Determine the facts and applicable law. A processor relationship under GDPR or UK GDPR generally requires a written contract meeting Article 28 requirements.
Can a vendor use one general DPA for all customers?
A standard DPA can be efficient, but the processing schedule, roles, transfers, security measures, and service details must accurately cover the specific relationship.
Does signing SCCs replace a DPA?
No. SCCs address specified international-transfer arrangements. A controller-processor relationship still needs the applicable processing terms, although documents can be combined and some SCC modules contain related obligations.
How often should a DPA be reviewed?
Review at onboarding and material renewal, and when processing purposes, data, product features, entities, locations, subprocessors, laws, or risk materially change.
