What is fourth-party risk? Downstream risk in your vendor chain

Fourth-party risk is the downstream risk that reaches you through your vendors' own providers: the cloud platforms, data centers, payment processors, email services and subcontractors they rely on to deliver your service. You have no contract with these companies, yet their outage, breach or exit can disrupt your critical services as surely as a failure at the vendor itself.

This post explains where fourth parties become visible, why you need two directions of evidence to see them properly, and why reconciling them into one record per provider is what makes concentration and blast-radius analysis possible.

What is fourth-party risk, and why call it downstream risk?

A third party is a company you contract with. A fourth party is a company your third party relies on to serve you. Beyond that sit the nth parties: your vendors' vendors' providers, and so on down the chain.

We call it downstream risk because dependency runs down the chain from you to your vendor to its providers, and impact flows back up. When a hosting provider fails, the vendor's service fails, and your business process stops. You did not choose that provider, you cannot audit it directly, and you may not know it exists.

Downstream risk matters most in two situations: when a vendor supporting a critical activity depends on one provider for something essential, such as hosting or payments, and when many of your vendors share the same provider, which turns one outage into several incidents at once.

Where do fourth parties show up in the evidence you review?

Most programs already hold plenty of fourth-party information, scattered across documents collected for other reasons.

• SOC reports. The system description names the subservice organizations the service organization relies on. Under the carve-out method, the subservice organization's controls are excluded from the auditor's testing, so the report tells you the provider exists but says nothing about how well it is run. Carved-out providers are exactly the ones worth recording.
• Subprocessor lists. Under GDPR Article 28, a processor may not engage another processor without the controller's prior written authorization, so many vendors that handle personal data publish or share a subprocessor list.
• Subcontractor disclosures. Questionnaires and due diligence responses often ask which subcontractors support the service, where they are located and what data they can reach.
• Contracts and DPAs. Subcontracting clauses, notification duties and approved-subcontractor schedules record who the vendor has told you it uses, and what it must tell you before that changes.

This evidence is authoritative because the vendor or its auditor put it in writing. But it is periodic, often self-declared, and scoped. A subprocessor list covers personal data, not resilience. A SOC report covers the services in its scope. Both can go months without an update.

What can outside-in monitoring reveal about a vendor's providers?

The second direction is continuous and independent of what the vendor declares. Every company that runs on the internet leaves public traces of the services it uses.

• MX records show which provider handles the vendor's email.
• SPF records list the services allowed to send email on the vendor's behalf, which often reveals marketing, ticketing and CRM platforms.
• NS records show who hosts the vendor's DNS.
• CNAME records point subdomains at content delivery networks, SaaS platforms and hosting services.
• Domain-verification TXT records are left behind when a company proves domain ownership to a SaaS provider, which can show productivity, identity and security tools.
• Web technology fingerprinting identifies the platforms, scripts and services behind the vendor's websites.
• IP address ownership shows which network or cloud provider operates the vendor's internet-facing hosts.

Why reconcile both views into one record per provider?

Each direction covers the other's blind spots. The evidence you review is authoritative but stale and scoped. Outside-in signals are current but inferred, and they cannot see back-office dependencies such as a core processor or an offshore support center. Used together, a provider confirmed in a SOC report and also visible in DNS is a strong dependency; a provider seen only in DNS is a lead to confirm with the vendor.

The step that turns this into useful analysis is reconciliation. If twelve vendors name the same cloud platform, that should be one provider with twelve links, not twelve free-text notes spelled six different ways. Only then can you answer the questions that matter: how many critical services depend on this provider, directly or through a vendor's subservice organization, and who is affected if it fails. That is the basis of concentration and blast-radius analysis.

Keep inferred links labeled until a contract, disclosure or report confirms them.

What do regulators expect about subcontractors?

Regulators in major markets now ask about the chain, not just the counterparty.

• The US Interagency Guidance on Third-Party Relationships (2023) lists reliance on subcontractors as a due diligence factor, including how the third party oversees its subcontractors and whether there is dependency on a single provider for multiple activities.
• DORA Article 29 requires financial entities to weigh the risks of subcontracting ICT services that support critical or important functions, including whether long or complex subcontracting chains affect their ability to monitor those functions.
• APRA CPS 230 requires the service provider management policy to cover the risks of fourth parties that material service providers rely on to deliver a critical operation.
• OSFI Guideline B-10 expects institutions to manage risk arising from subcontracting arrangements undertaken by their third parties.

These expectations are proportionate: the depth of fourth-party work should follow the criticality of the service, not the size of the vendor list.

How VendRisk360 handles downstream risk

VendRisk360 finds fourth parties from both directions. Subservice organizations named in SOC reports and the dependencies vendors disclose come from the evidence it reviews, and outside-in discovery reads each vendor's public DNS records, web technology and IP address ownership as part of continuous monitoring. Each provider is one shared record linked to every vendor that relies on it, which drives concentration and blast-radius analysis. For the full method, see the whitepaper Beyond the Fourth Party.

Frequently asked questions

What is the difference between a third party and a fourth party?

A third party is a company you have a direct contract with. A fourth party is a company that your third party relies on to deliver its service to you, such as its cloud host, payment processor or support subcontractor. You usually have no contract with a fourth party, so you manage its risk through your vendor and through independent monitoring.

What is downstream risk in vendor management?

Downstream risk is risk that flows from your vendors' own providers. A failure at a fourth party, such as a hosting outage or a breach at a shared processor, travels back up the chain and can disrupt your services even though you never chose or contracted with that provider.

Can you find fourth parties without asking the vendor?

Partly. Public DNS records, web technology fingerprinting and IP address ownership reveal many internet-facing providers, such as email, DNS, hosting and content delivery. They cannot see back-office dependencies such as a core processor or an offshore support center, so confirm critical links through SOC reports, subcontractor disclosures and contracts.

What is a carved-out subservice organization?

It is a provider that a SOC report names but excludes from the auditor's testing. The report confirms the provider is used without assessing its controls. If the carved-out provider supports a service you rely on, record it as a fourth party and consider what other evidence you need.