DPA review means more than confirming that an agreement carries the right label. A data processing agreement explains how a service provider processes personal data on behalf of your organisation, and its roles, services, data flows and controls must match the actual engagement.
This guide gives you twelve checks that can be worked through beside the contract. It is a review structure rather than a legal conclusion for a particular matter.
Start with the threshold question: is this processing on behalf?
A DPA is the right agreement only where the provider processes personal data on the controller's behalf and under its instructions. If the provider determines its own purposes or essential means, it may act as an independent or joint controller. Read the service description and actual workflow before relying on the labels in the template.
For EU processing, Article 28 GDPR sets the core contract requirements. Swiss organisations should separately consider Article 9 of the Swiss Data Protection Act as well as the Swiss rules on security, breach notification and disclosures abroad.
The 12 checks for your DPA review
Parties and roles: Are the controller, processor and other participants identified correctly, and do the labels match the service in practice?
Subject matter and duration: Does the agreement cover the service, testing, support, transition and termination periods?
Purposes and instructions: Are permitted purposes limited and instructions documented? Look for language that enables a separate use of customer data.
Data and people: Are the types of personal data, any sensitive categories and the groups of data subjects described with enough detail?
Confidentiality: Does the obligation cover everyone with access, including support personnel and external specialists?
Technical and organisational measures: Do the controls match the risks and service, including access, encryption, logging, recovery and change management?
Subprocessors: Are current subprocessors, locations and functions transparent? A general authorisation should include notice of changes and a meaningful right to react.
Locations and international transfers: Where are data stored, processed, backed up and accessed for support? Check the mechanism and recipients for each relevant transfer.
Data subject requests and assistance: Can the provider support access, correction, deletion, objection and data export within usable timeframes?
Personal data breaches: Must the provider notify the controller without undue delay and supply the information needed for the controller's own assessment and notification?
Return, deletion and backups: What happens to live data, copies, logs and backups at termination? Any legal retention exception should be narrow and traceable.
Evidence, audits and changes: Which reports, certifications and audit rights are available? What happens if security terms, subprocessors or the service change?
Three cross-cutting questions
The checks cannot be reviewed in isolation. A detailed security schedule is of limited value if the service description does not reveal which data reach support. A subprocessor list is incomplete without functions and locations. A deletion promise is ambiguous if backups are omitted.
Regulated professions also need a separate confidentiality analysis. Compliance with data protection law does not by itself answer whether privileged or professionally secret material may be disclosed to the provider.
Review liability, order of precedence and unilateral change clauses across the whole contract set. The DPA, service terms and security schedules should not give conflicting answers.
Typical findings and the result they should produce
The service description is too abstract
Wording such as "delivery of the agreed services" does not explain the real data flow. The finding should identify the missing details: functions, data, users, support access and the start and end of processing. The negotiation goal is a service description against which instructions and security controls can actually be assessed.
The subprocessor clause has no workable consequence
Many agreements promise notice of a new subprocessor but do not explain what happens after a reasoned objection. A useful review identifies the notice period, required information, contact and available responses. Depending on the contract, the answer may involve additional safeguards, avoiding the new provider or a termination right.
Incident, deletion or audit language cannot be used in practice
A clause can exist and still fail operationally. Examples include incident notices without minimum information, deletion language that omits backups, or audit rights neutralised by unclear fees and long notice periods. Review whether the mechanism will deliver the evidence and response needed at the relevant time.
The main agreement contradicts the DPA
Liability caps, unilateral changes, termination effects and dispute provisions often sit outside the DPA. An isolated review may miss that the main agreement cuts back a promise in the data schedule. The result should identify both documents and propose an express order of precedence.
A practical review sequence
Start with the service, data flow and roles. Then assess security, subprocessors and transfers against that factual picture. Mark every check as resolved, open or requiring negotiation and link the status to the relevant clause or missing schedule.
For each open point, record the practical risk and the change you need. That produces a negotiation list that another reviewer can understand, rather than a set of abstract concerns.
A defensible review ends with a short decision record: which issues must be resolved before signature, which can be closed through a side letter, and which remain as consciously accepted residual risk. Each issue should have a source clause, owner and next step so a second reviewer can understand the decision.
How AI can support a DPA review
AI can structure a long contract set, find terms and cross-references, map clauses to the twelve checks and compare the text with an internal standard. It can also prepare a first drafting proposal.
A useful instruction is: "Review this agreement against the following twelve checks. For each check, identify the clause, summarise the current wording, state one open question and propose an amendment. Do not assume that a missing schedule exists."
Treat the output as work product. Verify the cited clause, completeness and legal analysis. CASUS Risk Review can structure the analysis, while CASUS Chat Actions help prepare specific changes. The security page explains the technical and organisational basis for using CASUS.
To test the workflow with an approved document, try CASUS.
FAQ
When is a DPA required?
A DPA is generally required where a provider processes personal data on behalf of a controller. The actual allocation of decisions and tasks matters more than the contractual label.
Is a vendor's standard DPA sufficient?
It may be a useful starting point. You still need to test the service scope, data, security, subprocessors, transfers, incident duties, deletion and audit rights against the planned use.
Must every subprocessor be approved individually?
Not always. A general authorisation may be used where changes are notified and the controller has a meaningful opportunity to object or otherwise respond.
Can the processor wait 72 hours before reporting a breach?
Under the GDPR, the processor must notify the controller without undue delay. The separate 72-hour period concerns the controller's notification to the authority where the statutory conditions are met.
Can AI give final approval to a DPA?
No. AI can find, organise and draft. Final approval requires a human review of the complete agreement, the actual processing and all referenced schedules.
