Download the editable Data Processing Agreement Checklist
The file is designed for real review work, with structured fields, ownership prompts, status controls, and space for evidence.
What this file is for
This data processing agreement checklist helps a buying team review the operational facts behind a proposed data processing agreement before legal approval. It is most useful when several functions need to contribute facts but one person must maintain a single decision record. The working question is whether the contract describes the intended processing, safeguards, subprocessors, transfers, and exit duties. Keeping that question visible prevents the team from collecting documents and comments that never change the decision.
Use the file before approval, and return to it whenever scope, quantities, data handling, delivery timing, or contract terms change. The expected coordinator is the privacy or legal reviewer, with input from the service owner, privacy, security, legal, procurement, records management, and the vendor. The tool does not replace legal, security, privacy, finance, or technical judgment. It makes each judgment traceable to evidence and an accountable owner.
What the download contains
| # | Working area | How to complete it |
|---|---|---|
| 1 | Processing Purpose And Data Subjects | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 2 | Data Categories And Special Handling | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 3 | Controller And Processor Roles | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 4 | Subprocessor Notice And Objection Route | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 5 | International Transfer Mechanism | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 6 | Deletion, Return, Audit, And Incident Commitments | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
The file also includes instructions, status choices, review notes, and a signoff area. Blank fields are intentional: they should be completed from the documents and tests for the actual purchase. Do not copy a previous vendor's answers unless the underlying facts are still current and apply to the same service scope.
Field-by-field review guide
Processing Purpose And Data Subjects
Treat processing purpose and data subjects as a decision input in the data processing agreement checklist, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether the contract describes the intended processing, safeguards, subprocessors, transfers, and exit duties. Ask the privacy or legal reviewer to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check processing purpose and data subjects against data categories and special handling, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from the service owner, privacy, security, legal, procurement, records management, and the vendor should remain attributable to the person and evidence used. A specific risk to test here is copying privacy language without mapping real data flows. Record the status, next action, due date, and proof needed for closure. The completed processing purpose and data subjects record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Data Categories And Special Handling
Treat data categories and special handling as a decision input in the data processing agreement checklist, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether the contract describes the intended processing, safeguards, subprocessors, transfers, and exit duties. Ask the privacy or legal reviewer to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check data categories and special handling against controller and processor roles, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from the service owner, privacy, security, legal, procurement, records management, and the vendor should remain attributable to the person and evidence used. A specific risk to test here is accepting a subprocessor URL with no change-notice process. Record the status, next action, due date, and proof needed for closure. The completed data categories and special handling record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Controller And Processor Roles
Treat controller and processor roles as a decision input in the data processing agreement checklist, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether the contract describes the intended processing, safeguards, subprocessors, transfers, and exit duties. Ask the privacy or legal reviewer to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check controller and processor roles against subprocessor notice and objection route, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from the service owner, privacy, security, legal, procurement, records management, and the vendor should remain attributable to the person and evidence used. A specific risk to test here is missing a conflict between the DPA and order form. Record the status, next action, due date, and proof needed for closure. The completed controller and processor roles record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Subprocessor Notice And Objection Route
Treat subprocessor notice and objection route as a decision input in the data processing agreement checklist, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether the contract describes the intended processing, safeguards, subprocessors, transfers, and exit duties. Ask the privacy or legal reviewer to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check subprocessor notice and objection route against international transfer mechanism, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from the service owner, privacy, security, legal, procurement, records management, and the vendor should remain attributable to the person and evidence used. A specific risk to test here is assuming product deletion automatically meets retention duties. Record the status, next action, due date, and proof needed for closure. The completed subprocessor notice and objection route record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
International Transfer Mechanism
Treat international transfer mechanism as a decision input in the data processing agreement checklist, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether the contract describes the intended processing, safeguards, subprocessors, transfers, and exit duties. Ask the privacy or legal reviewer to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check international transfer mechanism against deletion, return, audit, and incident commitments, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from the service owner, privacy, security, legal, procurement, records management, and the vendor should remain attributable to the person and evidence used. A specific risk to test here is copying privacy language without mapping real data flows. Record the status, next action, due date, and proof needed for closure. The completed international transfer mechanism record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Deletion, Return, Audit, And Incident Commitments
Treat deletion, return, audit, and incident commitments as a decision input in the data processing agreement checklist, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether the contract describes the intended processing, safeguards, subprocessors, transfers, and exit duties. Ask the privacy or legal reviewer to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check deletion, return, audit, and incident commitments against processing purpose and data subjects, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from the service owner, privacy, security, legal, procurement, records management, and the vendor should remain attributable to the person and evidence used. A specific risk to test here is accepting a subprocessor URL with no change-notice process. Record the status, next action, due date, and proof needed for closure. The completed deletion, return, audit, and incident commitments record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Decision rules
- Match the agreement to the actual configured service, not a generic product description.
- List unresolved transfer or subprocessor issues as decisions, not comments.
- Confirm deletion duties cover backups and downstream subprocessors.
- Recheck the agreement when scope or data categories change.
Common failure modes
- Avoid copying privacy language without mapping real data flows.
- Avoid accepting a subprocessor URL with no change-notice process.
- Avoid missing a conflict between the DPA and order form.
- Avoid assuming product deletion automatically meets retention duties.
Evidence and signoff standard
A defensible file should let a later reviewer reconstruct the decision without relying on memory. For every material item, capture the source document or test, the date reviewed, the person responsible, and the next action. If evidence is restricted, record its approved location and a short conclusion rather than attaching it to an uncontrolled copy. If a vendor answer changes, preserve the final accepted version and note what superseded the earlier response.
Before signoff, verify that the record covers processing purpose and data subjects, data categories and special handling, controller and processor roles, subprocessor notice and objection route, international transfer mechanism, and deletion, return, audit, and incident commitments. Resolve critical gaps or document a time-limited exception. The final approver should understand both the desired outcome and the residual risk. Store the signed or approved copy with the contract, quote, implementation decision, or service inventory entry that it supports.
Questions to ask before approval
- What evidence supports the entry for processing purpose and data subjects?
- What evidence supports the entry for data categories and special handling?
- What evidence supports the entry for controller and processor roles?
- What evidence supports the entry for subprocessor notice and objection route?
- What evidence supports the entry for international transfer mechanism?
- What evidence supports the entry for deletion, return, audit, and incident commitments?
Authoritative references
The following public resources provide context for the control and acquisition principles used in this file. They do not answer vendor-specific questions; use the current vendor documents and your organization's policies for the actual decision.