A data processing agreement, often called a DPA, defines how one party may process personal data for another. It turns privacy and security responsibilities into operational contract duties covering instructions, access, subprocessors, incidents, transfers, audits, retention, and deletion.
The review should begin with the real data flow. A well-written DPA cannot fix an incomplete understanding of what data enters the service, where it goes, who can access it, and what happens when the service ends.
Map the Data Before Reading the Terms
Identify the categories of personal data, data subjects, processing purposes, systems, locations, and recipients. Determine whether the service handles sensitive information, employee records, customer communications, financial information, health information, identifiers, or behavioral data.
The schedule describing processing should be specific enough to test the rest of the agreement. Phrases such as "business data" or "information necessary to provide the service" may be too broad for meaningful review.
Confirm the Parties' Roles
The DPA should identify the parties' privacy roles and account for activities in which the provider may act independently.
Check whether the provider processes data only on documented instructions or also uses it for analytics, product improvement, fraud prevention, legal compliance, or AI training. Separate those purposes instead of assuming one role applies to every activity.
For processing subject to the EU General Data Protection Regulation, Article 28 establishes contractual requirements for processor relationships. The official regulation is available through EUR-Lex.
Define Documented Instructions
Instructions may appear in the agreement, order form, product configuration, support requests, or later written directions. The DPA should explain what qualifies as an instruction and what happens if the provider believes an instruction violates applicable law.
Avoid language allowing the provider to expand processing unilaterally through product documentation or a privacy policy. Material new purposes should require appropriate notice and, where necessary, agreement.
Review Confidentiality and Access
The provider should limit personal-data access to authorized personnel who need it for assigned work. Review confidentiality duties, access approval, authentication, logging, training, and removal of access when roles change.
Privacy confidentiality overlaps with the broader contract confidentiality framework. Link this page to What Is an NDA?, which currently has the site's highest blog impressions, while explaining that a DPA addresses regulated processing duties beyond a conventional NDA.
Evaluate Security Commitments
Security terms should be concrete enough to assess. Review encryption, identity controls, vulnerability management, logging, backup, recovery, secure development, testing, incident response, physical safeguards, and personnel controls.
Determine whether the security schedule is binding and whether the provider may materially reduce controls during the term. Certifications and reports can support diligence, but they do not replace contract commitments tailored to the service.
Control Subprocessors
Review the current subprocessor list, notice period for additions, objection rights, locations, flow-down obligations, and provider responsibility for subprocessor performance.
An objection right is weak if the only outcome is immediate termination without refund or migration support. The process should give the parties a reasonable opportunity to address a legitimate concern.
Define Incident Notification and Cooperation
The DPA should define the event that triggers notice and avoid delaying notice until every fact is confirmed. Review required timing, communication channels, minimum information, update frequency, evidence preservation, investigation cooperation, remediation, and allocation of costs.
The customer may need information to satisfy its own notice duties. The provider should therefore deliver available facts promptly and update them as the investigation develops.
Review International Transfers
Identify every country where data may be stored, accessed, or supported. Confirm the transfer mechanism, responsibility for assessments, supplementary measures, and process for responding to legal changes.
The agreement should also address government requests, including notice where legally permitted and review of the request's validity and scope.
Address Data Subject and Regulator Requests
Determine how the provider will assist with access, deletion, correction, restriction, portability, objections, regulatory inquiries, and impact assessments.
Assistance should be timely and technically feasible. If fees apply, the pricing method should be stated so that urgent compliance support does not become an open-ended cost.
Review Audit Rights
Audit language should balance verification with security and operational burden. Review available reports, questionnaires, evidence, onsite rights, notice, frequency, confidentiality, costs, and follow-up on findings.
A report prepared for another purpose may not address the customer's specific processing risk. The agreement should provide an escalation path when standard materials are insufficient after an incident, material control change, or regulator request.
Plan Return and Deletion
The DPA should explain how the customer retrieves data, when active copies are deleted, how backups are handled, and whether deletion is confirmed. Check whether retention continues for legal requirements and how retained data remains protected.
Exit terms should align with the main agreement. A DPA promising deletion immediately at termination may conflict with a transition period that requires continued access.
Connect the DPA to the Main Agreement
Review liability caps, indemnities, confidentiality, security schedules, insurance, suspension, termination, and order of precedence. A privacy commitment may have little value if another document overrides it or limits the available remedy unexpectedly.
Use How to Review a Contract as the internal hub for this cross-document method. Alloomi AI can help identify conflicting provisions and compare DPA language with the main agreement, subject to human verification.
Common Review Mistakes
• Reviewing the DPA without mapping the actual data flow.
• Assuming the provider acts in one role for every use of data.
• Accepting generic security language without a binding schedule.
• Overlooking remote access and subprocessor locations.
• Allowing incident notice only after final confirmation.
• Failing to align deletion with transition and backup processes.
Conclusion
A DPA should convert the data flow into clear responsibilities from collection through deletion. The strongest review follows the information across roles, instructions, access, security, subprocessors, incidents, transfers, audits, assistance, and exit.
Frequently Asked Questions
1. Is a DPA the same as an NDA?
No. An NDA focuses on confidentiality. A DPA addresses the processing of personal data and may include regulatory, security, assistance, transfer, and deletion obligations.
2. Does every vendor need a DPA?
Not necessarily. The need depends on whether the vendor processes personal data and on the applicable legal and contractual framework.
3. Should a DPA have separate liability terms?
The parties may use the main agreement's cap, a separate cap, or specific exceptions. The structure should be reviewed against the data risk and applicable law.
