Your vendor uses a vendor. That vendor uses another vendor. By the time you count the cloud provider running their infrastructure, the support tool handling their tickets, and the analytics platform processing their customer data — one SaaS contract can involve 20+ third, fourth, and fifth parties with access to your data.
Fourth-party risk management (FPRM) is how you get visibility into that chain. And under NIS2, DORA, and most 2026 audit frameworks, it’s no longer optional.
This guide explains what fourth-party risk actually is, how it differs from third-party risk, and the practical workflow for assessing sub-processors without drowning in complexity.
What is fourth-party risk?
A third party is a company you directly contract with — your CRM vendor, your cloud provider, your payment processor.
A fourth party is any company your third party contracts with to deliver their service. If you use Salesforce, and Salesforce runs on AWS, AWS is your fourth party. If your support tool uses Twilio for SMS notifications, Twilio is your fourth party.
Fourth parties matter because:
- They may have access to your data (even if indirectly)
- Their failure can cascade into your third party’s outage
- Their security weaknesses expose you via the third party
- Your regulatory obligations extend to them (GDPR processors, DORA sub-contractors, NIS2 critical suppliers)
Fourth-party risk management is the discipline of identifying, assessing, and monitoring these indirect relationships — with documentation that satisfies regulators and audit teams.
Why fourth-party risk is a 2026 priority
1. Concentration risk is now measurable
When 10 of your critical SaaS vendors all run on AWS us-east-1, a single AWS outage can knock out your entire operations. You can’t see that concentration without fourth-party visibility.
2. Regulation caught up
- DORA Article 28 requires financial entities to assess and monitor ICT sub-contractors for critical services
- NIS2 extends supply chain security obligations to sub-processors of critical suppliers
- GDPR Article 28 requires data processor agreements to flow down to sub-processors
- SOC 2 CC9.2 requires assessment of sub-service organizations
3. Sub-processor breaches are common
Major 2024-2025 incidents traced to sub-processor weaknesses: Okta (Lapsus$ via third-party support contractor), Clorox (IT contractor compromise affecting major B2B customers), Change Healthcare (vendor exploited to access downstream customers).
Your third party’s security is only as strong as their weakest sub-processor — and you bear the regulatory and reputational consequences.
Fourth-party vs third-party risk: key differences
| Factor | Third-party | Fourth-party |
|---|---|---|
| Direct contract | Yes — you sign with them | No — your third party signs |
| Audit rights | Usually enforceable | Only via third-party contract flow-down |
| Visibility source | Direct questionnaires, audits | Third-party disclosure, SOC 2 CUECs, public info |
| Assessment depth | Full assessment | Risk-based (critical sub-processors only) |
| Monitoring | Direct | Inherited via third party |
| Action on findings | Direct remediation | Via third-party leverage |
The fourth-party assessment workflow (5 steps)
Step 1: Identify critical sub-processors
Start with your critical third parties (tier-1 vendors). For each, request their sub-processor list. Most mature SaaS vendors publish this openly — it’s a DPA (Data Processing Agreement) requirement under GDPR.
Prioritize sub-processors that:
- Handle or can access your data
- Provide infrastructure the third party depends on
- Deliver a critical function to the third party’s service
- Operate in non-EU jurisdictions (data transfer implications)
You don’t need to assess every fourth party — only the critical ones.
Step 2: Inherit security evidence where possible
Most critical fourth parties are major cloud and SaaS providers (AWS, GCP, Azure, Auth0, Twilio, Stripe). They publish their own certifications:
- AWS: SOC 2, ISO 27001, PCI DSS, FedRAMP, many more
- Salesforce: SOC 2, ISO 27001, ISO 27018, HIPAA
- Stripe: PCI DSS Level 1, SOC 2 Type II, ISO 27001
Collect these for each critical fourth party. This becomes your primary evidence base — you won’t be sending them questionnaires directly.
Step 3: Review CUECs in third-party SOC 2 reports
If your third party provides a SOC 2 Type II, read the “Complementary User Entity Controls” (CUECs) section. This lists controls the third party relies on from their sub-processors.
Cross-check CUECs against the sub-processor’s published certifications. Gaps here are where you push back on the third party — “Your report states you rely on X from your sub-processor, but their SOC 2 doesn’t cover that. How is it actually addressed?”
Step 4: Assess concentration risk across your portfolio
This is the fourth-party question that matters most at portfolio level. Map your tier-1 vendors to their critical sub-processors:
- How many of your vendors share AWS us-east-1?
- How many rely on Cloudflare for edge?
- How many use Stripe for payments?
- Which single fourth-party outage would cause the most damage?
This isn’t a vendor-by-vendor assessment — it’s a systemic view across your vendor portfolio. DORA Article 29 specifically requires financial entities to track this concentration.
Step 5: Document and monitor
For each critical fourth party:
- Record the sub-processor relationship (which of your third parties uses them)
- Record evidence reviewed (certifications, audit reports)
- Document residual risk acceptance
- Set monitoring triggers (new incidents, certification expiry, concentration changes)
Re-review when third parties change sub-processors (they must notify you under GDPR) or when public incidents affect a tracked fourth party.
Common fourth-party risk management pitfalls
Assessing every sub-processor at the same depth. You’ll drown. Focus on critical sub-processors of tier-1 vendors only. Low-risk third parties’ sub-processors can be tracked without active assessment.
Ignoring concentration risk. The biggest fourth-party exposure is usually portfolio-level concentration, not any single sub-processor’s security posture. AWS isn’t insecure — but 50% of your critical vendors being in AWS us-east-1 is a concentration risk.
No contract flow-down. Your third-party contracts must require third parties to flow obligations down to sub-processors. Without this, you can’t enforce security requirements on fourth parties.
Outdated sub-processor lists. Third parties add and remove sub-processors. Your records need to stay current — most vendors notify via email or DPA portal updates.
Treating cloud providers as “too big to fail.” AWS, Azure, GCP are extremely reliable — but still have outages. Their sub-processor risk is different from smaller vendors, not lower.
Fourth-party risk in DORA, NIS2, and GDPR
DORA Article 28: Financial entities must “identify and assess a third party’s concentration risk and determine whether the third party further sub-contracts a critical or important function to other ICT third-party service providers.” Explicit fourth-party obligation.
NIS2 Annex I Measure 4 (supply chain security): Requires assessing the security posture of direct suppliers with regard to their own suppliers — i.e., fourth parties.
GDPR Article 28.2: Processors (your third parties) may not engage sub-processors (your fourth parties) without prior specific or general written authorization from the controller (you). Changes must be notified, and objection rights exist.
SOC 2 CC9.2: Requires organizations to assess and monitor sub-service organizations’ controls that affect the entity.
Each regulation treats fourth parties slightly differently, but they converge on the same practical requirement: know who your sub-processors are, assess the critical ones, and document the chain.
How to operationalize FPRM at scale
For teams with 50+ third parties, fourth-party assessment manually is not sustainable. The automation pattern:
- Ingest sub-processor lists — automated scraping of published DPAs or API pulls from trust center platforms
- Map dependencies — which third parties use which sub-processors; update when they change
- Automate certification collection — inherit SOC 2, ISO 27001 from major cloud/SaaS sub-processors automatically
- Surface concentration signals — portfolio-level views of fourth-party exposure
- Trigger alerts — breach disclosures, expired certifications, new sub-processors added
Modern TPRM platforms handle this layer — it’s the Level 4→5 capability in the TPRM maturity framework that separates programs running assessments from programs running continuous portfolio risk oversight.
FAQ
What is a fourth party in vendor risk management?
A fourth party is any company your direct vendor (third party) contracts with to deliver their service. If you use a SaaS tool that runs on AWS, AWS is your fourth party. You don’t have a direct contract with them, but they handle or affect your data through the third-party relationship.
How is fourth-party risk different from third-party risk?
Third-party risk is direct — you have the contract, the audit rights, and control over remediation. Fourth-party risk is indirect — you rely on your third party’s oversight and contractual flow-down. Assessment methods, evidence sources, and remediation leverage all differ.
Do I need to assess every sub-processor?
No. Focus on critical sub-processors of your tier-1 vendors — those handling data, providing infrastructure, or delivering critical functions. Low-risk third parties’ sub-processors can be tracked without full assessment.
How do I get my third party’s sub-processor list?
Most SaaS vendors publish their DPA and sub-processor list openly. Check the vendor’s trust center or data privacy page. If not published, request it directly — under GDPR Article 28, processors must disclose sub-processors.
What’s the most important fourth-party risk to track?
Concentration risk — the degree to which many of your third parties depend on the same fourth party. A single AWS outage affecting 40% of your critical vendors is usually a bigger exposure than any one sub-processor’s security posture.
Does DORA require fourth-party risk assessment?
Yes. DORA Article 28 explicitly requires financial entities to identify sub-contractors of ICT third parties delivering critical functions and assess concentration risk across the chain. Non-compliance carries significant fines and supervisory consequences.
Getting started with fourth-party risk management
Start small. Pick your top 10 most critical third parties, request their sub-processor lists, and map the chain. This alone usually reveals 20-40 fourth-party relationships your team didn’t know existed.
Then prioritize by criticality. The AWS, Azure, Stripe, Salesforce-tier sub-processors need documentation but rarely deep assessment. The smaller, less-certified sub-processors are where you focus real diligence.
See how CheckFirst automates sub-processor tracking and concentration analysis, or review our vendor security assessment guide for the upstream third-party process.
Related reading
- TPRM Maturity Model: 5-Level Framework — fourth-party oversight is a Level 4+ capability
- Vendor Security Assessment Guide — upstream third-party process that should precede fourth-party work
- CSA CCM for TPRM — normalize sub-processor evidence across frameworks
- NIS2 Article 21 Compliance Checklist — supply chain security obligations extend to fourth parties
- DORA Supplier Assessment — DORA Article 28 explicit fourth-party requirements