A fourth party is your vendor's own vendor: the cloud infrastructure a SaaS product runs on, the payment processor it integrates with, the customer-support platform it outsources to. You have no direct relationship with any of them, no contract, and no standing to demand evidence. Your only line of sight is whatever your vendor chooses to disclose - which is precisely what makes fourth-party risk different from ordinary vendor risk. It isn't a harder version of the same problem; it's a visibility problem first and a risk problem second.
The case for taking it seriously is not hypothetical. A single cloud region outage, a compromised CDN, or a breached identity provider can degrade or expose dozens of vendors simultaneously - vendors that looked completely independent on your own risk register. The Shared Assessments fourth-party risk management paper frames this precisely: as outsourcing has grown, the vendors you've assessed increasingly outsource pieces of their own service, and that downstream layer can undermine a program that only ever looked at direct, contracted relationships.
Why you can't just extend your assessment process downward
The instinct is to treat fourth parties like third parties one layer removed - send a questionnaire, request a SOC 2, tier them. That doesn't work, for a structural reason: you have no contract with a fourth party, so you have no right to any of it. Whatever you learn comes secondhand, through your vendor, and your vendor has limited incentive to volunteer a subcontractor's weaknesses. Trying to run full due diligence on every fourth party behind every vendor also doesn't scale - a single mid-size SaaS vendor's dependency graph reaches nested subcontractors quickly, and few programs have the headcount to chase all of it for a low-tier vendor's spell-checker plugin.
The practical answer is not to abandon visibility, but to scope it deliberately: demand fourth-party transparency from the vendors where it matters, and accept a lighter touch everywhere else.
What regulators now expect
This is no longer just good practice - specific guidance now expects programs to look past the first tier.
- OCC Bulletin 2023-17 (the interagency guidance jointly issued with the Federal Reserve and FDIC) explicitly extends third-party risk management expectations to a third party's subcontractors, describing this as "flow-down" due diligence and monitoring: banks are expected to understand how a third party selects and oversees its own subcontractors and to have appropriate oversight of that chain, not just of the direct relationship. See the OCC bulletin.
- DORA (EU Digital Operational Resilience Act) addresses this directly for ICT services supporting critical or important functions: where a third-party provider may further subcontract such a service, in-scope financial entities must weigh the risks and benefits of that subcontracting, understand which subcontractors are involved and what each one delivers, assess whether a subcontractor's failure would affect the critical service, and hold contractual rights to be informed of material subcontractor changes. Those sub-outsourcing arrangements also have to be captured in the entity's Register of Information - DORA does not let a financial entity stop looking at the first tier.
- The EBA Guidelines on Outsourcing Arrangements (EBA/GL/2019/02) formalize the vocabulary and the expectation: they define "sub-outsourcing" - also called chain outsourcing - and require institutions' outsourcing governance to extend to it, including assessing whether a chain of sub-outsourcing impairs the institution's ability to monitor the arrangement or the supervisor's ability to oversee it. See the EBA guidelines.
- NIST SP 800-161 Revision 1 frames cyber supply chain risk management as a program that has to reach beyond direct suppliers to the broader network of entities that touch a system or service - the C-SCRM discipline exists specifically because supply chains are multi-tiered, not two-party.
A scoped approach to fourth-party visibility
Given the constraints above, the workable model is to tie fourth-party diligence to the same tiering you already use for direct vendors, rather than applying one standard to every relationship.
| Vendor tier | Fourth-party expectation |
|---|---|
| Critical - high data access or operational dependency | Require disclosure of material subprocessors and infrastructure dependencies at onboarding; contract for notification before a material subcontractor changes; ask the vendor directly how it oversees its own subcontractors' controls. |
| Significant - moderate access, standard SaaS | Request a subprocessor list (most SaaS vendors already publish one for GDPR purposes) and note shared infrastructure providers as monitoring context, without full flow-down diligence. |
| Low - minimal access or exposure | No dedicated fourth-party review; rely on the vendor's own attestations and revisit only if the vendor is upgraded to a higher tier. |
Three contractual and process levers do most of the practical work:
- Subprocessor disclosure clauses. Many SaaS agreements already require vendors to maintain a public or on-request subprocessor list - use it, and check it periodically rather than once at signing.
- Notification rights on material change. A contract clause requiring advance notice before a vendor adds or swaps a subcontractor for a critical function turns an invisible change into a scheduled review.
- Shared-infrastructure awareness. When several of your vendors disclose the same cloud region, identity provider, or payment rail, that's not fourth-party risk in isolation anymore - it's concentration risk, and it belongs on that register instead of being tracked vendor by vendor.
Where programs get this wrong
- Assuming a SOC 2 report covers the subprocessor layer. A vendor's SOC 2 opines on the vendor's own controls. It does not audit the vendor's subcontractors, and a "complementary user entity controls" section is not the same as a fourth-party risk assessment.
- Treating it as unmanageable and skipping it entirely. The absence of a contract with the fourth party is real, but it doesn't make the risk disappear - it just means the lever is your contract with the third party, not a direct one.
- Conflating fourth-party risk with concentration risk. They overlap but aren't the same question. Fourth-party risk asks "what does this specific vendor depend on." Concentration risk asks "how many of my vendors depend on the same thing." A shared-cloud finding should get logged as both.
- No contractual right to find out when it changes. Without a notification clause, a vendor can swap a critical subcontractor with no obligation to tell you, and your last known picture of the dependency chain quietly goes stale.
Making fourth-party visibility a running process, not a one-time question
Fourth-party disclosures age the same way questionnaire answers do - a subprocessor list checked once at onboarding tells you nothing about what changed eighteen months later. The programs that keep this current pair the contractual levers above with continuous monitoring of the infrastructure and services a vendor is observed to depend on, so a change shows up as a signal rather than requiring someone to re-ask. Rescana builds this into its monitoring, alongside platforms that take a similar evidence-plus-signal approach; whichever platform runs a program, the discipline that matters is scoping fourth-party effort to vendor tier and revisiting it on a schedule; not treating it as a box checked once at onboarding.
Frequently asked questions
How do you manage fourth-party risk in a third-party risk management program?
Manage fourth-party risk by scoping effort to vendor tier rather than trying to assess every subcontractor behind every vendor. For critical vendors, require disclosure of material subprocessors and infrastructure dependencies at onboarding, add a contractual right to be notified before a material subcontractor change, and ask the vendor how it oversees its own subcontractors' controls. For lower tiers, a subprocessor list and periodic review is usually sufficient. Because you have no direct contract with a fourth party, the practical levers are always contractual terms with your direct vendor plus ongoing monitoring for change, not independent audits of the fourth party itself.
How can you get visibility into your vendors' subcontractors?
Visibility into subcontractors comes from your contract with the direct vendor, not from any relationship with the subcontractor itself. Require the vendor to maintain and share a current subprocessor or subcontractor list, add a notification clause requiring advance notice before a material subcontractor changes for a critical function, and ask directly during due diligence how the vendor selects and oversees its own subcontractors. Regulatory guidance - including OCC Bulletin 2023-17's 'flow-down' due diligence expectation and DORA's sub-outsourcing provisions for critical or important functions - treats this as a standing oversight obligation, not a one-time onboarding question.
Does DORA require assessing fourth-party or sub-outsourcing risk?
Yes, for ICT services supporting critical or important functions. Where a financial entity's third-party ICT provider may further subcontract such a service, DORA requires the financial entity to weigh the risks and benefits of that subcontracting, understand which subcontractors are involved and what each delivers, assess whether a subcontractor's failure would affect the critical service, and hold contractual rights to be informed of material subcontractor changes. Those sub-outsourcing arrangements must also be captured in the entity's Register of Information under DORA's reporting framework, so the sub-outsourcing chain cannot be left out of scope for in-scope financial entities.
What is the difference between fourth-party risk and concentration risk?
Fourth-party risk is about a specific vendor's dependency - what subcontractor or infrastructure provider a given vendor relies on, and what happens if that dependency fails or is compromised. Concentration risk is a portfolio-level question - how many of your vendors, independently, depend on the same underlying provider, such as one cloud region or one identity provider. A single fourth-party finding can also be a concentration-risk finding if the same dependency shows up across multiple vendors; the two should be tracked together rather than treated as separate registers, since a fourth party shared by many vendors is exactly the concentration scenario regulators like DORA require entities to assess.