Review a data processing agreement against the real service

A data processing agreement becomes useful when its description matches the actual service. A complete-looking contract can still describe the wrong data, omit a support provider, or promise deletion that the product cannot perform.

For a CTO, the review connects legal commitments to architecture, configuration and operating procedures. Legal or privacy colleagues interpret the clauses; engineering establishes whether those clauses describe reality. The output should be a defensible service decision, supported by evidence and a clear list of unresolved conditions—not simply a signed PDF.

Establish the supplier’s role before reviewing clauses

Start by determining whether the supplier acts as a processor for the relevant processing. Under the GDPR, a processor processes personal data on behalf of a controller. Not every vendor relationship has that role, and one supplier can have different roles for different activities.

A hosted support platform may process customer tickets under your instructions while acting as a separate controller for some of its own account administration. If its terms also permit using ticket content for independently determined purposes, that activity needs separate analysis. Calling everything “service improvement” does not settle the role.

Prepare a short scope statement before marking up the agreement:

• Identify the contracting entity, product, subscription tier and enabled features.
• Describe why your organization uses the service and whose personal data it handles.
• Separate instructed processing from any supplier-defined purposes.
• Name the internal service owner and the legal or privacy reviewer.

A DPA is not an Article 6 lawful basis, nor does it automatically satisfy international-transfer requirements. Those questions remain separate. If your organization is itself a processor, identify the upstream controller’s instructions and authorization conditions before engaging the supplier as a subprocessor.

Build an Article 28 review matrix

Article 28 GDPR requires a binding contract or other qualifying legal act governing processor activity. It must describe the subject matter and duration, nature and purpose, personal-data types, data-subject categories, and the controller’s rights and obligations.

These details should identify the actual processing. “All data necessary to provide services” may leave reviewers unable to determine whether employee records, customer messages or sensitive attachments are covered. Check annexes against the configured product, including optional integrations.

Use the following matrix to examine the required processor duties. The evidence column contains practical review recommendations, not a statutory requirement to obtain each named document.

The processor must also immediately inform the controller if, in its opinion, an instruction infringes applicable data-protection law. Check where that notification goes and who can resolve it.

Mark each requirement as covered, unclear or missing, with a clause reference. Do not classify a mandatory omission as an ordinary commercial preference. Article 28(1) also requires controllers to use processors providing sufficient guarantees; contractual wording alone cannot establish that.

Trace a representative record through the service

Choose a realistic record and follow it from ingestion to disposal. For a customer-support service, this could be a ticket containing a name, email address, account identifier and attachment. Prefer synthetic data when testing.

Map collection, API ingestion, primary storage, indexing, analytics, support access, exports, integrations, backups and deletion. Ask which components receive content and which receive only metadata. Logs and diagnostic traces often contain identifiers even when the main application is correctly scoped.

For every stage, record the responsible entity, processing purpose, location, access path and retention period. Compare the result with the DPA, security annex, subprocessor list and transfer arrangements.

Pay particular attention to features that administrators can activate without procurement involvement: transcription, enrichment, AI summarization, external webhooks and support-session recording. A contract reviewed for the base product may not adequately describe the enabled service.

The deliverable can be a simple data-flow diagram and a discrepancy log. Each discrepancy should identify the contractual statement, observed behavior, consequence, owner and resolution. For example, “DPA describes customer-controlled retention; diagnostic logs remain for a fixed period” is actionable. “Retention unclear” is not enough to close the issue.

Test security promises against the implementation

Article 32 requires risk-appropriate security measures. It does not impose one universal technical configuration. Evaluate the measures against the data’s sensitivity, volume, exposure and likely consequences of compromise.

An annex should explain enough to assess the service, without requiring disclosure of exploit-sensitive details. Prioritize tenant isolation, privileged access, authentication, encryption, resilience, recovery, vulnerability management and testing. Identify the controls the vendor operates and the settings your team must configure.

If the agreement promises restricted support access, ask how access is requested, approved, time-limited and logged. If it promises encryption, distinguish protection in transit from protection at rest, then establish who controls keys and what authorized users can still read. Encryption does not resolve excessive application permissions.

For availability and recovery, determine which backups exist, how restoration is tested, and whether contractual recovery commitments cover the product you are buying. Keep commercial uptime targets distinct from security and privacy obligations.

Certificates and assurance reports can support the assessment, but their scope matters. Check the service, legal entity, assessment period, exclusions and customer responsibilities. A report about the hosting provider is not evidence for every control in the SaaS application, and certification does not establish GDPR compliance. See evaluating security assurance for the wider evidence review.

Where the security annex is incorporated through a web link, preserve the applicable version. Review whether changes can reduce protection and how customers are informed. Treat an undated, changeable page as an evidence-management problem to resolve, rather than assuming it is either automatically sufficient or automatically invalid.

Follow the subprocessor chain and assess transfers separately

Article 28(2) requires prior specific or general written authorization for engaging another processor. With general authorization, the processor must inform the controller of intended additions or replacements and provide an opportunity to object. Article 28(4) requires the relevant data-protection obligations to flow down; the initial processor remains fully liable to the controller for the subprocessor’s performance of those obligations.

Obtain a usable list showing each provider’s legal identity, function, relevant data and processing locations. Not every vendor dependency is a subprocessor, but infrastructure, support and analytics providers should not disappear from the review merely because they operate behind the product interface.

Evaluate the change mechanism:

• Does notice reach a monitored address or assigned owner?
• Is there enough information and time to assess the proposed change?
• How is an objection submitted and resolved?
• What happens if no acceptable alternative is available?

A contractual right that nobody can exercise operationally is a warning sign. Subscribe the appropriate team and record who evaluates notices.

EU hosting is relevant but does not finish the transfer assessment. Examine actual recipients, remote access arrangements, support locations and onward transfers. Equally, foreign ownership alone is not a complete description of a transfer: document the actual entities and access paths.

Where Chapter V applies, identify the relevant transfer mechanism and any necessary supporting assessment or measures. Keep this analysis connected to the supplier review, but distinct from Article 28 compliance. A DPA and a regional hosting setting do not independently answer all transfer questions.

Make assistance obligations executable

Breach notification and incident handoff

Under Article 33(2), a processor must notify the controller without undue delay after becoming aware of a personal-data breach. The controller separately assesses supervisory notification, which is required without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to create a risk to individuals’ rights and freedoms.

Do not give the processor the controller’s deadline as its default waiting period. A practical contract should establish prompt initial notification, named channels and progressive updates. An agreed notification target is an operational recommendation; it does not replace the statutory standard.

Request the information needed to assess affected data, individuals, systems, likely consequences, containment and recovery. The first notice may be incomplete, so define how updates and evidence follow. The controller must also assess whether high risk requires communication to affected individuals under Article 34, subject to its exceptions, and document the breach assessment, including reasons for not notifying. Review the notification trigger carefully: a process that waits for a completed root-cause investigation may delay the controller’s assessment.

Test the handoff with a tabletop scenario. Confirm that the notice reaches incident responders and privacy reviewers outside normal business hours, rather than only an account manager.

Data-subject requests

The processor’s assistance should make your own rights-response process feasible. Test whether records can be located across content, attachments, indexes and exports, and whether deletion or correction reaches the relevant components.

Agree on the response route and expected turnaround. Controllers normally have one month to respond to a request, subject to the GDPR’s extension conditions; supplier assistance must leave room for identity checks, legal assessment and secure delivery. The vendor should ordinarily route requests concerning your instructed processing to you rather than independently deciding their outcome.

Charges and service limits deserve review. Fees for additional assistance are not automatically prohibited, but they must not make mandatory assistance ineffective. Connect the procedure to your subject-access request workflow.

Return, deletion and backups

At service end, Article 28 requires deletion or return at the controller’s choice, and deletion of existing copies unless Union or Member State law requires storage. Establish what that means technically before buying.

Check export completeness, format, availability window and whether attachments or configuration are excluded. For deletion, distinguish active records, caches, replicas, logs and backups. If backup deletion follows a scheduled cycle, document the period, access restrictions and measures preventing deleted records from being reintroduced through restoration.

Ask how completion is evidenced and how legally required retention is identified. Avoid relying on “account closed” as proof that personal data has been removed.

Review audit rights, liability and unresolved clauses

Audit provisions should provide meaningful assurance while protecting other customers and legitimate security interests. Reasonable scheduling, confidentiality and use of independent reports can make audits workable. However, a certificate-only clause with no route to obtain necessary information or address material concerns warrants legal review against Article 28(3)(h).

Determine the escalation path when evidence is insufficient, an incident occurs or a regulator requires information. Examine audit costs, notice periods and restrictions together; their combined effect matters more than any single phrase.

Liability clauses need a separate commercial assessment. Article 82 compensation depends on the regulation’s responsibility conditions; processors are not automatically liable for every controller failure. Where multiple parties are responsible under Article 82, the rules can expose them to the whole damage to ensure effective compensation. A contractual cap does not restrict individuals’ statutory rights. Its effect on allocation and recovery between the parties needs legal review.

If the vendor refuses amendments, distinguish three outcomes:

• Clarification: obtain authoritative wording or evidence that resolves ambiguity.
• Conditional acceptance: approve a lawful arrangement with documented commercial or operational residual risk and specified safeguards.
• Do not proceed: stop or redesign processing where required obligations remain unsatisfied.

Management acceptance cannot make an unlawful arrangement lawful. The DPO, where appointed, advises and monitors independently; the accountable business owner makes service decisions with legal and privacy input. Do not assign the DPO ownership of determining processing purposes or means.

Inspect AI features as additional processing paths

AI features introduce inputs, outputs and intermediate artifacts that older annexes may not describe. Review prompts, retrieved documents, embeddings, generated responses, feedback, abuse-monitoring records and human-review access where relevant.

Establish whether customer data is used to train or improve models, whose purposes that serves, and which entity performs the processing. “No training” is not equivalent to “no retention,” and neither promise proves that support logs or monitoring records contain no personal data.

Check that commitments apply to the purchased tier, enabled endpoints and downstream model providers. Confirm retention settings, exceptions and deletion behavior. If a supplier claims anonymization, ask what supports that claim rather than assuming that model artifacts are anonymous.

Record the contractual commitment and configuration evidence together. Any new purpose requires its own role and lawfulness assessment; the DPA does not supply that legal basis. AI Act applicability is also a separate question, not something satisfied by signing processor terms.

Worked example: support software with optional summarization

Assume, illustratively, that a SaaS business wants a support platform holding names, business email addresses, ticket text and attachments. Tickets may accidentally contain sensitive information. An optional AI feature summarizes conversations.

The draft DPA describes ticket processing and EU storage. The technical walkthrough reveals a summarization provider, support access from another region and diagnostic retention that differs from ticket retention.

The review produces four concrete actions:

1. Complete the scope. Add attachments, diagnostic identifiers and AI processing to the description; check whether the supplier uses any content for its own purposes.
2. Resolve the provider chain. Obtain the model provider’s identity, processing locations, retention commitments and authorization coverage. Assess relevant transfers separately.
3. Validate lifecycle behavior. Run a synthetic ticket through export and deletion. Obtain the backup and diagnostic retention explanation instead of assuming ticket deletion removes every copy.
4. Set a release condition. Keep summarization disabled until its contract and data flow are reviewed. Establish routing for breach notices and subprocessor changes before production use.

The decision record distinguishes evidence received from questions still open. If the core service is acceptable, approval can explicitly exclude the AI feature. That boundary must also exist in configuration and change control; a note in the review file will not prevent someone enabling it later.

Retain the decision and reopen it when the service changes

Keep the applicable contract version, processing scope, data-flow diagram, assurance evidence, transfer assessment, discrepancy log and approval together. Record accepted residual risks, conditions, owners and follow-up dates. Preserve the reason an arrangement was accepted, not just its status.

Review again when processing purposes, enabled features, subprocessors, locations or contractual terms materially change. Include significant incidents and new evidence of control weaknesses as triggers. A scheduled review complements these triggers rather than replacing them.

Secani can support this workflow by modeling the service and external providers, linking evidence to requirements and decisions, and assigning review gaps to owners. Human-reviewed conclusions, source links, comments and approvals preserve the reasoning behind acceptance. This connects the contract review to third-party risk management without treating software as a substitute for legal or technical judgment.

Does the agreement need a handwritten signature?

Article 28(9) requires written form, including electronic form. A handwritten signature is not inherently required. Preserve evidence of binding acceptance and the version in force; ask legal reviewers to resolve uncertainty about online incorporation or conflicting terms.

Must every subprocessor be named inside the DPA?

Article 28 does not prescribe a fixed in-document list. A maintained list can support authorization, provided the arrangement delivers the required information, change notices and opportunity to object. Preserve the list relevant to your review.

For the next supplier review, start with one representative data flow and the Article 28 matrix. Resolve the mismatch between contractual promises and observable operation before authorizing production processing.