1. Purpose
A Data Processing Agreement (DPA) Checklist is used to verify that appropriate privacy and information-security requirements are addressed in an agreement between parties where one party processes personal data on behalf of another.
The checklist helps the organization confirm that the DPA clearly defines:
- The parties and their roles
- The processing activities
- Types of personal data
- Categories of individuals
- Processing purposes
- Processing instructions
- Security requirements
- Confidentiality
- Subprocessors
- Data breach notification
- Data subject rights support
- Data retention and deletion
- Data transfers
- Audit and assurance
- Regulatory requirements
- Contract termination obligations
Core Principle
Personal Data → Processing Purpose → Roles → Instructions → Security Controls → Subprocessors → Data Transfers → Data Subject Rights → Incident Management → Retention/Deletion → Assurance → Termination
2. When to Use This Checklist
Use the checklist when:
- A supplier will process personal data on behalf of the organization
- A SaaS provider processes employee/customer information
- A cloud service stores or processes personal data
- A service provider receives customer personal data
- A business outsources HR, payroll, support, marketing, analytics, or similar activities
- A processor uses subprocessors
- Personal data is transferred across countries
- A new processing activity is introduced
- The scope of an existing processing activity changes
- A DPA is renewed or amended
- A security incident or privacy incident occurs
- Regulatory or contractual requirements change
Not every supplier requires a DPA. The organization should first determine whether the supplier actually processes personal data and what legal relationship applies.
3. DPA Information
| Field | Details |
|---|---|
| DPA ID | |
| Contract ID | |
| Organization | |
| Supplier / Processor | |
| Business Owner | |
| Privacy Owner / DPO | |
| Service | |
| Processing Activity | |
| Effective Date | |
| Expiry / Renewal Date | |
| Assessment Date | |
| DPA Status | Draft / Under Review / Approved / Executed |
| Related Contract | |
| Data Protection Jurisdiction(s) |
4. Party and Role Identification
Confirm that the DPA clearly identifies the parties.
| Check | Yes/No/N/A | Evidence / Comments |
|---|---|---|
| Legal name of organization identified | ||
| Legal name of supplier identified | ||
| Registered/contact details identified | ||
| Appropriate privacy contacts identified | ||
| Data protection roles identified | ||
| Controller/processor or equivalent roles identified | ||
| Responsibilities of each party defined | ||
| Relationship with the main agreement defined |
The agreement should avoid ambiguity about who determines the purposes and means of processing and who processes personal data on another party’s behalf.
5. Processing Description
Verify that the DPA clearly describes the processing activity.
| Check | Yes/No/N/A | Details |
|---|---|---|
| Purpose of processing defined | ||
| Nature of processing defined | ||
| Processing activities identified | ||
| Categories of personal data identified | ||
| Categories of data subjects identified | ||
| Processing duration defined | ||
| Processing locations identified | ||
| Systems/services involved identified | ||
| Business purpose documented |
Example
A SaaS HR provider may process:
Purpose: Payroll and employee administration
Data subjects: Employees
Data: Name, contact information, employee ID, payroll information and bank details
Duration: Contract period plus legally required retention period
6. Processing Instructions
Confirm that the processor is required to process personal data only in accordance with documented instructions, subject to applicable law.
| Check | Yes/No/N/A |
|---|---|
| Processing instructions documented | |
| Purpose limitation addressed | |
| Processor cannot use data for unrelated purposes without authorization | |
| Processor cannot sell/use data for unrelated commercial purposes where prohibited | |
| Processor must notify organization of conflicting legal requirements where applicable | |
| Changes to processing require appropriate authorization |
7. Personal Data Categories
Document the categories of information involved.
| Data Category | Applicable? | Details |
|---|---|---|
| Name | ☐ | |
| Contact Information | ☐ | |
| Employee Information | ☐ | |
| Customer Information | ☐ | |
| Account Information | ☐ | |
| Financial Information | ☐ | |
| Identification Information | ☐ | |
| Authentication Information | ☐ | |
| Device Information | ☐ | |
| Location Information | ☐ | |
| Usage Information | ☐ | |
| Sensitive/Special-category Data | ☐ | |
| Other | ☐ |
The organization should identify only the categories actually required for the service.
8. Data Subject Categories
Identify the individuals whose personal data is processed.
Examples:
- Customers
- Employees
- Contractors
- Job applicants
- Users
- Business contacts
- Website visitors
- Suppliers
- Partners
| Category | Applicable? | Details |
|---|---|---|
| Customers | ☐ | |
| Employees | ☐ | |
| Contractors | ☐ | |
| Applicants | ☐ | |
| End Users | ☐ | |
| Website Visitors | ☐ | |
| Business Contacts | ☐ | |
| Other | ☐ |
9. Purpose Limitation
Verify that the DPA addresses appropriate use of personal data.
- ☐ Processing purpose is documented
- ☐ Processing is limited to agreed purposes
- ☐ Secondary use is addressed
- ☐ Analytics use is addressed where applicable
- ☐ AI/ML use is addressed where applicable
- ☐ Advertising/marketing use is addressed where applicable
- ☐ Data monetization is addressed where applicable
- ☐ Processor’s independent use of data is addressed
10. Confidentiality
Confirm that persons authorized to process personal data are subject to appropriate confidentiality obligations.
- ☐ Confidentiality obligations are documented
- ☐ Supplier personnel are bound by confidentiality
- ☐ Confidentiality survives termination where appropriate
- ☐ Access is limited to authorized personnel
- ☐ Personnel receive appropriate security/privacy awareness
11. Information Security Requirements
Verify that the DPA contains appropriate security requirements.
| Control Area | Check |
|---|---|
| Access control | ☐ |
| Least privilege | ☐ |
| Authentication | ☐ |
| MFA where appropriate | ☐ |
| Privileged access management | ☐ |
| Encryption in transit | ☐ |
| Encryption at rest | ☐ |
| Secure configuration | ☐ |
| Vulnerability management | ☐ |
| Malware protection | ☐ |
| Logging and monitoring | ☐ |
| Security incident management | ☐ |
| Backup and recovery | ☐ |
| Business continuity | ☐ |
| Secure development | ☐ |
| Security testing | ☐ |
| Physical security | ☐ |
Security requirements should be proportionate to the nature and risk of the processing.
12. Technical and Organizational Measures
Verify that the processor maintains appropriate technical and organizational measures.
Examples include:
- Identity and access management
- MFA
- Encryption
- Network security
- Endpoint protection
- Secure software development
- Vulnerability management
- Logging and monitoring
- Incident response
- Backup and recovery
- Personnel security
- Security awareness
- Physical security
- Business continuity
Where appropriate, the DPA may reference a security appendix or supplier security requirements document.
13. Subprocessor Management
Verify that subprocessors are appropriately controlled.
| Check | Yes/No/N/A |
|---|---|
| Subprocessor use is addressed | |
| Current subprocessors are identified | |
| Subprocessor locations are identified where required | |
| Prior authorization or notification mechanism is defined | |
| Objection process is defined where applicable | |
| Subprocessors must meet appropriate privacy/security requirements | |
| Flow-down obligations are required | |
| Processor remains responsible for its subprocessors as contractually applicable | |
| Changes to subprocessors are communicated |
Maintain a Subprocessor Register where appropriate.
14. International / Cross-Border Data Transfers
Where personal data is transferred across jurisdictions, verify that the agreement addresses the applicable transfer requirements.
- ☐ Processing countries identified
- ☐ Storage locations identified
- ☐ Remote-access locations considered
- ☐ International transfers identified
- ☐ Applicable transfer mechanism identified
- ☐ Transfer safeguards documented
- ☐ Data localization requirements considered
- ☐ Government/legal access considerations addressed where applicable
The applicable mechanism depends on the jurisdictions and laws involved.
15. Data Subject Rights
Verify that the processor provides reasonable assistance to the organization in responding to applicable data-subject requests.
Potential requirements include assistance with:
- ☐ Access requests
- ☐ Correction
- ☐ Deletion/erasure
- ☐ Restriction
- ☐ Objection
- ☐ Data portability
- ☐ Consent withdrawal
- ☐ Other applicable statutory rights
The DPA should define responsibilities and response procedures appropriate to the applicable law.
16. Privacy Complaints and Requests
Verify that the processor:
- ☐ Has a privacy contact
- ☐ Escalates privacy requests appropriately
- ☐ Does not independently respond to requests where the organization must respond, unless authorized
- ☐ Provides information required to investigate complaints
- ☐ Maintains appropriate records
- ☐ Supports regulatory inquiries where contractually and legally appropriate
17. Personal Data Breach
Verify that the DPA contains appropriate breach-management requirements.
| Requirement | Check |
|---|---|
| Definition/description of breach addressed | ☐ |
| Processor must notify organization without undue delay or within agreed timeframe | ☐ |
| Notification channel identified | ☐ |
| Minimum incident information defined | ☐ |
| Incident investigation support required | ☐ |
| Evidence preservation addressed | ☐ |
| Containment/remediation cooperation required | ☐ |
| Regulatory/customer notification responsibilities clarified | ☐ |
| Post-incident report requirements addressed | ☐ |
Avoid inserting an arbitrary notification period without considering the applicable law and the organization’s actual regulatory obligations.
18. Security Incident Management
Distinguish general security incidents from personal-data breaches where appropriate.
Verify:
- ☐ Incident notification
- ☐ Escalation contacts
- ☐ Incident investigation
- ☐ Containment
- ☐ Evidence preservation
- ☐ Root-cause analysis where appropriate
- ☐ Corrective action
- ☐ Cooperation with investigations
- ☐ Post-incident review
19. Data Retention
Verify that the DPA addresses retention.
- ☐ Retention period defined or determined by instructions
- ☐ Legal retention requirements considered
- ☐ Business retention requirements considered
- ☐ Backup retention addressed
- ☐ Temporary copies addressed where relevant
- ☐ Data minimization considered
- ☐ Retention beyond the agreed purpose is controlled
20. Data Return and Deletion
Verify what happens to personal data when the service ends.
| Check | Yes/No/N/A |
|---|---|
| Data return requirement defined | |
| Data deletion requirement defined | |
| Deletion timeframe defined where appropriate | |
| Backup copies addressed | |
| Legal retention exceptions addressed | |
| Deletion confirmation available where appropriate | |
| Subprocessor deletion addressed | |
| Data remaining after termination is controlled |
21. Audit and Assurance
Verify that the organization has appropriate assurance mechanisms.
Possible evidence:
- ISO 27001 certificate
- SOC 2 report
- Independent security assessment
- Penetration-test summary
- Security questionnaire
- Audit report
- Compliance assessment
- Relevant policies and procedures
The DPA should define appropriate rights to obtain information or conduct assessments, subject to reasonable contractual and confidentiality limitations.
- ☐ Audit rights addressed
- ☐ Assessment rights addressed
- ☐ Evidence request process defined
- ☐ Independent assurance reports accepted where appropriate
- ☐ Remediation of findings addressed
22. Regulatory and Legal Requirements
Verify that the agreement addresses applicable privacy and security obligations.
Consider:
- Applicable privacy legislation
- Sector-specific requirements
- Contractual customer requirements
- Regulatory requirements
- Data localization obligations
- Records and retention requirements
- Law-enforcement requests
- Government access requirements
Do not automatically apply every privacy regulation to every supplier. Determine applicability based on the processing activity, parties, locations, and applicable law.
23. Government / Law-Enforcement Requests
Where appropriate, verify that the processor must:
- Notify the organization of legally permissible government requests
- Provide reasonable assistance
- Challenge or limit requests where legally appropriate
- Disclose only information legally required
- Maintain confidentiality of requests where legally permitted
The exact obligations should be reviewed against applicable law.
24. Data Location
Document where personal data is:
- Collected
- Processed
- Stored
- Backed up
- Accessed remotely
- Transferred
| Location | Activity | Data Type |
|---|---|---|
| Processing | ||
| Storage | ||
| Backup | ||
| Support Access |
Changes to relevant data locations should be addressed through the contract or supplier-management process.
25. Data Minimization
Verify whether the supplier receives only the information necessary for the agreed service.
- ☐ Data fields reviewed
- ☐ Unnecessary data excluded
- ☐ Access limited to required information
- ☐ Retention minimized
- ☐ Test/development data controlled
- ☐ Production data use in testing restricted
26. AI and Generative AI
If the supplier uses AI/ML or generative AI, verify:
- ☐ AI processing is disclosed
- ☐ Personal data use is addressed
- ☐ Customer data used for model training is addressed
- ☐ Secondary use is addressed
- ☐ Data retention by AI provider is understood
- ☐ Subprocessors are identified
- ☐ Security controls are addressed
- ☐ Applicable AI/privacy requirements are considered
This is particularly important where confidential or personal information may be submitted to AI services.
27. Data Processing Records and Documentation
Where appropriate, verify availability of:
- ☐ Processing description
- ☐ Data-flow information
- ☐ Subprocessor information
- ☐ Security measures
- ☐ Data-location information
- ☐ Retention information
- ☐ Incident records
- ☐ Data deletion records
- ☐ Audit/assurance evidence
28. Contract and Legal Review
Before execution:
- ☐ Main agreement reviewed
- ☐ DPA reviewed
- ☐ Security addendum reviewed
- ☐ Privacy requirements reviewed
- ☐ Data-processing scope reviewed
- ☐ Liability provisions reviewed
- ☐ Confidentiality reviewed
- ☐ Subprocessor terms reviewed
- ☐ Transfer terms reviewed
- ☐ Termination provisions reviewed
- ☐ Legal/privacy approval obtained where required
29. DPA Exceptions and Gaps
Document any requirements that are missing or different from the organization’s standard requirements.
| Gap ID | Requirement | Supplier Position | Risk | Compensating Control | Decision |
|---|---|---|---|---|---|
| DPA-001 | |||||
| DPA-002 |
Do not treat every contractual deviation as automatically unacceptable. Assess the associated privacy/security risk and document the decision.
30. Privacy Risk Assessment
Where appropriate, link the DPA review to a privacy or supplier risk assessment.
| Risk | Likelihood | Impact | Risk | Treatment | Residual Risk |
|---|---|---|---|---|---|
| Unauthorized access | |||||
| Excessive data collection | |||||
| Subprocessor risk | |||||
| Cross-border transfer | |||||
| Data retention | |||||
| Breach notification delay |
31. Approval
| Role | Name | Decision | Date |
|---|---|---|---|
| Business Owner | Approved / Rejected | ||
| Privacy Owner / DPO | Approved / Rejected | ||
| Information Security | Approved / Rejected | ||
| Legal | Approved / Rejected | ||
| Risk Owner | Approved / Rejected |
Approval should follow the organization’s delegation of authority.
32. Post-Execution Monitoring
After the DPA is executed, monitor relevant requirements.
| Activity | Frequency | Owner |
|---|---|---|
| Subprocessor changes | ||
| Security assurance | ||
| Privacy incidents | ||
| Data-processing changes | ||
| Data-location changes | ||
| Contract changes | ||
| Security review | ||
| DPA review |
A signed DPA should not be treated as the end of supplier privacy management.
33. Reassessment Triggers
Reassess the DPA or processing arrangement when:
- Processing purpose changes
- New categories of personal data are introduced
- New data subjects are introduced
- New subprocessors are added
- Data location changes
- International transfers change
- New AI functionality is introduced
- Supplier security changes
- A privacy incident occurs
- A personal-data breach occurs
- Contract scope changes
- Applicable law changes
- The supplier introduces a new service
- The organization changes its processing activities
34. Evidence Register
Maintain evidence supporting the DPA review.
| Evidence ID | Evidence | Owner | Location | Date |
|---|---|---|---|---|
| DPA-E01 | Executed DPA | |||
| DPA-E02 | Subprocessor List | |||
| DPA-E03 | Security Assurance Report | |||
| DPA-E04 | Privacy Assessment | |||
| DPA-E05 | Supplier Questionnaire | |||
| DPA-E06 | Risk Assessment | |||
| DPA-E07 | Approval Record |
Do not store passwords, API keys, access tokens, or other secrets in this register.
35. Startup-Friendly DPA Model
Not every processing relationship requires the same level of contractual review.
Low-Risk Processing
Focus on:
- Parties and roles
- Processing purpose
- Data categories
- Confidentiality
- Basic security
- Incident notification
- Retention
- Deletion
Medium-Risk Processing
Add:
- Detailed security measures
- Subprocessors
- Data locations
- Data-subject rights assistance
- Assurance evidence
- Audit/assessment rights
- BCP/DR
- International transfers
High-Risk Processing
Add:
- Detailed technical and organizational measures
- Sensitive/high-impact data assessment
- Detailed incident requirements
- Enhanced audit rights
- Subprocessor controls
- Transfer mechanisms
- Data-location controls
- Detailed deletion verification
- Security testing/assurance
- Enhanced monitoring
The level of contractual detail should reflect the nature and risk of the processing.
36. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Supplier Register | Identifies the supplier |
| Critical Supplier Register | Identifies critical suppliers |
| Supplier Due Diligence | Evaluates supplier before engagement |
| Supplier Risk Assessment | Assesses supplier-related risk |
| Supplier Security Questionnaire | Collects security information |
| Supplier Security Requirements | Defines security expectations |
| Supplier Contract Security Checklist | Reviews contractual security clauses |
| Supplier Security Addendum | Defines security obligations |
| DPA Checklist | Reviews privacy/data-processing requirements |
| Subprocessor Register | Tracks subprocessors |
| Data Inventory / RoPA | Records organizational processing activities |
| Privacy Risk Assessment | Assesses privacy risks |
| Supplier Security Review | Periodically reviews supplier controls |
| Supplier Offboarding | Handles secure termination |
37. ISO 27001 Connection
The DPA review supports the organization’s broader information-security and supplier-management processes, including areas related to:
- Supplier relationships
- Security requirements in supplier agreements
- ICT supply-chain security
- Protection of information
- Access control
- Information transfer
- Incident management
- Privacy and protection of personal information
- Risk assessment and treatment
- Monitoring and review
A DPA is primarily a privacy/data-processing contractual instrument. It should therefore be used alongside, rather than as a replacement for, the organization’s information-security risk assessment and supplier-security controls.
38. Quick Audit Checklist
An auditor should be able to verify:
- ☐ Processing relationship identified
- ☐ Parties identified
- ☐ Roles identified
- ☐ Processing purpose documented
- ☐ Personal-data categories documented
- ☐ Data-subject categories documented
- ☐ Processing duration addressed
- ☐ Processing locations addressed
- ☐ Processing instructions defined
- ☐ Confidentiality addressed
- ☐ Security measures addressed
- ☐ Subprocessors addressed
- ☐ International transfers addressed where applicable
- ☐ Data-subject rights assistance addressed
- ☐ Incident/breach notification addressed
- ☐ Retention addressed
- ☐ Return/deletion addressed
- ☐ Audit/assurance addressed
- ☐ Regulatory requirements considered
- ☐ AI processing considered where applicable
- ☐ Exceptions documented
- ☐ Privacy/security risks assessed
- ☐ Appropriate approvals obtained
- ☐ Executed DPA retained
- ☐ Ongoing monitoring defined
39. Final Audit Trail
A well-managed DPA process should create a clear chain:
Processing Activity → Personal Data → Data Subjects → Purpose → Parties/Roles → Processing Instructions → Security Measures → Subprocessors → Data Transfers → Data Subject Rights → Incident Management → Retention → Deletion → Assurance → Approval → Monitoring → Reassessment → Termination
Final Principle
A DPA should not be treated as a document that is simply signed and filed. It should establish clear responsibilities for how personal data is processed, protected, monitored, and ultimately returned or deleted.
The checklist should help demonstrate that the organization has considered both privacy requirements and information-security risks associated with the processing relationship.