Your vendors' vendors, and the one provider half your critical suppliers depend on

A vendor list looks like a list. It is really a graph. Your call-recording vendor sends transcripts to an AI provider. Your hosting provider runs in someone else’s data centres. Your payroll vendor uses a cloud platform that half your other suppliers also use. These are fourth parties: your vendors’ vendors. You did not choose them, you have no contract with them, and when one of them has an incident, several of your suppliers can be affected at once.

This use case shows how InsightVendors finds fourth parties in documents you already collect — data processing agreements (DPAs) and SOC reports — how to see where they concentrate, and how to react when one has a problem. It uses the demo organisation, Northwind Labs, whose vendors are fictional, and it is careful about what the product does automatically and what is still a person’s job.

Why fourth parties are a board-level concern

Concentration risk is the possibility that many of your critical services fail together because they share something underneath: a cloud region, a data-centre operator, an identity provider, a payment processor, a model provider. Each vendor might pass its own review. The portfolio can still have a single point of failure that no individual review would reveal.

Regulators have noticed. DORA, applying in the EU from 17 January 2025, requires financial entities to consider ICT concentration risk and to keep a register of information on ICT third-party arrangements, including information about subcontracting for services that support critical or important functions. The EBA outsourcing guidelines address sub-outsourcing. GDPR Article 28 requires a processor to have the controller’s authorisation before engaging another processor and to pass on the same data protection obligations. NIS2 Article 21 lists supply-chain security among its measures. Confirm with your compliance team which apply to you; all of them point to knowing who sits behind your vendors.

Where fourth parties are written down

You do not need a separate survey to find most fourth parties. Two documents most vendors already provide list them.

Document	What it names	What else to read
DPA (data processing agreement)	Subprocessors: who processes your personal data on the vendor’s behalf, often with purpose and location	Notice and objection rights for new subprocessors; data location; transfer mechanism such as SCCs
SOC 2 or SOC 1 report	Subservice organisations: providers whose controls the vendor relies on, such as data centres or cloud platforms	Whether they are carved out of the audit scope; the controls the vendor expects them to operate
MSA or terms of service	Sometimes a subcontracting clause, rarely a list	Whether the vendor may subcontract without notice; flow-down of obligations

The SOC point deserves care. Many SOC reports use the carve-out method for subservice organisations, which means the auditor did not test the subservice organisation’s controls. The vendor’s report is then only half the picture; the other half is the fourth party’s own assurance. Knowing a fourth party exists is the first step to asking for it.

Extraction: Stackforge and Equinix

Stackforge is Northwind’s fictional Tier 1 hosting provider: production systems, $420,000 a year, credentials and customer data. Northwind holds its SOC 2 Type II. When the Document agent read the report, it extracted the type, period, auditor, opinion, exceptions, complementary user entity controls (CUECs) and subservice organisations. One subservice organisation is named: Equinix. It now appears on Stackforge’s Fourth parties tab, with its purpose (“Subservice organization named in the SOC report”) and its source marked SOC.

The location column is empty, and that is honest: the SOC report named the subservice organisation but not where. A person can add it. The tab also has an Add button, because some fourth parties come from conversations and questionnaire answers rather than documents.

Extraction: Callwave and an AI subprocessor

Callwave, the fictional Tier 2 call-recording vendor, shows the privacy side. Northwind holds its MSA, DPA and SOC 2 Type II. The DPA’s subprocessor list includes OpenAI, and the Document agent did more than record it: it raised a finding, “OpenAI listed as sub-processor — AI data exposure risk”, citing the page and quoting the text. Callwave’s Fourth parties tab shows three entries in all.

That finding is a good example of why fourth parties matter commercially as well as technically. Sales calls contain customer names, deal terms and sometimes personal details. If those recordings are sent to a model provider, Northwind needs to know on what terms: whether data is retained, whether it is used for training, which region processes it. Those are questions for Callwave, informed by its DPA, and possibly contract changes — not questions Northwind can put to the fourth party directly.

The vendor list as a graph. Dotted line: a shared fourth party only appears if each vendor’s documents name it.

From vendor view to portfolio view

One vendor’s fourth parties are a due-diligence detail. The same fourth party behind many vendors is a concentration risk. Insights has a fourth-party concentration view that aggregates what has been extracted across the portfolio: which fourth parties appear, behind how many of your vendors, and in which tiers. The question it answers is the one a risk committee should ask once a year at least: if this provider went down, or was breached, which of our services would be affected?

In an eight-vendor demo, the concentration view is small. We will not dress it up with percentages it does not support. In a real portfolio of hundreds of vendors, a handful of cloud platforms, data-centre operators, identity providers and, increasingly, AI model providers tend to appear repeatedly. The value of the view grows with the number of documents read.

Fourth-party type	Typical concentration question	What to ask your vendors
Cloud platform or region	How many Tier 1 services run in one region?	Region, failover, recovery objectives
Data-centre operator	Is one operator behind several hosting vendors?	Subservice assurance; site diversity
AI model provider	Which vendors send our data to a model provider?	Retention, training use, processing region
Payment or identity provider	Would one outage stop several processes?	Fallbacks; notification commitments

When a fourth party has an incident

Monitoring in InsightVendors attaches signals to vendors: a breach, a sanctions hit, adverse media, a financial event, an expiring certificate, portal silence. The Monitoring agent decides the reaction per tier — note, finding, re-assessment or escalation. In the demo, a signal that “Stackforge us-east region outage lasts six hours” produced a finding on Stackforge.

A fourth-party incident needs one more step, and today a person takes it: find every vendor that lists the affected fourth party, then record a signal or open a re-assessment on each, letting the tier decide the urgency. A Tier 1 vendor whose SOC report names the affected provider gets a direct question within the day; a Tier 4 vendor gets a note. The vendor follow-ups the Remediation agent drafts are held in the outbox until someone releases them.

What each reader takes from it

What it adds up to

Fourth-party risk sounds like an exercise in infinite regress. In practice, most of the useful information is already in two documents you should be collecting anyway. Read them for subprocessors and subservice organisations, keep the source, look at the portfolio once a year for providers that sit behind too many critical vendors, and have a short runbook for the day one of them is in the news.

Keep reading