Fourth-Party Risk Blindness

Fourth-party risk , the risk introduced by your vendors' vendors , is one of the most consistently underassessed dimensions of supply chain security. The enterprise that assesses its critical ERP vendor thoroughly, confirms the vendor's security controls, and reviews their SOC 2 has completed a thorough third-party assessment. It has assessed the relationship it has direct visibility into. It has typically not assessed the infrastructure provider that hosts the ERP, the identity platform that authenticates all ERP users, the AI analytics vendor embedded in the ERP, or the backup storage provider that holds the ERP's data. These are the ERP vendor's third parties , the enterprise's fourth parties. A breach at any of them can expose the enterprise's data and disrupt the enterprise's operations through the ERP vendor, regardless of how well the ERP vendor's own controls have been assessed.

The subprocessor visibility problem is the technical manifestation of fourth-party risk. GDPR and similar regulations require processors to identify their subprocessors and obtain controller permission before engaging subprocessors to handle controller data. The contractual subprocessor list is the legal mechanism for fourth-party identification , but it is only as complete as the vendor's disclosure. Subprocessors added without notification, infrastructure providers not included in the formal list, and AI capabilities embedded as features rather than disclosed as subprocessors all create fourth-party exposure that the formal list does not reveal.

The critical dependency concentration problem is the specific supply chain risk. Many enterprise SaaS vendors share a small number of underlying infrastructure providers , AWS, Azure, GCP, and a handful of identity platforms. An organisation that has dozens of SaaS vendors hosted on AWS has AWS as a fourth-party to all of them. A failure at AWS affects all of those vendors simultaneously. This concentration is often invisible in third-party assessments because each SaaS vendor is assessed independently without mapping the shared infrastructure dependencies that connect them.

Why this matters

Fourth-party risk matters because the attack surface of the enterprise extends through its vendors' supply chains, not just through the vendors themselves. The SolarWinds attack was a fourth-party risk materialisation , the enterprise's software supply chain was compromised through a vendor's build pipeline, not through a direct attack on the enterprise's own systems. The enterprise that had assessed SolarWinds thoroughly and confirmed their security controls had not assessed the build pipeline that was the actual attack vector.

The DORA fourth-party obligation makes this a regulatory requirement for financial institutions. DORA's ICT third-party risk management requirements explicitly address concentration risk from shared ICT providers and require financial institutions to understand and manage the risks created by their critical ICT vendors' own providers. Fourth-party risk assessment is not optional for DORA-regulated entities , it is a stated programme requirement.

Where most teams get this wrong

The most consistent failure is treating third-party assessment as the complete supply chain risk assessment , without recognising that the vendor's technology stack, infrastructure, and subprocessors create an extended supply chain that the enterprise's direct assessment does not reach.

• Third-party assessment accepted as complete supply chain assessment
• Subprocessor list not requested or not reviewed for material dependencies
• Infrastructure provider (AWS, Azure) not identified as fourth-party to multiple vendors
• AI add-ons and embedded features not identified as separate subprocessors
• Fourth-party concentration across multiple vendors not mapped

What good looks like

Mature fourth-party risk programmes require critical-tier vendors to disclose their subprocessors and material technology dependencies, map fourth-party concentration across the vendor portfolio to identify shared infrastructure providers, and conduct risk-proportionate assessment of the most critical fourth-party relationships.

• Subprocessor list requirement for all critical-tier vendors
• Material technology dependency disclosure , infrastructure, authentication, AI
• Fourth-party concentration mapping , which fourth parties appear across multiple vendors
• Risk-proportionate fourth-party assessment for critical dependencies
• Subprocessor change notification , vendors must notify before adding material subprocessors

Tooling

Fourth-Party Discovery , SecurityScorecard, BitSight for supply chain risk mapping; Prevalent for subprocessor tracking

Supply chain risk platforms can map the technology dependencies of assessed vendors , identifying shared infrastructure providers and building a fourth-party concentration picture that individual vendor assessments do not produce. For critical-tier vendors, requesting a technology stack disclosure during assessment provides the starting data for fourth-party mapping.

Governance challenges

The governance challenge with fourth-party risk is the visibility limitation. The enterprise cannot directly assess its vendors' vendors , it depends on vendor disclosure and indirect evidence. The governance resolution is contractual requirements that obligate critical-tier vendors to maintain their own third-party risk programmes, disclose material subprocessors, and notify the enterprise of material changes in their technology stack.

• Require subprocessor disclosure in critical-tier vendor contracts
• Require subprocessor change notification , prior notice of material new subprocessors
• Map fourth-party concentration across the vendor portfolio annually
• Assess highest-concentration fourth parties , AWS, Stripe, Okta as shared dependencies
• Include fourth-party programme requirements in critical-tier vendor contracts

If you are a small team

For your five highest-risk vendors, ask one question: who are your material subprocessors , specifically your infrastructure provider, your authentication provider, and any third-party AI or analytics capabilities embedded in your product? Map the answers. If three or more of your critical vendors share the same infrastructure provider, that provider is a material fourth-party concentration risk. Start your fourth-party programme by managing that concentration.

• Ask top five vendors for material subprocessor disclosure
• Map shared infrastructure providers across the portfolio
• Identify fourth-party concentration , same provider appearing across multiple vendors
• Require subprocessor change notification for critical vendors contractually

What to require

Ask directly:

"Can you provide your complete subprocessor list including your infrastructure provider, authentication provider, and any third-party AI or analytics capabilities embedded in your product , and do you commit to notifying us before adding material new subprocessors?"

Expect as evidence

• Complete subprocessor list with function for each
• Infrastructure and authentication provider identification
• Subprocessor change notification commitment
• Vendor's own third-party risk programme confirmation

A vendor who confirms comprehensive security should be asked for their complete subprocessor list. Their security is the third-party assessment. Their subprocessors' security is the fourth-party exposure that their assessment doesn't address.

How to evidence it

• Subprocessor disclosure records
• Fourth-party concentration mapping
• Subprocessor change notification records
• Critical fourth-party risk assessment

Key Takeaway

ERP vendor: thoroughly assessed. AWS: hosting the ERP, not assessed. Auth provider: authenticating all ERP admin access, not assessed. AI vendor: processing transaction data for forecasts, not assessed. The enterprise assessed the relationship it had direct visibility into. The four vendors whose infrastructure and capabilities the ERP ran on were the supply chain the assessment didn't reach. Fourth-party risk is the extension of the attack surface through the vendor's own supply chain. Subprocessor disclosure reveals it. Fourth-party concentration mapping manages it. Contractual notification requirements maintain visibility as the vendor's own supply chain changes.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security