# Subprocessor management under GDPR

Source: https://contracko.com/blog/subprocessor-management-under-gdpr

[Blog](https://contracko.com/blog)

[Subprocessor management under GDPR](https://contracko.com/blog/subprocessor-management-under-gdpr)

# Subprocessor management under GDPR

Budi Voogt May 22, 2026

Copy for LLM

You vetted your vendor, signed the DPA, and moved on to the next fire. I've done exactly that more times than I'd like to admit. The trouble is that your vendor relies on its own vendors (hosting, email delivery, analytics, support tooling), and under GDPR, those sub-processors are part of your compliance picture too. In my experience, sub-processor management is where a lot of otherwise tidy privacy programmes quietly fall down.

> This is practical guidance, not legal advice.

By the end of this guide, you will:

- Understand what a sub-processor is and why GDPR Article 28 makes them your concern.
- Know how the notice-and-objection model works, and where the deadline hides.
- Have a repeatable set of habits for keeping each vendor's sub-processor list current.
- See how to build an audit trail that holds up when a customer or regulator asks.

## What a sub-processor actually is

A sub-processor is a third party your processor engages to help process personal data on your behalf. If your CRM vendor hosts on a cloud provider and uses a separate email-delivery service, both of those are sub-processors of your data. You may never have signed anything with them, you may never have heard their names, and yet your customers' personal data flows through their systems.

GDPR Article 28 sets the terms. Your processor has to get your authorisation before engaging a sub-processor, flow down equivalent data-protection terms to that party, and remain liable to you for what they do. That last point is worth sitting with. The chain of accountability runs back to you as the controller, so a weak link three vendors down the line is still your problem when something goes wrong. This is the same logic that drives so much of [vendor contract management](https://contracko.com/usecases/vendor-contract-management): the relationship doesn't end at the signature, it extends through everyone your counterparty leans on.

## The notice-and-objection model

Most DPAs handle authorisation with what's called a general authorisation. Rather than asking your permission for each new sub-processor individually (which would be unworkable at scale), the processor maintains a sub-processor list and commits to notifying you of additions or replacements. You then get a window, often 14 to 30 days, to object before the change takes effect.

That window is the whole game. If you don't track it, you don't get to use it, and you're deemed to have accepted a new party handling your data. The obligation is real, but the mechanism is easy to miss, because the notice rarely arrives with any ceremony. You'll recognise this: it lands as a routine email, a footer line in a product update, or a changelog entry on a status page nobody on your team is watching. By the time anyone notices, the window has closed and the new sub-processor is already live.

What can you actually do inside that window? In practice, a few things:

- Accept the change, and record that you reviewed and accepted it.
- Object on reasonable grounds, which usually opens a conversation with the vendor about alternatives.
- Escalate internally if the new sub-processor sits in a jurisdiction or handles a data category that triggers your own review thresholds.

The point isn't that you'll object often. Most of the time you won't. The point is that you keep the right to object, and you can show you considered each change rather than sleepwalking through it.

## Keeping the list current

Practical sub-processor management comes down to three habits.

First, know who's on the list today for each vendor, and store it somewhere you can actually find it. A snapshot you saved during procurement two years ago is not the current list. I've found it helps to treat each vendor's sub-processor roster as a living record attached to the DPA itself, not a one-time attachment that ages out of date in a shared drive. A central [contract repository](https://contracko.com/features/contract-repository) is the natural home for this, because the list lives next to the agreement that governs it.

Second, catch the change notices, and treat each one as a decision with a deadline rather than an FYI. This is the habit that breaks down most often, because the notices are designed to be low-friction for the vendor, not high-visibility for you.

Third, keep an audit trail. What was the list, when did it change, were you notified in time, and did you object? When a customer security questionnaire or a regulator request arrives, that trail is your evidence. Without it, you're reconstructing history from memory and inbox archaeology, and I promise that's a bad afternoon.

Here's a simple way to think about what each habit produces:

| Habit | What you keep | Why it matters |
| --- | --- | --- |
| Know the current list | A dated roster per vendor | Answers "who touches our data right now?" |
| Catch the notices | A logged decision per change | Preserves your right to object |
| Keep the trail | A timeline of changes and responses | Evidence for customers and regulators |

The hardest of the three is the audit trail, because sub-processor changes arrive piecemeal over months across many vendors. One notice in March, two in July, a quiet replacement in October. Holding each DPA, its current sub-processor list, and the change-notice window in one place, tied to the vendor, is what makes this tractable instead of overwhelming. That's a large part of what [data processing agreement management](https://contracko.com/solutions/data-processing-agreement-management) is built to do, and it sits inside our broader [GDPR compliance software](https://contracko.com/solutions/gdpr-compliance-software) for teams that need the full picture rather than a single document.

## Where extraction earns its keep

There's a step I skipped over above that's worth its own moment. When you sign a new DPA, the sub-processor terms (the notice period, the objection window, where the list lives, how changes get communicated) are buried in dense clauses you read once and never reopen. Pulling those details out by hand, for every agreement, is the kind of work that gets deprioritised the moment something more urgent appears.

This is where [AI contract analysis](https://contracko.com/features/ai-contract-analysis) changes the economics. Instead of a person reading paragraph 9.3 of every DPA to find the objection window, [contract data extraction](https://contracko.com/features/contract-data-extraction) reads it for you and surfaces the dates and obligations as structured fields you can monitor. For compliance teams especially, that shift from manual reading to extracted, trackable data is what makes a sub-processor programme survive contact with a busy quarter. If this is your remit, the [compliance officer use case](https://contracko.com/usecases/compliance-officer) walks through how it fits a day-to-day workflow.

A quick word on trust, because it comes up every time data and AI appear in the same sentence. Contracko is EU-hosted, your contracts are encrypted, access is role-based, and we don't train AI on your contracts. The tooling that reads your DPAs isn't quietly feeding them into a model somewhere. You can read more about that on our [security page](https://contracko.com/features/security).

## Don't miss the objection window

The single most missable item in all of this is the objection deadline. Everything else (the lists, the trail, the analysis) supports the one moment where inaction costs you a right you can't get back. You can't object to a change you didn't notice, and the calendar won't remind you on its own.

A [DPA reminder tool](https://contracko.com/contract-reminder-tools/data-processing-agreement-reminder) takes the sub-processor change windows out of an agreement (alongside review dates and audit rights) and turns them into reminders, so a new sub-processor never slips past you while the window to object is still open. It's the difference between managing your sub-processors and discovering them after the fact. If you want to see how this thinking extends across the rest of contract risk, our piece on the [common risks in contract management](https://contracko.com/blog/risks-in-contract-management) covers the wider pattern.

## Next steps

If your sub-processor lists currently live in a mix of inboxes, screenshots, and good intentions, start small. Pick your three highest-risk vendors, find their current sub-processor lists, and note the objection window for each. That alone will tell you whether you've been catching the notices or quietly accepting changes you never saw.

When you're ready to make it systematic rather than heroic, that's what we built Contracko for. I'd genuinely like to hear how you're handling sub-processor notices today, because no two programmes do it quite the same way. Do reach out if you have questions, I read and answer every message myself.

## Get started with Contracko

Take the hassle out of contract and subscription management. Contracko empowers you to stay organized, on time, and in control. Start simplifying today.

[Start 7-day free trial](https://app.contracko.com/register)

Book demo