A few years ago, a major cloud database provider had an extended outage that cascaded through dozens of well-known SaaS products. None of the affected SaaS products had advertised the database provider as a dependency. Their customers had no idea that the SaaS company they bought from was running on top of a database they had never assessed, never put under a contract, and never monitored. When the database went down, the SaaS product went down. When customer data was exposed in similar incidents that have followed, the chain ran through providers that the buyer had no contractual relationship with at all.
This is fourth-party risk. The third party is the vendor you bought from. The fourth party is the vendor your vendor bought from. You have no contract with the fourth party, no leverage, no monitoring, and often no awareness that they exist. Until they fail. Then they are your problem, because the failure is going to land on your customers regardless of whether you knew about the chain.
Why Fourth Parties Were Ignored
The TPRM industry built its early frameworks around third parties because that was the visible boundary. You sign a contract with a vendor. You assess that vendor. The assessment ends at the vendor's organizational boundary. What was on the other side of that boundary was the vendor's problem.
This worked when vendors were vertically integrated. When a payroll provider ran their own software on their own servers in their own data center, the third-party assessment covered the actual risk surface. The cloud era ended this. Modern SaaS vendors are deeply layered. A typical mid-market SaaS product might run on AWS, use Stripe for payments, Twilio for SMS, Auth0 for identity, Datadog for observability, Snowflake for analytics, and a dozen other niche services for specific functions. Every one of those is a fourth party from the buyer's perspective. The vendor's "stack" is mostly other vendors' stacks.
The blast radius pattern is consistent. If a foundational fourth party fails (a cloud region, a CDN, a payment processor, a DNS provider), the failure cascades through hundreds or thousands of third-party SaaS products simultaneously. Your TPRM program assessed each third party in isolation. The fourth-party concentration risk was invisible because it was distributed across vendors who all looked independent from your view.
Mapping The Chain
Mapping fourth parties starts with asking your third parties for their subprocessor list. Most enterprise SaaS vendors publish a subprocessor list on their trust portal because GDPR essentially requires it for vendors that process EU personal data. The list is usually accurate at a point in time and is supposed to be updated when subprocessors change.
The subprocessor list gives you the names. It does not give you the structure. To get structural information (which subprocessors are critical to which functions, which are interchangeable, which are concentrated across many of your vendors), you need to do additional analysis. The analyses that matter are concentration analysis and criticality analysis.
Concentration analysis asks: across all my vendors, how many depend on the same fourth party? If 40 of your 200 vendors depend on the same identity provider, that identity provider is a concentration risk. Its failure does not affect one vendor; it affects 20% of your supplier base. The concentration analysis often surfaces foundational providers that you would not have flagged in an individual third-party assessment because they were just one of many subprocessors on each list.
Criticality analysis asks: for each fourth party, what happens if it fails? Some fourth parties are critical (the cloud provider hosting your CRM). Some are auxiliary (the email delivery service for transactional emails). The fourth-party risk register should distinguish, because the response plan for a critical fourth party going down is different from the response plan for an auxiliary one.
SBOM Ingest As Fourth-Party Telescope
The most useful technical control for fourth-party visibility in software vendors is SBOM ingest. The SBOM tells you what components the vendor's product is built from. Every component is a fourth party in the software supply chain sense, even if it is not a fourth party in the GDPR sense. A vendor whose product depends on an obscure open source library that has six known CVEs is a vendor with fourth-party risk in their software supply chain, regardless of whether the library is on their subprocessor list.
This is where SBOM ingest changes the fourth-party game. The subprocessor list shows you organizational dependencies. The SBOM shows you software dependencies. Both matter. Both have to be tracked. The SBOM is updated more frequently because software ships frequently, which means the SBOM is the higher-resolution view of the chain.
When the same compromised open source package shows up in 30 of your vendors' SBOMs, you have a fourth-party concentration risk that no subprocessor list would have shown you. The package is not a subprocessor. It is a transitive dependency. But the concentration is real, and the response (notify the affected vendors, ask for remediation timelines, assess customer impact) is the same as for any fourth-party issue.
How Safeguard's TPRM Module Maps The Chain
Safeguard's TPRM module builds two parallel chain views. The organizational view ingests the vendor's subprocessor list (uploaded or scraped from the trust portal) and maintains a mapping of which subprocessors are used by which vendors. The view supports concentration queries: show me the fourth parties that appear across more than ten of my vendors, sorted by criticality.
The software view ingests the SBOM of each vendor's product and maintains a component graph. The graph supports concentration queries at the component level: show me the components that appear across more than 50 of my vendors' products, with current vulnerability status for each. When a critical CVE drops on a widely used component, the module immediately tells you which of your vendors are affected, in what products, in what versions.
The two views are linked. When a fourth-party organization (say, a CDN provider) has a public incident, the module shows you the affected vendors from the organizational view. When a fourth-party software component (say, a popular logging library) has a critical CVE, the module shows you the affected vendors from the software view. The fourth-party question stops being "which of my vendors might be affected?" and becomes "which of my vendors are affected, with confidence."
The Conversation The Vendor Doesn't Want
Some vendors push back on fourth-party visibility. They argue that their subprocessors are confidential, that their architecture is proprietary, that their SBOM contains competitive information. These arguments have less standing than they used to. GDPR established the principle that subprocessors must be disclosable. The CRA establishes the principle that components must be enumerable. The market pressure from regulated buyers is establishing the principle that SBOMs are a default deliverable.
The vendors who resist are signaling something. Sometimes the signal is that they have subprocessors they should not have or components they have not been managing. Sometimes the signal is just that they have not built the muscle of disclosure and they are slow to start. Either way, the resistance is a data point. Vendors who can produce a current subprocessor list and a current SBOM in 48 hours have their supply chain under control. Vendors who need three weeks and a redacted PDF are telling you something about their internal hygiene.
The Board Conversation
Fourth-party risk has now reached the board level in most large organizations. The questions the board is asking, and the questions you should be ready to answer, are these. What are our top fourth-party concentration risks? Which fourth parties would cause the most damage if they failed? What is our exposure to a specific named provider that has been in the news? How quickly can we identify which of our vendors depend on a specific fourth party?
A TPRM program that cannot answer these questions in a meeting is a program that does not have fourth-party visibility. Building the visibility takes work, but the work scales. Once the chain is mapped and the SBOM ingest pipeline is running, the board questions become five-minute queries. Until then, every board ask becomes a fire drill.