The moment to fix a Data Processing Agreement (DPA) is before signature; afterward, you operate whatever you accepted. For the sub-processing dimensions of a DPA, that means reviewing a small number of clauses with outsized operational consequences: the authorization model, the notice period and objection mechanics, where the authoritative subprocessor list lives, how notifications reach you, flow-down to subprocessors, transfer provisions, audit rights, and what happens at the end of the engagement.
This checklist works through those clauses in review order. The legal frame is Article 28 of the General Data Protection Regulation (GDPR), which defines what a controller-processor contract must contain; the broader requirements are covered in GDPR Article 28 DPA requirements. A useful neutral benchmark throughout is the European Commission's set of standard contractual clauses for controller-processor relationships, adopted under Article 28(7) in Decision (EU) 2021/915; when a vendor's drafting departs sharply from what the Commission considered balanced, that departure deserves a reason. One framing note before starting: this is guidance for structuring the review, not legal advice, and the calls belong to your counsel.
Authorization model, notice, and objection
General or specific authorization
Article 28(2) permits sub-processing only with the controller's prior written authorization, which comes in two forms. Specific authorization means each subprocessor engagement needs your approval before it happens: maximum control, maximum friction. General authorization means the processor may engage subprocessors, but must inform you of intended additions or replacements and give you the opportunity to object: it scales, but it shifts the burden onto you to notice the notice and react in time. Most software-as-a-service (SaaS) DPAs propose general authorization. The Commission's standard clauses present both models as drafting options with a notice period left to be specified, which is a useful reminder that neither model is exotic and that the notice period is a genuine negotiation variable rather than a fixed feature of the law.
Note also what the signature itself does: the subprocessors on the list at signing are typically authorized as part of entering the DPA. Reviewing the initial list is therefore part of the DPA review, not a separate exercise for later, and any entry you would want to object to is far easier to raise before signature than through the objection mechanism afterward.
What a workable notice period looks like
The GDPR does not set a minimum notice period; the contract does. Review the proposed period against your internal reality: how long does it actually take your organization to assess a new subprocessor once counsel, security, and the business owner are all involved? Check the units, calendar days or business days. Above all, check when the clock starts: on an email to a named contact, or on publication of an updated page you were never separately told about. A clause that starts the clock at page publication quietly converts your objection right into a monitoring obligation.
Objection mechanics and consequences
Read what objecting actually requires and what it achieves. How must an objection be made: in writing, to which address, by when within the window? And what follows a well-founded objection: some DPAs let the processor propose a remediation or an alternative, while many provide only that you may terminate the affected services, with or without a pro-rated refund. Check for deemed-acceptance language, where continued use after the window counts as approval. An objection right whose only outcome is your own termination is thin, but knowing that before signature changes both what you negotiate and how you triage notices afterward.
The subprocessor list: annex or URL
Subprocessor lists appear in two formats: an annex frozen at signature, or a URL the processor updates over time. Each answers a different question. The annex records what you authorized on day one; the URL claims what is true today. The review point is which one controls when they diverge, and the DPA should say so explicitly. If the URL is authoritative, record the exact URL in the agreement, require that updates to it be dated, and check whether the processor commits to keeping the URL stable rather than moving the list quietly. If the annex is authoritative, ask how it gets amended when the list changes, because an annex nobody re-executes goes stale by design.
Check what the list actually names, too. Some lists identify concrete legal entities with locations and functions; others name only categories of service provider. The tighter the identification, the more meaningful your authorization and the easier every later transfer assessment. If the proposed list is categorical, ask for entity names and locations, and treat reluctance as information in its own right.
The notification channel
The most operationally consequential clause is often the least examined: where does the notice actually arrive? Drafting in the wild ranges from email to a named contact, through mailing lists you must remember to subscribe to, to in-product banners, to notice-by-publication, where updating the page is itself the notification. Review for one property above all: does the channel reach a monitored, role-based inbox that survives personnel changes? A notice sent to a person who left the company is a notice sent nowhere.
If the DPA offers only notice-by-publication, the monitoring burden is entirely yours. That can be acceptable, but only if it is accepted deliberately and priced into how you operate, not discovered later. Negotiating an email notification to a role-based address is one of the cheapest asks in the whole document, and it is worth making. Whatever channel you end up with, keep evidence of notices as they arrive: if a dispute ever turns on whether notice was given and when, a searchable mailbox and a dated capture of the page beat anyone's memory. How notices arrive in practice, and how teams route and handle them, is covered in subprocessor change notifications.
Flow-down, transfers, and audit rights
The flow-down warranty
Article 28(4) requires that when a processor engages a subprocessor, the same data protection obligations as set out in your DPA are imposed on that subprocessor by contract, and that the initial processor remains fully liable to you for the subprocessor's performance. Review the DPA's restatement of this for dilution: the statutory standard is the same obligations, so weaker formulations such as substantially similar or materially equivalent deserve a counsel review rather than a silent pass. The full-liability sentence matters just as much; it is what keeps your remedy pointed at the party you actually contracted with.
Transfers and TIA cooperation
Where subprocessors process personal data outside the European Economic Area (EEA), check which transfer mechanism the DPA incorporates and how: Standard Contractual Clauses (SCCs) incorporated by reference with the module identified, or another lawful route described concretely. Then check for cooperation duties: does the processor commit to providing the information you need to conduct and maintain a Transfer Impact Assessment (TIA) across the chain, including where subprocessors are located and what they do? A processor that resists information requests before signature will not become more forthcoming after it.
Audit and information rights
Article 28(3)(h) entitles you to the information necessary to demonstrate compliance and requires the processor to allow and contribute to audits. The practical review is about mechanics: do you have question rights short of a full audit; will the processor accept third-party audit reports in place of on-site exercises; are there frequency limits or notice requirements; and who bears the cost. For most small and mid-sized enterprise (SME) relationships, the realistic audit right is written questions plus existing reports, so make sure the clause supports at least that without a fight.
Deletion, return, and liability basics
End of engagement
Article 28(3)(g) gives you the choice, at the end of services, between deletion and return of the personal data, with existing copies deleted unless law requires their retention. Review the mechanics the DPA attaches: how long after termination, whether deletion is certified on request, and how backups are handled. A carve-out for backup systems is common and workable when it comes with a defined expiry, and quietly open-ended when it does not.
Liability, briefly
Check where DPA liability sits relative to the master agreement's limitation of liability: inside the general cap, carved out, or under a separate cap. Check that the processor's full liability for its subprocessors, consistent with Article 28(4), is not contradicted elsewhere in the stack of documents. And keep in mind that statutory positions, including data subjects' rights to compensation under the GDPR, operate regardless of what the parties agree between themselves. This part of the review is dense and consequential; the checklist's job is to make sure the questions get asked, and counsel's job is to answer them.
Negotiation priorities with limited leverage
Much of a large provider's DPA is effectively non-negotiable for an SME, which makes prioritization the actual skill. Push hardest on asks that cost the provider little and protect you most.
- A named, role-based email address as the notification channel for subprocessor changes
- The authoritative list URL written into the DPA, with updates dated
- A notice period long enough for your real internal turnaround, in units you checked, with a start trigger you can live with
Rarely winnable, and usually not worth the negotiating capital: uncapped liability, bespoke on-site audit rights, or specific authorization from a high-volume SaaS provider. Where a term will not move, compensate operationally rather than walking away from an otherwise sound vendor: shorten your own review turnaround, watch the list URL yourself, and calendar every window. Referencing the Commission's standard clauses can help here too, since asking for what the Commission drafted is hard to paint as unreasonable.
After signing: make it operational
A signed DPA is inert until its terms are wired into how the team works. Five steps in the week after signature cover most of it.
- Record the authoritative subprocessor list URL in your vendor inventory and put it under scheduled watch
- Turn the objection window into a computed deadline: any notice immediately produces a dated review task with an owner, not a mental note
- Point the notification channel at a shared, monitored mailbox and send a test through it
- Link the vendor to the records it affects, so a subprocessor change triggers review of the TIA and the Records of Processing Activities (RoPA) entry for that vendor
- Capture what the list said on signature day, dated, because that baseline is what every later change gets measured against
None of this is heavy process. It is five decisions made once, while the DPA is still fresh, instead of five improvisations later under a deadline. If you plan to tool the watching rather than run it by hand, the evaluation criteria are in the subprocessor monitoring software buyer's checklist.
Where DPAFlow fits in
The second half of this article, noticing changes, computing windows, keeping dated evidence, and documenting objection decisions, is the part DPAFlow operationalizes. Teams register the vendor's subprocessor list URL and DPA page on a watchlist; DPAFlow checks them on a scheduled, recurring basis, records changes with dated evidence including captured text, diffs, and screenshots where available, sends immediate or daily-digest email alerts, and provides a review workflow where the objection decision and its rationale are documented. How legal teams put that to work is described on the legal use-case page.