The DPA Review Checklist · Guides

A vendor's standard DPA is a legal document drafted by their lawyers in their interests. Reviewing one isn't legal triage — it's a fit-check against your own commitments and your own risk posture. This checklist is the one we'd hand to a privacy operations lead doing their first round of vendor onboarding.

The list is organised in the order you'd typically read the document. None of it requires legal training, but a flagged item should go to legal review before signing.

Identification of the parties

[ ] Correct entity name. The DPA names your legal entity, not a parent or affiliate. Mismatches cause problems with audit trails and standing for legal claims.
[ ] Correct vendor entity. Some vendors operate through a regional affiliate (e.g. an Irish subsidiary for EEA customers); the DPA should be with the entity actually processing your data, or explicitly bind the corporate group.

Subject matter and scope

[ ] Description of processing. A concrete description of what the vendor does with the data, not a copy of GDPR Article 28(3) text.
[ ] Categories of data subjects. Customers, employees, contractors, leads — whichever applies to your use of the service.
[ ] Categories of personal data. Specific. "Contact information, transaction records, IP addresses" — not "personal data."
[ ] Special categories. Explicitly addressed if relevant. If you'll be processing health, biometric, or financial data, the DPA must reflect heightened safeguards.

Instructions

[ ] Limit to documented instructions. The DPA must restrict the processor to acting on your documented instructions only.
[ ] Flag exceptions. Many DPAs allow the vendor to deviate where required by law. Watch for "or any law" — should be limited to laws of the EEA or member states.
[ ] Notification of conflicting law. If the vendor believes an instruction conflicts with applicable law, they must inform you (Article 28(3)(h)).

Confidentiality and personnel

[ ] Confidentiality obligations. Personnel handling data must be under confidentiality obligations.
[ ] Need-to-know basis. Access limited to those who need it.
[ ] Training. Vendor personnel are trained on data protection.

Security

[ ] Article 32 measures. A description of technical and organisational measures, not just the phrase.
[ ] Encryption in transit and at rest. Not optional.
[ ] Access logging and monitoring. The vendor logs access to your data and retains the logs.
[ ] Backup and disaster recovery. Defined RPO and RTO if your business depends on the vendor's availability.
[ ] Penetration testing. Annual at minimum, scope appropriate.
[ ] Vulnerability management. A defined patching cadence.

Subprocessors

[ ] Authorisation type. Specific (named in DPA) or general (notification with right to object).
[ ] Subprocessor list URL. Stable and monitorable. Buried-in-PDF lists are a yellow flag.
[ ] Notice period. 14 days minimum is reasonable; less is a flag.
[ ] Right to object. Not just a right to be notified.
[ ] Consequences of objection. What happens if you object? Termination right, transition support, data return.
[ ] Flow-down. The vendor's contracts with subprocessors impose substantially the same obligations.

International transfers

[ ] Transfer mechanism named. SCCs, BCRs, adequacy. Generic references aren't enough.
[ ] 2021 SCC version. Old SCCs (2010, 2004, 2001) are non-compliant.
[ ] Correct module. Module 2 for controller-to-processor; check the annexes are filled out.
[ ] TIA available or referenced. The vendor has done one and will share it.
[ ] Supplementary measures. Listed where applicable (encryption, key residency, etc.).

Data subject rights

[ ] Assistance with rights requests. The vendor will assist within defined timeframes.
[ ] Mechanism for assistance. API, support ticket, contact channel — concrete.
[ ] Costs. Who pays for assistance with DSARs and other rights requests.

Breach notification

[ ] Notification window. A specific number of hours, not "without undue delay."
[ ] 24-72 hours typical. Anything longer is hard to reconcile with your own 72-hour controller obligation.
[ ] Information included. Categories of data, approximate number of records, root cause, remediation.
[ ] Channel. Email to a defined address; phone for severe incidents.

Audit rights

[ ] Audit mechanism. Access to relevant attestation reports (SOC 2, ISO 27001) is industry standard.
[ ] Frequency. At least annually, plus on incident.
[ ] Notice and cost. Who pays, how much notice the vendor requires.
[ ] No reasonable refusal. If you have grounds to suspect non-compliance, the vendor cannot refuse.

Retention and deletion

[ ] Retention period defined. A number, or a clear trigger.
[ ] End-of-engagement deletion or return. Article 28(3)(g) requires this.
[ ] Deletion confirmation. A written confirmation, not just an asserted policy.
[ ] Backup retention. Acknowledged separately. "Deleted from production" with an unknown backup retention is incomplete.
[ ] Legal hold exceptions. Defined and limited.

Liability and indemnification

This section needs legal review. Things to flag:

Caps below the contract value are unusual.
Carve-outs for breach of data protection obligations are reasonable.
Mutual indemnification for regulator fines arising from the other party's actions.

What to live with

Not every DPA can be negotiated. For a small customer signing a vendor's standard terms, the realistic ask is:

A 2021 SCC version.
A working, monitorable subprocessor list URL.
A defined breach notification window of 72 hours or less.
A defined retention and deletion commitment.

If those four are present, the DPA is workable. The rest is incremental improvement.

After signing

Signing is the start, not the end. The DPA references documents (subprocessor list, security measures, the SCCs themselves) that change over time. Set up monitoring on at least the subprocessor list and the privacy policy on day one — the rest will surface in the annual review if not before.