Fourth-Party Risk: The Vendors Your Vendors Don’t List

Fourth-party risk is the exposure your organization carries from the companies your vendors rely on: the sub-processors behind your processors, the infrastructure under your SaaS tools, and the code your approved tags load onto your pages. You have no contract with any of them, yet their failures arrive as yours.

Regulators no longer accept “our vendor’s vendor” as an excuse. In June 2025, Germany’s data protection authority fined Vodafone €15 million not for a breach but for failing to vet and monitor the partner agencies handling its customer data, a GDPR Article 28 failure. 

In October 2025, New York’s DFS told regulated firms to require disclosure of their vendors’ subcontractors and keep the right to reject them after due diligence. Then, in November 2025, the EU took things further: 19 technology providers, including AWS, Microsoft, Google Cloud, Oracle, and SAP, came under direct regulatory oversight as critical third parties under DORA, with penalties up to 1% of average daily worldwide turnover. The fourth-party layer is now on regulators’ radar.

If you’re a DPO, privacy counsel, or lead for GRC or vendor risk, this page helps you answer the real questions examiners ask: How far should your diligence go, and what can you do about fourth parties you can’t reach by contract?

What is fourth-party risk?

Fourth-party risk is the risk that a vendor’s vendor causes you harm: a data breach, an outage, a regulatory finding, or a reputational hit that lands on your organization even though you never signed a contract with the company that failed.

For example, if your processor’s hosting provider leaks your customer data, you’re the one the regulator contacts.

Each level in the chain is defined by its relationship to you, not by its size or industry:

The Financial Stability Board’s December 2023 toolkit defines an nth-party service provider as one “that is part of a third-party service provider’s supply chain and supports the ultimate delivery of services”; fourth parties are the most common case.

There are two types of fourth parties, and this difference shapes everything else discussed here:

• Contract-chain fourth parties. Your vendor engages them under a contract, so paperwork can usually reach them. This includes sub-processor lists, flow-down clauses, and audit reports. 
• Browser-chain fourth parties. Your own website loads them. You approved one vendor’s tag; that tag can load code or send data to other parties who aren’t listed anywhere, since no contract controls what a script does at runtime. No paperwork reaches this class. Only observation can.

Software dependency chains (the open-source libraries inside your vendor’s product) are a parallel nth-party surface, managed with different instruments and outside this article’s scope. What is in scope for every fourth and nth party is where diligence stops, and the stopping rule below answers it in a form you can hand to an examiner.

For a working definition of the third party one level up, and the program that governs it, see our third-party privacy risk management guide.

How is fourth-party risk different from third-party risk?

The main difference is simple: third-party risk is managed by a contract or agreement you have, while fourth-party risk is managed by an agreement you do not hold. Everything else stems from this point.

The last row is why existing third-party programs do not absorb fourth parties by default. Your third-party risk management (TPRM) workflow is built around a counterparty: send the questionnaire, review the SOC 2, sign the DPA. A fourth party has no slot in that workflow. Nobody in procurement knows it exists until your vendor mentions it, or doesn’t. What it needs instead is a different discipline, built on flow-down rights, disclosure instruments, and, for the browser chain, direct observation.

Why is fourth-party risk a problem now?

The chain has grown longer, failures have become bigger, and regulators have started addressing these risks in their rules. According to a UK government survey, only 13% of organizations review their immediate suppliers’ security. When a fourth party fails, it can cause five types of damage, often more than one at a time:

• Operational. A fourth party goes offline, and your service goes with it, even though your own systems and your direct vendor are both healthy.
• Financial. Response costs, lost revenue, contractual penalties, and litigation over whose failure it was, including between you and your vendor.
• Legal, regulatory, and compliance. Regulators hold you accountable for personal data your vendors’ vendors mishandle.
• Reputational. Your customers experienced your outage and your breach notice. The fourth party’s name appears nowhere in the headline.
• Strategic. If many vendors rely on the same fourth party, one cloud region, or one network provider under several vendors, it creates correlated failure you cannot diversify away at the vendor level.

The incident file shows each type with receipts:

Rick Pollack, president and CEO of the American Hospital Association, called the Change Healthcare attack 

“the most significant and consequential incident of its kind against the U.S. health care system in history”

(March 5, 2024). 

The hospitals that could not fill prescriptions that month had done nothing wrong. Their vendors’ vendor had.

Does the law require you to manage fourth parties?

Yes, in most regulated contexts, though almost never under the name “fourth-party risk management.” The law’s approach is consistent: accountability does not stop at your direct vendor. Your vendor must control its subcontractors, you must control your vendor’s oversight, and several regimes give you specific instruments. The floor, regime by regime:

No regime demands that you personally chase every vendor’s vendor to the bottom of the chain. Read the guidance’s structure, not its slogans (our interpretation of the mechanics, not a quotation): the recurring pattern is assess your vendor’s oversight of its subcontractors. Your duty is to select, contract, and monitor the third party well enough that its fourth parties are governed, and to document that you did.

Geography is not a defense

The interagency guidance applies its expectations regardless of where subcontractors are based, and DORA’s assessment explicitly includes third-country providers. A fourth party in another jurisdiction is still your fourth party.

The UK’s National Cyber Security Center put the security side of the same point in October 2022: 

“Supply chain attacks are a major cyber threat facing organizations and incidents can have a profound, long-lasting impact on businesses and customers.” 

The privacy side is identical: the harm lands downstream, the accountability flows back up.

How do you find out who your fourth parties are?

To do fourth-party due diligence, use four tools in order and note what each one can’t show you. No single tool gives you a full fourth-party inventory. Instead, you combine four partial views, each with a known ceiling.

1. The sub-processor list 

Your processor’s disclosure of its subprocessors, usually a web page or an annex, updated on the vendor’s schedule. Contract for change notice if you don’t already have it: GDPR Article 28(2) general authorization requires the processor to inform you of intended additions or replacements so you can object, so the list plus a notice duty is the minimum viable instrument.

2. The SOC 2 report’s subservice-organizations section

The auditor names the subservice organizations and whether they are carved out or included, and that decides what the report proves: carve-out means their controls were excluded and you inherit complementary subservice organization controls (CSOCs) your vendor was assumed to operate; inclusive means they were examined. 

Read the complementary user entity controls (CUECs) too, what the auditor assumed you would do; they often include reviewing these very disclosures. Mind the window: Type 1 covers design on one date, Type 2 covers effectiveness over a sampled period. Even the best SOC 2 is a photograph, not a feed.

3. The vendor questionnaire

Useful for what it is: a structured claim. When a vendor writes “we do not subcontract” or lists hosting on a named cloud in a named region, you have something contractual conversations can attach to.

4. Outside-in signals

DNS records, certificate transparency logs, trust-center pages, and status pages reveal infrastructure relationships nobody disclosed: which cloud hosts the vendor, which CDN fronts it, which email provider sends for it.

Run the pass at two dependency levels: the organization level (who the vendor relies on as a company: its cloud, support desk, analytics stack) and the product or service level (who touches the specific service you bought, usually a smaller, different set). The org-level set predicts incident blast radius; the service-level set predicts your data’s actual path.

Four instruments in, a pattern emerges: every one documents the chain your vendor knows about and chose to write down. None sees the chain that assembles in your visitor’s browser at page load. That blind spot is the next section.

On attestation limits generally, including how far a SOC 2 or ISO 27001 certificate stretches before it tears: the third-party privacy risk guide covers them in full.

The fourth parties your paperwork can’t see

Your website loads fourth-party vendors that no contract, list, report, or questionnaire will ever name. You approved one vendor; at page load, its tag executes in your visitor’s browser and can load further scripts and send data to more recipients: the tag’s CDN, its analytics backend, its partners, parties the vendor never enumerates anywhere you can read. The network tab shows nine recipients.

The contrast is structural, not incidental:

• On the contract chain, every link exists because someone signed something. Discovery is a paperwork exercise: read the lists, reports, and clauses. Diligence flows down the same channel as the relationship.
• On the browser chain, every link exists because code executed. No procurement event happened; no DPA was drafted. The relationship is created fresh on every page load by a script you approved once, doing whatever its current version does.

Approval-based diligence cannot reach this chain: every instrument presupposes a counterparty that can answer, and a piggybacked recipient is nobody’s counterparty. It appears in no vendor inventory (the vendor who would list it is itself a fourth party) and in no sub-processor list (those lists describe processing relationships, not script behavior).

The mechanisms, how tags load other tags, how recipient chains assemble, what consent states gate, are covered in depth in the web-tracking guide. The channel-level map is in the data-leakage guide. 

What matters here is the classification: every runtime recipient is, by definition, a fourth party your vendor relies on, and its failures and data practices become yours.

And unlike the contract chain, this chain is directly observable, from the outside, on your own properties, without anyone’s permission. 

What can you verify, and what must you take on trust?

Sort every fourth-party claim you currently hold into three buckets: verified (you observed it), verifiable (an instrument exists that could check it), and trusted (you are relying on someone’s statement). Expect bucket three to hold almost everything.

The table’s pattern is the point. Everything on the contract chain is a statement by an interested party, checked at intervals, against documents the same ecosystem produces. None of this makes them worthless; it makes them trust instruments, and trust instruments fail silently, in the gap between export day and incident day. 

Only the browser-chain claim is directly checkable because your own properties are the one place in the chain where you can observe instead of ask. What your pages load, what each script sends, and to whom is evidence you can produce without waiting for anyone’s disclosure cycle.

The boundary matters as much as the capability. Outside-in observation sees what executes in the browser and what it transmits. It does not see server-to-server flows, what a vendor does with data after arrival, or processing inside someone else’s infrastructure. Server-side sharing is a boundary, not a managed surface. Where it matters, your instruments are the contract-chain ones above, with their ceilings.

Which fourth parties actually matter?

The material ones, and materiality is a question about consequences, not contract size. A fourth party matters when its failure or misuse would hurt you: by the data that reaches it, the function it performs, the dependence it concentrates, and the difficulty of replacing it. In practice, critical fourth parties are the subset that deserve individual attention.

For example, on the browser chain, your site runs an approved analytics tag, and observing a session shows it loading two further recipients. The exposure picture is a per-recipient list, one row per party that received something:

• The approved vendor receives page paths, timestamps, and a pseudonymous ID.
• Its first loaded recipient receives the same page URL, including query parameters, which on a healthcare or fintech site can carry appointment types or product names.
• The second receives the visitor’s IP address and browser fingerprint.

Now the materiality questions have something to bite on: query parameters with appointment context are sensitive-adjacent, so this chain is not low-materiality. If three of your other vendors’ tags also load that second recipient, it is a shared dependency you never approved. This per-recipient inventory is a fourth-party view; the channel-by-channel version is in the data-leakage guide.

Everything below the materiality line is monitored in aggregate, not assessed one by one. That is not negligence, but the stopping rule the next sections build to.

What levers do you have over a party you have no contract with?

You have more control than you might think. While you do not have a contract with a fourth party, you do have a contract with someone who does, and absolute control over your own pages: two lever sets, one per chain.

Through your vendor (the contract chain):

• Approval and objection rights. GDPR Article 28(2)-style general authorization with a duty to inform gives you a live objection right over sub-processor changes; an objection right never exercised is a clause, not a control.
• Change-notification duties. Contract for notice windows on subcontracting changes, so you learn that the list changed instead of discovering the diff later.
• Flow-down of standards. Require that your vendor’s subcontracts carry the same data-protection obligations you imposed on the vendor. Article 28(4) makes this the GDPR default; RBI’s outsourcing directions make the liability version explicit; elsewhere it is a clause you ask for.
• Evidence inheritance, read critically. Sub-processor lists, SOC 2 subservice sections, and questionnaire answers flow up through your vendor. Inherit them, but read carve-outs as carve-outs and export-day lists as export-day lists.
• Termination mechanics. The interagency guidance’s contract provisions (notice or consent for subcontracting, subcontractor liability, termination rights) exist so that “remove that sub-processor or we leave” is a sentence you can actually say.

On your own properties (the browser chain):

• Continuous observation. Gating and policy are blind without a feed: watch what your pages actually load and transmit, so a new recipient or a new data category trips the levers below within days and strengthens your security posture. This is the one instrument that needs no vendor’s cooperation, and it is what “enforced” means in practice.
• Consent gating. Tags that fire only after the consent state permits them cut off browser-chain recipients at the source.
• Tag policy and enforcement. A written policy on which tags may load which resources, enforced on your own pages, is a lever no fourth party can negotiate with: it executes in the browser, where you are the platform.

When you find an unapproved fourth party, the response path is short:

1. Object through your vendor, in writing, invoking the authorization or notice clause; the vendor is your only contractual route to the contract chain.
2. Gate or block the tag on your own properties while the objection runs; you need no one’s permission to stop your pages from loading a recipient.
3. Escalate with observed evidence: dated captures of what loaded and what it carried beat a forwarded complaint.
4. Accept in writing if the answer is genuinely fine: the party, the data, the rationale, the reviewer, the date. A documented acceptance is a control. Silence is not. The wording that binds is counsel’s drafting job, not this page’s. This section inventories which levers exist and which chain each pulls.

How far down the chain should diligence go?

As far as your instruments can still see, and not one hop further, with the boundary written down. The honest answer to “how many tiers?” is that the question is wrong. Counting hops measures anxiety, not risk. The right question is where your visibility ends on each chain and whether you have documented the decision to stop there.

On the contract chain, the verified guidance structure is your rule: assess your vendor’s reliance on and oversight of subcontractors during due diligence, contract for notice, liability, and termination, monitor how the vendor manages its chain, and keep a risk-appropriate inventory of related subcontractors. 

The FSB’s toolkit adds the principle: indirect reliance does not lessen your accountability. So the contract-chain stopping rule is: your diligence target is the quality of your vendor’s vendor-management, plus a documented inventory of what sits beneath, deeper for material fourth parties, aggregate for the rest.

On the browser chain, there is no vendor program to validate because there is no vendor relationship at all. The stopping rule is the observation boundary. You can verify what your pages load and transmit, not what recipients do with it afterward. Diligence there means continuous observation plus gate-and-block enforcement, all the way to the recipient’s front door.

Diligence ends where observation ends, and the stopping point is a written decision, not an accident. 

The deliverable that satisfies an examiner or board is a one-paragraph scope decision with this skeleton:

• What we inventory, per chain: named sub-processors and subservice organizations on the contract chain; observed runtime recipients on the browser chain.
• At what depth: material fourth parties individually assessed; the long tail monitored in aggregate; rationale tied to the materiality factors.
• What we monitor and on what triggers: list changes, newly observed recipients, breach signals; cadence per chain.
• What we accept in writing: known fourth parties we are not chasing, with the reason, the owner, and the date.
• When we revisit: scheduled review plus the triggers above.

What does fourth-party risk management look like as a program?

Fourth-party risk management is not a second TPRM program bolted onto the first: it is a set of additions to instruments you already run, plus one capability most programs lack. The skeleton:

Monitoring triggers, the events that move a fourth party from “monitored in aggregate” to “assessed today”:

• A sub-processor list change touching a material vendor.
• A newly observed recipient on your pages, or a known recipient newly receiving a different data category.
• A breach or outage signal at a party anywhere in your inventory, yours or a peer’s.
• An incident at a direct vendor that escalates its tier, re-opening its whole chain.

Ownership stays simple: one named owner per chain, both reporting into your existing vendor-risk governance.

A realistic first 90 days 

Weeks one and two, collect the contract-chain inventory for material vendors and run the first browser-chain observation pass. Weeks three to six, assess what surfaced against the materiality factors and exercise objection or gating levers where needed. Weeks seven to twelve, write the scope decision, open the acceptance register, and set the triggers. After that, the program is maintenance, not a project.

How MELURNA helps with fourth-party risk

The browser chain is the half of fourth-party risk that paperwork cannot reach. It is the half MELURNA observes. MELURNA scans your own web properties from the outside and shows you what actually executes: which third and fourth parties fire on your pages, what data each one carries, who receives it, and what changed since the last scan.

Applied to this article’s problems: the blind-spot section becomes a report instead of an argument. The claim register’s one directly checkable row gets checked, the materiality exercise gets its per-recipient data categories without a questionnaire, and the program skeleton’s browser-chain column runs on observation rather than on vendors remembering to tell you.

If you want the observed version of your own fourth-party chain, request a demo, and we’ll measure your exposure.

FAQs

DISCLAIMER: This article is for general informational purposes only and does not constitute legal advice. While we strive for accuracy, we make no warranties about the completeness or reliability of this information, and are not liable for any errors, omissions, or actions taken based on its contents. Consult a licensed attorney for guidance specific to your business.