GDPR Subprocessor Change Notices: The Article 28 Notification Workflow

GDPR Subprocessor Change Notices: The Article 28 Notification Workflow

A subprocessor change notice is the advance notification a processor must send before adding or replacing a subprocessor under general written authorisation. GDPR Article 28(2) requires the controller to be informed of intended changes and given a genuine opportunity to object before the new subprocessor starts processing. The Regulation sets no fixed notice period — that is a contractual matter — but EDPB Opinion 22/2024 (adopted 7 October 2024) tightened what a meaningful notice now looks like: enough detail and enough time for an informed objection, backed by a sub-processor list kept up to date at all times. This guide covers the workflow itself — what the notice must contain, how long the window should be, how to handle objections, and who to notify.

Subprocessor change notices at a glance

Question	Short answer
When is a notice required?	Before adding or replacing a subprocessor under general written authorisation (Art. 28(2)).
Statutory notice period?	None. The window (typically ~15 days in Europe) is set in the DPA, not the GDPR.
What must it contain?	Identity + contact, processing description, location/transfer mechanism, security guarantees.
Can silence equal consent?	Only under general authorisation, and only with genuine, informed, timely notice. Never under specific authorisation.
Who receives it?	Every controller whose data the subprocessor will touch — proactively, not on request.
Where does it live?	A current subprocessor register + an active alert channel (email subscription / Trust Center).

Key takeaways

1. Article 28 sets the trigger, the DPA sets the clock. The duty to notify and allow objection is statutory; the number of days is contractual — make it operationally enforceable, not just a clause.
2. A change notice is a document with required fields, not a one-line email. After EDPB Opinion 22/2024, "we added Vendor X" is not enough for non-trivial processing.
3. The objection path has to exist before someone objects. Define what happens — workaround, or termination of the affected services — in advance.
4. Notification is push, not pull. Controllers must be informed in time to object; expecting them to watch a web page does not discharge the obligation.
5. This is a workflow, not a page. Register, notice, subscriber alert, objection handling, and audit trail are one connected system — which is exactly what a Trust Center operationalises.

What GDPR Article 28 actually requires

Subprocessor change notices exist because of one sentence in Article 28(2) of the GDPR:

"In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes."

Three obligations follow from it, and a fourth from the surrounding text:

• Inform of intended changes. The notice must be given for intended — i.e. advance — additions or replacements, in writing (Article 28(9) requires the Article 28 arrangement, including electronic form, to be in writing).
• Give a real opportunity to object. The objection right cannot be theoretical. The controller must have enough information and enough time to assess the new subprocessor and decide.
• Impose equivalent obligations down the chain (Article 28(3)(d) and 28(4)). When a subprocessor is engaged, the processor must flow the same data-protection obligations down to it and remains liable to the controller for that subprocessor's compliance.

What Article 28 deliberately does not do is set a number. There is no statutory "30 days." The Regulation requires prior information and an opportunity to object; the concrete deadline lives in your Data Processing Agreement. This is confirmed by the UK ICO's guidance, which tells processors to set out "the date by which the controller should raise any objections" — the need to state a date is precisely because the GDPR does not fix one.

For the full picture of how subprocessor lists, due diligence, and Article 28 contract terms fit together, see our companion guide on subprocessor management under GDPR Article 28. This page goes deeper on the one piece most teams handle badly: the change notice itself.

Specific vs. general authorisation — and why it changes the notice

Article 28(2) offers two routes, and they produce different workflows:

• Specific authorisation. The controller approves each subprocessor individually before it is engaged. There is no "notice and object" — there is "request and approve." Crucially, EDPB Opinion 22/2024 states that under specific authorisation, silence must be treated as no consent: if the controller does not respond within the requested timeframe, the processor cannot proceed.
• General authorisation. The controller gives blanket approval subject to being told about changes and retaining the right to object. This is what most B2B SaaS companies use, and it is what generates a recurring change-notice workflow.

The two are not interchangeable. A general-authorisation DPA may provide that a controller who does not object within the window is deemed to accept the change — but, per EDPB Opinion 22/2024, only where that controller received genuine, informed notice with enough time to act. Deemed acceptance built on a notice nobody could realistically evaluate is the kind of "theoretical" objection right the Regulation rules out.

What a subprocessor change notice must contain

Before October 2024, a lot of notices were a single line: a company name and a service category. EDPB Opinion 22/2024 raised that floor. The Opinion requires processors to keep an up-to-date list of all sub-processors and to proactively provide controllers with the information they need to meet their own Article 28 duties. For each (sub-)processor that means:

Field	Why it's required
Name and address	Basic identification of the entity processing the data.
Contact person (name, role, details)	So the controller can direct due-diligence questions.
Description of the processing	What the subprocessor does, and a clear delineation of responsibilities where several processors are involved.
Location of processing + transfer mechanism	Whether data leaves the EEA and on what basis (SCCs, adequacy) — essential after Schrems II.
Security guarantees	Certifications (ISO 27001, SOC 2) or a summary of technical and organisational measures, so the controller can assess "sufficient guarantees" under Article 28(1).

The depth is risk-based. For low-risk processing a controller may reasonably rely on summary information; for higher-risk processing the EDPB expects more — which means your notice for a new analytics pixel and your notice for a new sub-processor handling special-category data should not look identical. A name-only line item is no longer defensible for anything non-trivial.

How long should the notice window be?

The GDPR does not say, so practice fills the gap. The benchmarks that appear most often in European DPAs:

• ~15 days — the typical European notice window, and the practical default in most EU DPAs. Long enough to assess a change, short enough to keep subprocessor onboarding moving.
• 30–60 days — the usual negotiated range, requested by enterprise and regulated controllers who need time to run internal reviews or transfer impact assessments.
• 90 days — increasingly rare. In the age of AI-accelerated vendor review, controllers seldom need three months to evaluate a single subprocessor change, and processors resist locking onboarding for that long.

Whatever you choose, EDPB Opinion 22/2024 reframes the test: the window must be long enough for a meaningful, informed objection, not merely long enough to satisfy a clause. A notice window measured in a handful of days on a high-risk subprocessor change, delivered over a holiday period, is the kind of arrangement a supervisory authority could find inadequate even though the number is written into the contract.

The objection workflow: what happens when a controller says no

A right to object is only real if there is a defined consequence. Your DPA should spell out the path before anyone uses it. The standard model:

1. Controller objects in writing within the notice window, ideally with a stated reason.
2. Processor makes reasonable efforts to accommodate — for example, not routing that controller's data to the new subprocessor, or offering an alternative configuration.
3. If no workaround is feasible, the controller may terminate the affected services without penalty, typically with a defined wind-down period.

The point is to remove ambiguity. An objection should trigger a known process, not a negotiation that starts from scratch each time. Document each objection and its resolution — it is part of the audit trail your DPO and your customers' DPOs will both want to see.

Who to notify — and why "push" beats "pull"

A change notice only counts if it reaches the controllers it affects, in time. Two failure modes are common:

• The buried email. A notice sent to a generic procurement inbox that nobody monitors does not give a "real opportunity to object."
• The silent web page. Many processors publish a public subprocessor list and treat updating it as notice. EDPB Opinion 22/2024 is explicit that a web page is acceptable only if it is kept current at all times, carries the required detail, and is paired with an active alert — an email subscription or equivalent — so controllers are actually informed rather than expected to police the page themselves.

The workable pattern is a subscriber model: controllers (and their DPOs) opt in to notifications for your subprocessor list, and every addition or replacement triggers a structured alert with the required fields and a clear objection deadline. That is exactly the kind of recurring, governed communication a Trust Center's trust-update workflow is built to run — and it doubles as evidence that you notified, when, and with what content.

What EDPB Opinion 22/2024 changed

EDPB Opinion 22/2024, adopted on 7 October 2024, is the most important recent development for this workflow. It does not rewrite Article 28, but it sharpens the expectations around it:

• Whole-chain visibility. Controllers must be able to identify every processor and sub-processor in the chain — not just the first tier — and verify that each provides sufficient guarantees, with the depth of verification scaled to risk.
• Proactive, always-current lists. Processors must "keep this information regarding all engaged sub-processors up to date at all times" and provide it without waiting to be asked.
• No minimalist notices. For higher-risk processing, a notice that omits location, transfer mechanism, or security information does not let the controller make the informed decision the Opinion requires.
• Silence ≠ consent under specific authorisation. Deemed acceptance is confined to genuine general-authorisation scenarios with adequate notice.

The net effect: the common "subprocessor page plus a 30-day email window" model still works, but only if it is enriched and integrated. Names on a page are out; structured, current, push-notified records are in.

The UK and Norway/EEA position

The change-notice obligation is not an EU-27 quirk — it travels across the European compliance landscape:

• United Kingdom. Under UK GDPR (retained post-Brexit and supervised by the ICO), Article 28 applies in the same form: no subprocessor without prior specific or general written authorisation, advance notice of intended changes under general authorisation, an equivalent-protection contract down the chain, and continuing processor liability. The ICO's contracts-and-liabilities guidance mirrors the EU position, including the instruction to state an objection deadline in writing.
• Norway and the EEA. Norway applies the GDPR through the personopplysningsloven, supervised by Datatilsynet, via the EEA Agreement. Article 28's authorisation-and-objection mechanism applies identically; there is no separate national rule that softens the change-notice duty. EEA controllers selling into the EU expect the same notice quality as their EU peers.

For a controller operating across the EU, EEA, and UK, the practical conclusion is one workflow, not three: a single change-notice process that satisfies the strictest reading covers all of them.

Turning the obligation into a workflow

The reason subprocessor change notices go wrong is rarely a missing clause — it is the absence of a system to execute the clause. The register drifts out of date, a change ships before the notice goes out, the objection window is enforced inconsistently, and there is no record of who was told what.

A Trust Center closes that gap by making the whole sequence one connected workflow: a public, always-current subprocessor list; a subscriber base of controllers and DPOs; structured change notices with the EDPB-expected fields; an enforced objection window; and an immutable audit trail of every notice and objection. For legal teams in particular, this moves subprocessor governance off the manual to-do list — see Trust Center for legal teams for how the same layer handles DPAs and NDA gating. And because NIS2 and DORA push the same way (NIS2 Article 21(2)(d) supply-chain security, DORA's ICT subcontracting rules in Articles 28–30), the workflow you build for GDPR notices does double duty across your EU obligations.

If you want to see it running, Orbiq's trust-update workflow issues subprocessor change notices to subscribed controllers, enforces the objection window, and keeps the audit trail automatically.

Frequently asked questions

What is a GDPR subprocessor change notice?

It is the advance notification a processor sends to a controller before adding or replacing a subprocessor under general written authorisation (Article 28(2)). It must identify the new subprocessor, describe the processing and any third-country transfer, and give the controller a genuine opportunity to object before the change takes effect.

How much notice does GDPR require?

GDPR sets no fixed period. It requires only that the controller be informed of intended changes in time to object before processing starts. In Europe the typical window is around 15 days, with 30–60 days the usual negotiated range and 90 days increasingly rare — all set by the DPA. EDPB Opinion 22/2024 adds that the period must be long enough for a meaningful, informed objection.

Can silence be treated as consent?

Under general authorisation, a DPA can deem a non-objecting controller to have accepted a change — but only where the controller had genuine, informed notice and enough time to object. Where specific authorisation is required, silence must never be treated as consent.

What must a notice contain in 2026?

After EDPB Opinion 22/2024: the subprocessor's name, address, and contact person; a description of the processing and the delineation of responsibilities; the processing location and any transfer mechanism; and enough security detail (certifications or measures) for the controller to assess "sufficient guarantees" under Article 28(1).

What happens if a controller objects?

It depends on the DPA. The standard path is that the processor makes reasonable efforts to accommodate the objection, and if none is feasible, the controller may terminate the affected services without penalty. Define this before an objection ever arises.

Does a public subprocessor page satisfy the obligation?

Not by itself. A web page works as a mechanism only if it is kept current at all times, carries the required detail, and is paired with an active alert so controllers are actually informed in time to object.

Sources & References

1. Regulation (EU) 2016/679 (GDPR) — Article 28 — processor obligations, subprocessor authorisation (28(2)), contract terms (28(3)), flow-down and liability (28(4)).
2. EDPB Opinion 22/2024 on certain obligations following from the reliance on processors and sub-processors — adopted 7 October 2024; whole-chain verification and up-to-date sub-processor information.
3. EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR — Version 2.1; controller-processor and subprocessor relationships.
4. ICO — Contracts and liabilities between controllers and processors (what needs to be in the contract) — UK GDPR position on subprocessor authorisation and objection.
5. Commission Implementing Decision (EU) 2021/915 — Standard Contractual Clauses between controllers and processors — Article 28(7) SCCs covering subprocessor engagement.
6. Datatilsynet (Norway) — Data protection authority — supervision of the GDPR via the personopplysningsloven and the EEA Agreement.

Related Reading

• Subprocessor Management Under GDPR Article 28: What Controllers Actually Expect
• GDPR Articles 28, 32, 33, and 34: Why an ISMS Is Not Enough
• Trust Center for Legal Teams
• What Is a Trust Center?
• NIS2 Supply Chain Security: Requirements, Gaps, and How to Comply
• DORA Compliance: ICT Third-Party Risk Management
• Trust Updates — keep customers informed automatically