Clarify the task and decision
This guide turns dpa review checklist into a reviewable operating workflow. It connects domain decisions, ownership, evidence, and acceptance so the result continues to work in production.
A useful DPA review connects legal clauses to the actual system, subprocessors, deletion process, and assistance duties.
Practical workflow
- 1
Draw the data flow from collection through processing, logs, cache, support, backup, and deletion.
- 2
Classify each data category and connect it to purpose, legal role, location, recipient, and retention.
- 3
Request architecture, contractual, operational, and testing evidence for every material claim.
- 4
Score risk and record required controls, owners, acceptance evidence, and residual risk.
- 5
Approve only the documented configuration, then monitor subprocessors, incidents, changes, and deletion evidence.
Worked example or tool
A clause-to-control worksheet assigns evidence and owners to every review point. In the tool, also record the baseline, owner, decision, evidence, open issue, and approval date. Use a real page or transaction so the team sees dependencies, exceptions, and the maintenance work that follows release.
| Decision point | Record | Acceptance criterion |
|---|---|---|
| Baseline | Observed current state | Source and date recorded |
| Decision | Selected option and rationale | Risk and audience considered |
| Evidence | Test, document, or measure | Reviewable and version-specific |
| Approval | Name, role, and date | All mandatory criteria met |
Establish roles, instructions, and scope
Start by describing the service in operational terms: who submits content, which systems send it, what the provider returns, and which teams can access the result. Then classify the parties for each processing activity. A supplier can be a processor for customer text and an independent controller for account billing, security intelligence, or legally required records.
The agreement should define documented instructions broadly enough for ordinary operation but tightly enough to prevent secondary use. Cover configuration, support, troubleshooting, service monitoring, deletion, export, and exceptional access. State explicitly whether customer content, prompts, or outputs may be used for model training, human review, benchmarking, or product improvement.
Attach a current service description and data-category matrix. This avoids a contract that sounds complete but does not match the purchased configuration. The matrix should identify data subjects, special categories, volume, frequency, source systems, recipients, and the approved production purposes.
Name controller, processor, and any separate-controller activities.
List approved purposes and prohibit incompatible secondary use.
Describe data subjects, categories, systems, and expected volume.
Make the product configuration and service description part of the agreement.
Test security commitments and the subprocessor chain
Technical and organisational measures should be specific enough to audit. Look for identity controls, privilege review, encryption, tenant separation, secure development, vulnerability remediation, backup protection, restoration tests, logging, physical security, staff confidentiality, and incident exercises. Ask which measures are standard, optional, or dependent on the selected plan.
The subprocessor schedule should name the legal entity, service, location, processing purpose, and transfer mechanism. Require advance notice of changes and a workable objection process. A generic right to terminate is weak if the organisation cannot export its data or replace the service within the notification period.
Trace one request through the full chain and reconcile every recipient with the schedule. Include cloud hosting, model inference, content moderation, support, observability, email, and backup services. Unexplained recipients or broad categories should be resolved before signature.
- 1
Map contract controls to the organisation's minimum security standard.
- 2
Request dated evidence for high-risk measures and test the evidence scope.
- 3
Reconcile the architecture diagram with every listed subprocessor.
- 4
Set a change-notification period that permits assessment and migration.
Design rights, deletion, and assistance duties
Assistance clauses need measurable operating detail. Define how the provider helps locate, export, correct, restrict, or delete data and how quickly it responds. Clarify whether search covers prompts, outputs, logs, backups, support tickets, and derived identifiers. For a shared service, confirm that assistance cannot expose another customer's data.
Define deletion events for individual records, workspace closure, contract termination, expired backups, and support artefacts. Record standard completion periods, verification evidence, and lawful exceptions. If backups cannot be selectively edited, require isolation from normal use, fixed expiry, and propagation of deletion when a backup is restored.
The provider should support impact assessments, security enquiries, supervisory-authority requests, and prior consultations with relevant information. Agree what is included in the service fee, what may be charged separately, and which contacts receive urgent requests.
Set response targets for rights requests and compliance enquiries.
Cover live systems, logs, support systems, archives, and backups.
Define deletion evidence and treatment after backup restoration.
Name operational and escalation contacts for urgent assistance.
Close gaps before signature and govern the agreement
Use a clause-and-evidence tracker with columns for requirement, contract reference, evidence, owner, gap, action, and decision. This turns a long legal review into an accountable workflow. Mandatory gaps should block production use or lead to an explicit reduction in data scope, not disappear into an unsigned risk note.
For example, if the provider retains security logs for ninety days but the organisation expected thirty, decide whether the logged fields contain customer content, whether pseudonymisation reduces exposure, and whether the longer period is necessary. Record the conclusion in the processing inventory and user-facing retention information.
After signature, review the agreement when the service adds a model, region, subprocessor, purpose, or material feature. Reconcile changes with the technical configuration and processing inventory. Contract ownership should sit with a named role that can coordinate legal, security, procurement, and product teams.
- 1
Resolve every mandatory gap before enabling production data.
- 2
Record accepted residual risks with scope, controls, owner, and review date.
- 3
Store the signed agreement, schedules, evidence, and configuration together.
- 4
Trigger reassessment for material service and supplier changes.
Roles, evidence, and approval
Security and privacy reviews must describe the production configuration rather than a generic provider. Record the exact service, region, feature flags, optional telemetry, support access, subprocessors, encryption boundaries, retention settings, and customer responsibilities. Reassess after material architecture, contract, provider, or purpose changes and keep the decision linked to the evidence reviewed.
Operations and maintenance
The work does not end at publication. Link the language version or configuration to its source, monitor quality and service measures, and define concrete review triggers. Triggers include source changes, legal changes, new audience needs, recurring support questions, technical changes, and incidents. A named owner evaluates the trigger, opens a new revision when needed, and records renewed approval.
Release checklist
The complete processing path is documented.
Controller and processor roles are agreed.
Locations and subprocessors are evidenced.
Training and secondary use are explicitly addressed.
Access, encryption, logging, and incident controls are verified.
Retention and deletion are defined per data category.
International transfers and safeguards are documented.
Changes, audits, exit, and evidence ownership are assigned.