Fourth-Party Risk Visibility in SOC 2 Vendor Programs

SOC 2 vendor frameworks deliver assurance, yet their visibility into fourth parties hinges on the boundary between audit scope and subsequent oversight. Excluded areas demand additional proof, whereas comprehensive audits evaluate the relevant subservice functions firsthand. Such reports cannot substitute for initiatives confirming outsourced supervision, charting mutual reliance, and mandating updates whenever those links shift.

Why SOC 2's subservice organization rules matter to vendor program managers

SOC 2 reports handle subservice organizations through either the carve-out or inclusive approach. Under carve-out, the report identifies which entity management relies on for specific functions, though the auditor leaves those functions unexamined. With the inclusive approach, direct testing of the subservice organization's controls demands both a written assertion and full cooperation.

In reality, engagements that include every service provider are rare, with carve-outs being the norm. Big providers like Stripe, Okta, and AWS issue SOC 2 reports of their own, so leaning on those makes more sense than retesting identical controls within every customer’s audit. A vendor’s report may state a reliance on some other company even when that company’s controls were never audited. So for those managing vendor programs, the key question is not just whether a dependency shows up, but how much evidentiary support the report offers about it.

What the carve-out method actually discloses — and what it leaves unexamined

When using a carve-out, management names a subservice entity and specifies the CSOCs, or Complementary Subservice Organization Controls, expected from it. These are management assertions. An auditor will base their conclusion about the service organization upon those CSOCs functioning as expected, yet verifying that premise falls beyond what this engagement covers. Consequently, what the report reveals and what it actually guarantees do not fully align.

Take a payroll vendor offering SaaS that excludes its cloud infrastructure provider from the report. That document names the provider and details which safeguards the payroll vendor expects it to execute. Visibility ends right at that assumption. The customer now knows where responsibility falls, yet no auditor for that payroll vendor has examined those excluded safeguards. So a dependency that is clearly described is not the same as one that has been examined.

Reviewers should secure the subservice provider’s SOC report or document why the residual risk is being accepted. That action falls within the vendor program. The framework neither traces the dependency chain nor gathers evidence from excluded organizations automatically. A carve-out flags the exposure for additional review but does not itself resolve that exposure.

The fourth-party blind spot that lives inside every carve-out

Whenever a supplier depends on an outside firm to fulfill its obligations, that third entity becomes a fourth party with no direct contract linking it to the buyer. For instance, AWS becomes a fourth party whenever a SaaS vendor stores client information on its infrastructure. Similarly, an online retailer relying on Stripe for transactions makes that processor a fourth party. Contractual distance defines this relationship. Buyers may recognize a vendor's identity and find it mentioned in documentation while lacking any authority to supervise its operations.

Naming the provider still does not show its own dependencies. Even if the carve-out lists the vendor's dependency on AWS, it does not address AWS subcontractor oversight or prove the vendor's handling of other infrastructure dependencies. It still does not map the supply chain. Scope stays with the system of the service organization and with the subservice arrangements included in it. A fourth party can appear in the report even though its control evidence and downstream chain are still incomplete.

An architectural boundary exists here. Suppliers face no obligation to reveal each downstream dependency, while voluntary details about fourth parties rarely capture the full picture. So relying on a neat separation for confidence demands that the paperwork resolve an issue outside its intended scope. Operational impacts become most obvious when seemingly separate suppliers depend on an identical backend.

What cascading incidents reveal about the cost of fourth-party invisibility

In 2023, Cl0p ransomware operators leveraged a zero-day in MOVEit Transfer to compromise entities outside the platform's direct client base. Firms handling their payroll, benefits, and HR services ran the platform. Numerous victims never realized the software sat within their procurement network, since a second-tier supplier beyond their reviewed partner deployed it. This breach exposed a common reliance invisible to standard supplier evaluations.

The same pattern shows up in the December 2021 AWS East-1 outage, and this time no malicious actor was involved. When a provider the customers had no dealings with and no rights to audit went down, vendors lacking failover across regions left their users cut off from the services. The result here was lost service availability.

These incidents show that a single platform can take multiple services down at once, whether the trigger is an attack or a system failure. Concentration risk analysis is designed to reveal those shared dependencies. While a carve-out may pinpoint a single dependency, it stops short of forcing the vendor to reveal how broadly the customer depends on shared infrastructure across critical services.

What regulators actually require versus what SOC 2 delivers at the fourth-party tier

Regulators expect oversight beyond simply acknowledging a listed dependency, though they rarely mandate that firms examine each fourth party firsthand. FINRA guidance says firms should “assess the risk of any fourth-party vendors handling firm data”. Such an evaluation demands more than confirming a downstream provider appears in documentation. Firms must instead evaluate the hazards introduced by these connections and whether suppliers supervise them sufficiently.

DORA, in force since January 17, 2025, lays down stricter obligations for the financial entities within its scope. Article 28(4)(c) covers concentration risk identification and evaluation, while the Commission's Delegated Regulation of March 24, 2025 details how subcontracting chains must be assessed. Read together, they direct focus to material subcontractors that support ICT services and to risks across the wider chain. Disclosure alone leaves the evaluation unfinished. What a SOC 2 carve-out delivers is a reliance plus controls taken on trust.

The SEC imposes a distinct kind of pressure through its cyber reporting mandates. Firms must report yearly on how they handle, plan for, and oversee cyber threats, along with any significant breaches. They do not mandate cataloging every downstream vendor. Yet oversight and major breaches remain reportable regardless of whether the threat stems from a third party. The real challenge lies in bridging awareness of a dependency with the ability to articulate its risk controls.

The strongest objection: why delegating to vendors’ TPRM programs is defensible but not sufficient

Assigning the vendor’s TPRM program the role of monitoring fourth parties is a sensible way to divide responsibility. Customers lack the privity needed to bind unrelated organizations to security duties or insist on audit access they are not required to provide. That relationship instead sits with the direct vendor. Regulators tolerate that model in light of these constraints and leave subcontractor supervision to the party that actually controls the vendor chain.

The difficulty is that delegation makes the vendor’s oversight program a dependency in its own right. How well that program works affects the customer’s exposure, but a SOC 2 report rarely has enough evidence to judge it unless vendor management is in the system description and is tested. A carve-out does not establish that this happened. Most reports do not describe or test the service organization’s vendor management program in meaningful depth.

Delegation should be accepted only after it has been checked. A vendor management program that has actually been tested is more persuasive than a written account of the subservice organization’s assigned role. When that proof is missing, the customer still must have grounds to rely on how the vendor supervises the relationship. Report review therefore comes first, identifying the controls actually examined and the expectations left on paper, so later contract terms and operational measures can cover the remaining gaps.

What vendor program managers should look for when reviewing a SOC 2 report for fourth-party signals

For reviewers, each carve-out signals what to investigate next. The report must name the subservice provider and spell out exactly what it does. Next, the CSOCs specify the controls that management expects that vendor to handle. Those disclosures together map out the gap where the reviewer has to obtain that vendor’s SOC report or record acceptance of any remaining risk.

Another clue comes from how the vendor describes its oversight. A vendor claim that it annually evaluates the SOC 2 report for the relevant subservice provider suggests the review process is established. Reviewers should verify that the system description covers the vendor management program and that auditors tested it. That distinction keeps proposed monitoring separate from proof that the oversight process was actually audited.

Change notification is another key element of the system description. When a vendor commits to alerting customers about subservice organization changes, it signals that customers will be informed of material substitutions. A missing notification clause also deserves scrutiny. If a SaaS vendor leaves out any reference to cloud infrastructure, it could signal that not all material dependencies have been identified, though this gap by itself is not proof. When combined, these elements reveal how much assurance the report provides and where additional scrutiny is warranted.

Supplementing SOC 2 review with contractual and operational controls that close the remaining gaps

Contracts governing Tier 1 and Tier 2 supplier relationships must compel vendors to identify key fourth parties and notify clients of any substitutions, especially when essential service providers are affected. That shifts transparency from a nice-to-have into a clear responsibility. Response provisions must detail supplier duties if a downstream compromise or outage impacts the client, including how quickly to report and what fixes are required. These clauses close the contractual distance that hurts most during an incident.

The next step is to verify that those responsibilities hold up in practice. Revisit high-risk vendors each year, with longer cycles for providers presenting medium or lower risk. Include SOC reports as part of the broader review, alongside financial statements, continuity planning materials, proof of cyber resilience, and incident response records. When choosing vendors and reassessing them later, also look at how the vendor governs its operations, since delegated oversight depends on whether it can extend risk standards through its subcontractors.

Concentration analysis reveals shared fourth-party dependencies among key vendors. Those running vendor programs need to question suppliers about their underlying infrastructure and any backup arrangements. Risks should still be logged regardless of whether an immediate fix exists, so that a lack of solutions never justifies omitting them. Continuous oversight, paired with periodic reviews, keeps tabs on shifting third-party providers.

Entities covered by DORA find an operational purpose for that inventory work in the Register of Information spelled out in Article 28(3). Staying current on that record of ICT contracts and their subcontracting chains demands focus past the most recent audit window. SOC 2 is where assurance begins, yet a program that halts at that point lets a well-known limit on audit scope become a lasting gap in how it oversees itself.