Sub-processor risk management: How to build a program that satisfies GDPR, CCPA, and beyond

The vendor you never signed a contract with can still be the one that exposes your data.

Your data rarely stops at the vendor you contracted with. Your CRM shares it with an email delivery provider. That provider runs on a cloud host. Each of those downstream parties holds customer data you are still legally accountable for, and most of them never appear in a contract you signed. 

GDPR Article 28(2) is explicit about this: That blind spot compounds with scale. Every SaaS tool you adopt arrives with its own stack of sub-processors, and each of those has sub-processors of its own.

The result is a fourth-party exposure that grows quietly in the background while your security team is focused on the vendors it can see. Building a serious vendor risk management program means accounting for that downstream layer, not just the vendors on your first-party list, and it is now a core part of your GDPR compliance obligations.

This guide explains how to identify and inventory sub-processors, tier them by risk, meet GDPR and other regulatory requirements, and build an ongoing monitoring program that scales as your vendor ecosystem grows.

What is a data sub-processor?

A data sub-processor is a third party engaged by a data processor to carry out processing on behalf of the data controller. Where a processor handles data for the controller, a sub-processor handles it for the processor, one layer further down the chain, bound by the same data protection obligations.

The chain is easiest to see with an example. Your company (the controller) uses a CRM vendor (your processor). That CRM vendor uses an email delivery service (a sub-processor) to send campaigns. The email service runs on a cloud hosting provider (another sub-processor). Your customer’s personal data flows through all four, but you only ever signed a contract with the CRM. The other two are the parties your program has to surface.

Sub-processor language came out of GDPR and was popularized by it. That framing is now the operating assumption across most enterprise procurement, extending well beyond product infrastructure to the HR and go-to-market tools that quietly hold employee and customer PII.

CCPA and CPRA do not use the term "sub-processor," but the CPRA amendments (effective July 2023) introduced the "contractor" category, which carries data protection obligations that are much closer to the GDPR's processor model. 

AI tools sit in this picture too: an LLM API that receives customer-supplied data on your behalf is a sub-processor under GDPR, a point this guide returns to in depth later. One useful exclusion holds: open-source libraries and static code that do not themselves process information on your behalf are generally not sub-processors.

The GDPR data mapping guide covers the mechanics of flow documentation. The GDPR compliance checklist is useful for pressure-testing where sub-processors fit in.

Why sub-processor risk matters: Regulatory obligations and real exposure

Sub-processor risk is not one problem. It is four, stacked, and each carries its own consequence.

The first is contractual. Under GDPR, a processor may use sub-processors only if authorized by the controller, can themselves comply with GDPR, implement adequate technical and organizational measures, provide breach notifications, and are bound by a contract detailing the purpose and nature of processing. Miss any of these, and you are in breach of your own controller agreements.

The second is a regulatory penalty. GDPR violations can carry penalties up to €20 million or 4% of global annual turnover under Article 83, depending on the nature of the infringement, with the highest tier applying to violations of core data protection principles. That exposure follows the data down the chain. A sub-processor's failure becomes your regulatory problem.

The commercial impact is often what finally gets leadership’s attention. Enterprise buyers now vet sub-processor lists during procurement, and a gap or a stale disclosure can stall or block a deal outright. 

There is a reputational cost that sits alongside it. The 2022 Morgan Stanley case, where the SEC imposed a $35 million penalty after a vendor engaged to decommission hardware failed to properly dispose of customer data (SEC Release No. 34-95428), is the kind of downstream vendor failure that regulators treat as the controller’s problem, regardless of the contractual distance. That is the headline that turns an abstract compliance requirement into a board-level conversation.

The regulatory surface is widening well beyond GDPR. NIS2 (EU Directive 2022/2555) requires organizations in scope to address supply chain security, including the security relationships between entities and their direct suppliers. Article 21 makes this explicit. The transposition deadline for member states was October 17, 2024, though national implementation timelines have varied.

DORA adds a financial-sector layer. If you sell into banking, insurance, or investment management, the Digital Operational Resilience Act (EU 2022/2554) is a first-order concern. It requires financial entities to manage ICT third-party risk and explicitly addresses sub-outsourcing arrangements, meaning your sub-processors are in scope, not just your direct vendors. 

Two more frameworks differentiate a mature program. Canada’s PIPEDA holds you accountable for personal information transferred to third parties, including the due diligence you did before the transfer, not just the transfer itself. Brazil’s LGPD requires every processing agent to adopt protective security, technical, and administrative measures. Tracking sub-processors across all of these is the foundation of a defensible third-party risk management posture.

The regulation sets the floor. What sits above it is a practitioner judgment call: how much your customer cares is what actually defines “reasonable” for your program. A customer with strict requirements; custom frameworks, AI supply chain conditions, transaction-data restrictions, is effectively telling you what "reasonable" means. Their requirements set your bar.

How to build a sub-processor inventory

Start where the data lives, not where the paperwork lives. The authoritative list of what touches customer data sits with engineering, not legal or compliance. A good place to begin is the production database, the customer DB. 

If your company sells an application hosted on AWS, GCP, or Azure, that is likely a cloud-hosted Postgres service or a managed database like ClickHouse or Supabase, and it is almost certainly your most important sub-processor. Begin there because everything else radiates outward from it.

1. Use data flow as your organizing principle

Once you have the production database anchored, trace the movement: what comes in, what reads from it, what it writes to, and where data exits your environment. As Nicholas Muy, CISO at Scrut Automation, frames it, you look at what’s coming in and what’s going out, then follow it to the external entities on that map: the customer analytics tool reading session data, the SaaS platform connected to your store, the API pulling records. Those reading and writing entities are your sub-processors.

2. Inventory the obvious categories first

Cloud infrastructure (AWS, GCP, Azure) belongs on the list even when it feels too obvious to document. Auditors will ask for it. Customer analytics and session recording tools capture detailed user behavior and belong near the top. Email delivery and marketing automation platforms process contact data at volume. 

AI and LLM APIs receiving customer-provided inputs are formal sub-processors. Payment processors and billing systems touch financial data. HR and payroll platforms holding employee PII, and support and ticketing systems, are worth specific attention even though neither sits in your product’s direct data path.

3. Account for OAuth and shadow IT, or your inventory is incomplete

OAuth-connected applications, including third-party email clients, Slack bots, and productivity add-ons, process data in ways teams routinely fail to track, and they can qualify as sub-processors even when no formal contract governs them. 

Infosec leader Kevin Qiu's advice is to treat OAuth apps like any other third-party app. Many email clients claim all storage is local, but as Kevin Qiu has noted, that claim is worth scrutinizing when the same tool ships AI features that require server-side processing. 

An OAuth allowlist stops people from wiring personal SaaS tools into corporate inboxes full of sensitive data. If your inventory ignores this layer, it is wrong. See our deeper treatment of shadow IT and OAuth risk and how security questionnaires for vendors can surface these connections.

Format for maintenance, not just existence

The inventory should be referenced consistently across your DPAs and privacy notices, publicly available in line with common GDPR practice, and machine-readable where possible. Conflicting or stale lists create liability, not just confusion. Pair the inventory work with structured GDPR data mapping so the two artifacts stay aligned, and lean on your broader vendor risk management process to keep entries current.

How to tier and prioritize sub-processors by risk

An inventory without tiering is just a list. Tiering applies vendor-risk logic one layer deeper, so your effort lands where the exposure actually is.

Lead with the data question. It usually settles the tier. Start with what kind of data the sub-processor will access, collect, store, or transmit, and whether that data is your customers’ directly. From there, run the rest of the triage in order:

• Does the sub-processor touch production customer data directly? This is the single most important signal.

• What PII categories are involved? Special categories under GDPR Article 9 (health, biometric, and similar) trigger heightened treatment.

• Is the vendor cloud-hosted (SaaS) or self-managed? A software license you deploy yourself changes the assessment scope significantly.

• Are there compliance requirements that decide the treatment for you? PCI DSS, HIPAA, and DORA remove the interpretation. If a sub-processor is in your cardholder data environment or handles PHI, it is critical by definition.

• Is the sub-processor shared across several of your Tier 1 vendors? Shared dependencies create concentration risk worth flagging.

That gives you three practical tiers:

Tier 1 — Critical: Sub-processors with direct access to production customer data, special category PII, financial data, or health records. Full DPA, security questionnaire, DPA review for sub-outsourcing provisions, and an annual or biannual review.

Tier 2 — Significant: Sub-processors processing company-sensitive data, including employee records, financial records, and go-to-market data, but not direct customer PII. A DPA plus a simplified annual review is proportionate.

Tier 3 — Low risk: Sub-processors handling publicly available information or internal productivity tools with no sensitive data exposure. Register and monitor. A full assessment is not required.

The longtail is a deliberate decision, not a gap. You do not have unlimited time, and some vendors are doing something entirely innocuous, aggregating public data, for instance. Group the Tier 3 longtail categorically and review it at a higher level rather than assessing each vendor individually. 

The more specificity you can get about how each vendor affects your data flow, customer interactions, and sensitive data handling, the easier the tiering decision becomes. Name this grouping explicitly in your program so it reads as a choice, not an oversight.

Our vendor risk assessment guide and vendor management policy template cover the mechanics in full. 

Operationalizing sub-processor management: Contracts, notifications, and ongoing oversight

Most programs have tiering. Fewer have the mechanics that turn tiering into an actual process: DPA flow-down, change notifications, and audit-ready evidence.

DPA flow-down is the mechanism that auditors check

GDPR Article 28(4) requires that the processor–sub-processor DPA impose the same data protection obligations that the controller–processor DPA imposes on you. 

In practice, that means either using your own approved DPA template for sub-processors or accepting the sub-processor’s standard DPA and closing the gaps with an addendum. Auditors sample this specifically, so the paper trail has to show that the obligations actually flowed down.

Build the change notification workflow before you need it

GDPR requires processors to notify controllers of intended sub-processor changes with enough time to object. “Sufficient time” is not defined in the regulation. Many DPAs set this window at 30 days, though the specific period varies by contract. 

The workflow is straightforward: a sub-processor change triggers advance notice to the controller, the controller has a defined window to object, and you then proceed or substitute. Wire this into your onboarding process so it runs the same way every time.

Know what auditors sample, and prepare that evidence

When auditors sample vendor risk work, they are looking for evidence that a process ran, not just that questionnaires were sent. They want to see who your sub-processors are and documentation of how you choose and assess vendors. 

The better ones go further. They take the assessments you have run, sample a handful, and look at what you asked, what came back, and what you did with it. Were there communications where you pushed back and asked a vendor for clarification? That back-and-forth is the evidence that a real assessment happened rather than a form being filed. Line this up with your SOC 2 audit preparation and keep your vendor risk assessment evidence in a state you can hand over on demand.

Keep a single, versioned source of truth. Maintain one authoritative sub-processor list, your Trust Vault, or public sub-processor page that every DPA and privacy notice references. Version and timestamp it for audit purposes. This is also the backbone of any move toward continuous vendor monitoring. Software bills of material (SBOMs) point at where machine-readable tracking is heading, but for most organizations, that is still aspirational rather than current practice, so it should not lead your program.

The definition of reasonable effort that makes all of this tractable is simpler than it sounds: if you know where your customer data is going, where it is stored, who is accessing it, and how, and you focus your analysis there, you can do a genuinely useful assessment in a reasonable amount of time.

Sub-processor risk and AI tools: What has changed

The old advice of sanitizing PII before pasting it into a chatbot misses the structural shift. When your product sends customer-supplied data to an LLM API, that API provider is a sub-processor under GDPR. That means a DPA with the LLM provider, authorization from your controller, and disclosure in your sub-processor list, no different from any other party in the chain.

Two scenarios sit under this, and they carry different risk.

Internal use

Your employees use an AI assistant for internal tasks that do not involve customer personal data. The regulatory exposure is lower, but the shadow IT risk is higher. People wire these tools in without oversight. Govern this through acceptable use policies and access controls rather than DPAs.

Product-embedded AI

Your SaaS product calls an LLM API with customer data as input. This is a formal sub-processor relationship. It requires a DPA, controller notification, and disclosure on your sub-processor list, exactly like any other party in the chain.

There is a concentration angle worth flagging even without perfect contractual data. Suppose you assess your most critical vendors and discover they all depend on the same model provider, say Anthropic, while your own company policy is to standardize on a different provider. 

Even if you cannot see the exact contractual relationship between your vendor and that provider, the shared dependency is enough to raise in an internal risk assessment: "We found in our vendor risk review that our critical sub-processors all share a dependency on one AI provider." 

From there, leadership can make an informed call. For the governance layer around all of this, see our work on AI governance and compliance, AI risk management, and LLMs and third-party risk.

What “continuous” sub-processor monitoring actually means

In practice, sub-processor monitoring programs fall into three distinct levels. Most programs operate at the first. Naming them clearly tells you both where your program actually sits and what “continuous” is worth promising to a board.

Registry maintenance (the baseline)

This is keeping the sub-processor list accurate: updating it when a vendor changes its own sub-processors and referencing it consistently across DPAs and privacy notices. It is the minimum viable program, and for many organizations, the automation of exactly this, keeping the list current with the least manual lift, is where the real value shows up. 

Most programs that claim to do more are, in practice, doing this well and calling it continuous.

Event-triggered review

Reviewing a specific sub-processor when something material happens: a reported breach, a change in ownership, a new feature that expands data access, or a regulatory action against the sub-processor. This is more mature than registry maintenance because it responds to a signal rather than just maintaining a record.

Periodic reassessment

This is a structured annual or biannual review of Tier 1 sub-processors, with evidence that it occurred, which SOC 2 and ISO 27001 auditors expect.

Now the honest part. Real-time monitoring of sub-processor security posture, the way a SIEM watches internal infrastructure, is not the standard expectation for most organizations. 

As Akilesh Muralidharan, SVP Product at Scrut Automation, has noted, for the majority of organizations, “continuous” really means keeping in check with the frequency of the audits that happen, just done with some level of automation. Setting that expectation explicitly saves you from over-promising to a board.

The litmus test follows from that: if monitoring will not change a decision you make, it is probably not worth the effort. Build the level of continuous compliance monitoring that actually drives action, lean on vendor risk management automation to reduce the manual lift, and read our fuller take on moving from point-in-time to continuous risk management.

When a sub-processor has a breach: Your response workflow

When a sub-processor, or your vendor’s sub-processor, has a breach, two tracks run at once. Getting the sequencing right is the difference between a controlled response and a scramble.

Track 1: Internal investigation

Confirm first whether the breach even affects the systems or data relevant to your engagement. Many vendors sell multiple products, and the breach may not touch the one you use. Establish scope: was it only some customers, only some products, all customers, all products, the vendor’s product, or the vendor's whole operation? Document your investigation and findings regardless of the outcome, because auditors will ask. Then prepare an internal FAQ for your customer-facing and legal teams before any communications go out.

Track 2: Customer communication

GDPR Article 33 requires notification to the relevant supervisory authority within 72 hours where personal data is likely affected. That clock starts when you have reasonable certainty that personal data is affected, not when the sub-processor notifies you. A vague or incomplete vendor disclosure does not reset it.

Customers who see that sub-processor on your list will ask directly whether they are affected. Do not speculate before your investigation establishes the facts. The goal is to be transparent without overreacting before the facts are established. Validate the scope first, then communicate.

The contractual gap most programs discover too late

Many organizations only realize after a breach that their DPA never specified notification timelines. The fix is a clearly defined incident notification threshold in the DPA. Specify what constitutes a notifiable event, because "notify us of everything" is meaningless. If everything is notifiable, nothing is. 

Set a timeline (48 to 72 hours is common in practice, though GDPR Article 33 sets 72 hours for supervisory authority notification), and define the required contents of the notice. Get this into the contract at signing, not after an incident.

The third-party incident response plan, vendor breach prevention guide, and GDPR data breach obligations checklist cover the operational scaffolding. See our third-party incident response plan, our guidance on vendor breach prevention, and the GDPR data breach obligations checklist.

Conclusion

A mature sub-processor risk management program is not complicated, but it does have to be complete. It runs on five moving parts: a tiered inventory that starts with production customer data, DPA flow-down that puts the same obligations on your sub-processors that your controllers put on you, a change notification workflow that gives controllers time to object, periodic reassessment of the sub-processors that matter most, and a breach response protocol that is defined before you need it. Miss any one, and the chain has a weak link.

Keeping your sub-processor list accurate and current, and surfacing it to controllers and auditors on demand, is exactly the kind of operational lift that Scrut’s vendor risk management platform is designed to reduce. If you are earlier in your research, start with our broader vendor risk management guide and build from there.
‍