Orbiq LogoOrbiq
Subprocessor Management Under GDPR Article 28: What Controllers Actually Expect
2026-02-23
By Anna Bley

Subprocessor Management Under GDPR Article 28: What Controllers Actually Expect

What do controllers, DPOs, and procurement teams actually expect from your subprocessor management? A practical guide beyond GDPR Article 28 minimum compliance — covering sub-processor lists, change notifications, data flow transparency, and ongoing due diligence.

GDPR
Data Protection
Subprocessors
Compliance

Subprocessor Management Under GDPR Article 28: What Controllers Actually Expect

Most SaaS companies have a subprocessor list somewhere. It's in a PDF, attached to the DPA, last updated six months ago. Technically, that's not wrong. Operationally, it's not enough. This article explains what controllers, DPOs, and procurement teams actually expect when they evaluate how you manage subprocessors — and why the gap between "compliant on paper" and "trustworthy in practice" matters more than you think.

TL;DR

GDPR Article 28 requires processors to get controller authorisation before engaging subprocessors (also called sub-processors), impose equivalent data protection obligations, and remain liable for subprocessor compliance. Most companies handle this through a static list in their DPA. But controllers increasingly expect more: proactive change notifications, transparent data flows, and continuous visibility into your subprocessor landscape. A trust center makes this operational — not as a compliance checkbox, but as a living system your customers can actually use.

What Article 28 Actually Requires

Let's start with the text. Article 28(2) and 28(4) establish two models for subprocessor authorisation:

Specific prior authorisation — the controller approves each subprocessor individually before engagement. This gives the controller maximum control, but it's operationally heavy for both sides.

General written authorisation — the controller gives blanket approval for the processor to engage subprocessors, subject to two conditions: the processor must inform the controller of any intended additions or replacements, and the controller must have the opportunity to object.

Most B2B SaaS companies operate under general authorisation. It's the practical choice. But "general authorisation" doesn't mean "do whatever you want" — it means "we trust you to manage this transparently, and we retain the right to object."

Article 28(4) adds that subprocessors must be bound by the same data protection obligations as the processor. If your subprocessor fails, you're liable — not them.

That's the legal framework. These GDPR processor obligations are well-documented. Now here's what happens in practice.

What Controllers Actually Expect

If you sell to European enterprise customers, your subprocessor management is evaluated during procurement, monitored during the relationship, and scrutinised during audits. Here's what DPOs and procurement teams are looking for — beyond the DPA.

1. A Current, Public Subprocessor List

This sounds basic, and it is. But "current and accessible" means something different to a DPO than it does to most SaaS companies.

What most companies do: A table in the DPA or a PDF on a legal page, updated when someone remembers to update it. Sometimes the list is behind a login or an NDA request.

What controllers expect: A publicly accessible, clearly structured list showing each subprocessor's name, purpose, data categories processed, hosting location, and country of incorporation. Updated within days of a change — not months.

The difference matters because DPOs use your subprocessor list to maintain their own records of processing activities (Article 30). If your list is outdated, their records are wrong. If your list is buried in a PDF, they have to manually extract it. If it's behind an NDA, they have to explain to their legal team why they need to sign an NDA to see who processes their data.

Make it easy. Make it public. Make it current.

2. Proactive Subprocessor Change Notifications

Article 28(2) requires that under general authorisation, controllers are "informed of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object."

What most companies do: Update the subprocessor list quietly. Maybe send an email if the change is significant. Often, the controller discovers the change during their own annual vendor review.

What controllers expect: Written notification before the change takes effect, with enough detail to evaluate the impact: who is the new subprocessor, what data will they process, where are they located, what security measures are in place, and what's the timeline.

The notice period matters. Most DPAs specify 30 days, but some enterprise customers negotiate 60 or 90 days. Whatever you've agreed to, the operational question is: do you have a system that reliably sends these notifications, or does it depend on someone remembering?

3. Meaningful Objection Rights

The right to object is in the regulation, but how it works in practice varies enormously.

What most companies do: The DPA includes an objection clause, but the practical mechanism is unclear. Can the controller actually block a subprocessor change? What happens if they object — do you revert? Do you offer termination rights?

What controllers expect: A clear process. If a controller objects to a new subprocessor, what are the options? Typically, this means: the processor will make reasonable efforts to find an alternative, and if no alternative is feasible, the controller can terminate the affected services without penalty.

The important thing is to have this defined before anyone needs to use it. Enterprise DPOs will check during procurement.

4. Data Flow Transparency

Subprocessor management isn't just about who — it's about what data goes where.

What most companies do: The subprocessor list names companies and maybe describes their function ("cloud hosting," "email delivery," "analytics").

What controllers expect: Enough detail to understand the data flow. Which categories of personal data does each subprocessor access? Is it stored or transient? Is it in the EU or transferred internationally? If transferred, under what mechanism (adequacy decision, SCCs, binding corporate rules)?

This is where the CLOUD Act conversation becomes practical, not theoretical. If your subprocessor is a US company, controllers want to know: is there a transfer impact assessment? What supplementary measures are in place? Simply listing "AWS" isn't sufficient if the controller needs to document their own compliance under Schrems II.

5. Evidence of Subprocessor Due Diligence

Article 28(1) says controllers should only use processors that "provide sufficient guarantees to implement appropriate technical and organisational measures." By extension, your subprocessors need to meet the same standard.

What most companies do: Evaluate subprocessors during onboarding. Maybe check SOC 2 or ISO 27001 status once.

What controllers expect: Evidence that you continuously evaluate subprocessors — not just at onboarding but over the lifecycle. Have their certifications lapsed? Have they had security incidents? Has their data processing changed?

This is where the practical burden sits: maintaining ongoing visibility into your subprocessor landscape is work. Most companies don't do it systematically. The ones that do stand out in procurement evaluations.

Where Most Companies Fall Short

The pattern is consistent: the DPA is fine, the subprocessor list exists, but the operational infrastructure is missing.

Updates are reactive, not proactive. Someone adds a new subprocessor to the product, and six weeks later the legal team updates the list. Meanwhile, controllers have incorrect records.

Notifications are manual. There's no system — it's an email from legal, sent when someone remembers. If you have 200 enterprise customers, that's 200 individual notifications that need to go out with appropriate lead time.

Data flow documentation is shallow. "Subprocessor X provides analytics" doesn't tell a DPO what they need to know. What data? What jurisdiction? What transfer mechanism?

Due diligence is point-in-time. You checked the subprocessor's SOC 2 report when you signed the contract. That was two years ago. Their certification may have lapsed, their hosting may have changed, or they may have had a breach you don't know about.

Objection processes are theoretical. The DPA says controllers can object, but there's no operational workflow for handling objections. If a controller objects on day 25 of a 30-day notice period, what happens?

None of these are legal violations per se. But they're operational gaps that enterprise controllers increasingly identify — and that influence procurement decisions.

How a Trust Center Makes This Operational

This is where the concept connects: a trust center turns subprocessor management from a legal documentation exercise into a living, operational system. For legal teams handling DPAs, NDAs, and subprocessor due diligence, this shift is especially significant.

Public Subprocessor Page on Your Trust Center

Your subprocessors are visible by default — name, purpose, data categories, location, and legal basis for transfer. No PDF download, no NDA required for basic information. Controllers can check it anytime, and their records of processing stay current.

Change Notifications Built In

When you update a subprocessor, the trust center notifies affected customers automatically. No manual email list, no missed notifications. The notice period starts from the notification, creating a clear, auditable timeline.

Data Flow Visibility

Each subprocessor entry can include data categories processed, hosting region, and transfer mechanisms — structured in a way that DPOs can use directly in their Article 30 records. Not a paragraph of legal text; a clean, parseable table.

Continuous Due Diligence Evidence

If your trust center includes vendor assurance capabilities, you can show the current security posture of your subprocessors — not just their status at onboarding, but ongoing. Certifications, security ratings, last assessment date. This is the evidence that controllers want but rarely get.

Audit-Ready Documentation

When an auditor or DPA asks about your subprocessor management, the answer isn't "let me find the spreadsheet." It's a link to your trust center, where the current state is always visible, versioned, and timestamped.

The Practical Checklist

If you're evaluating how your subprocessor management holds up to what enterprise controllers actually expect, here's the list:

Subprocessor list:

  • Publicly accessible (no NDA required for basic information)
  • Includes name, purpose, data categories, hosting location, country of incorporation
  • Updated within days of changes, not months

Change notifications:

  • Proactive, written, before changes take effect
  • Include enough detail for the controller to evaluate the impact
  • Sent with the contractually agreed notice period (typically 30 days)
  • Auditable: you can prove when the notification was sent

Objection process:

  • Clearly defined in the DPA
  • Operationally supported: you know what happens if a controller objects
  • Includes termination rights if no alternative subprocessor is available

Data flow documentation:

  • Data categories per subprocessor
  • Hosting location and jurisdiction
  • Transfer mechanism for international transfers
  • Transfer impact assessment where applicable

Ongoing due diligence:

  • Subprocessor certifications tracked and current
  • Security posture monitored, not just assessed at onboarding
  • Process for handling subprocessor security incidents

Frequently Asked Questions

Do I need to list every subprocessor publicly?

No. Article 28 requires informing controllers, not the public. But making the list publicly accessible is increasingly expected by enterprise buyers — it reduces friction in procurement and helps controllers maintain their own compliance records. You can gate sensitive details (like specific security measures) while keeping the basic list public.

What's the right notice period for subprocessor changes?

Article 28 doesn't specify a minimum. Most DPAs set 30 days. Enterprise customers sometimes negotiate 60 or 90 days. Whatever you agree to, it should be operationally enforceable — meaning you have a system, not just a clause.

What happens if a controller objects to a new subprocessor?

This depends on your DPA. Typical approaches: the processor makes reasonable efforts to find an alternative, and if none is feasible, the controller may terminate the affected services. The important thing is to define this before it happens.

Does the subprocessor list need to include data categories?

Article 28 doesn't explicitly require data categories in the subprocessor list, but Article 30 requires controllers to document categories in their records of processing. If your list includes categories, you make their compliance easier — which makes your procurement evaluation smoother.

How does this relate to NIS2?

NIS2 Article 21(2)(d) requires supply chain security measures, including "security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Subprocessor transparency under GDPR and supply chain security under NIS2 are converging requirements — both demand ongoing visibility into your third-party dependencies. A trust center that handles subprocessor management also addresses a significant portion of NIS2 supply chain obligations.

Key Takeaways

  1. Article 28 sets the floor, not the ceiling — enterprise controllers expect significantly more than minimum compliance
  2. Static subprocessor lists create operational gaps — updates, notifications, and due diligence need to be systematic, not ad hoc
  3. Proactive change notifications are table stakes — controllers shouldn't discover subprocessor changes during their annual review
  4. Data flow transparency matters more than a company name — DPOs need categories, jurisdictions, and transfer mechanisms
  5. A trust center turns subprocessor management into a living system — public, current, auditable, and useful for your customers' own compliance

See How Orbiq Handles This

Orbiq's trust center includes a structured subprocessor page — public by default, with change notifications, data flow detail, and audit-ready documentation. No PDF, no NDA for basic information.

→ View our Trust Center (see our own subprocessor list in action)

→ See Pricing

→ Start Free

Sources

  1. Regulation (EU) 2016/679 (GDPR) – Article 28 (Processor) – Official text of Article 28, including subprocessor authorisation requirements.
  2. EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR – Version 2.1, July 2021. Detailed guidance on controller-processor relationships, including subprocessor engagement.
  3. GDPR Article 30 – Records of processing activities – Requirements for controllers and processors to maintain processing records, including subprocessor details.
  4. CJEU – Schrems II (Case C-311/18) – Ruling on international data transfers, relevant to subprocessor transfer assessments.
  5. EDPB Recommendations 01/2020 on supplementary measures – Guidance on transfer impact assessments and supplementary measures for international subprocessor transfers.

Related Reading