Third-Party vs Fourth-Party Risk

A financial services company contracted with a cloud analytics vendor for customer data processing. The vendor's SOC 2 Type II report covered their analytics platform. What the report did not cover , and what the TPRM assessment had not reached , was the vendor's use of a subprocessor for data storage. The vendor stored processed analytics output in a managed data warehouse operated by a third company. Approximately fifty-three percent of the financial company's customer data, after processing, resided in this subprocessor's infrastructure. The subprocessor had no direct contractual relationship with the financial company. The financial company's DPA with the analytics vendor included a clause permitting subprocessor use with written notice, and the notice had been provided. The financial company had acknowledged the notice. Nobody had assessed the subprocessor's security controls. Nobody had reviewed the subprocessor's data residency. Nobody had confirmed the subprocessor's breach notification obligations ran through to the financial company with the same timelines as the primary vendor's obligations. The financial company's customer data was in a system governed by a contract they were not party to, assessed by a programme that did not reach it, and covered by breach notification obligations that had not been validated.

What is the Third-Party vs Fourth-Party Risk Problem, Really?

Fourth-party risk is the security risk created by the vendors of your vendors , the subprocessors, sub-service providers, and supply chain participants that your third parties use to deliver their services to you. You have a direct relationship with your third parties , you contracted with them, assessed them, and govern them through your TPRM programme. You have an indirect relationship with their subprocessors , your data may flow through them, your services may depend on them, and a breach or failure at the fourth-party level may affect your customers , but you have no direct contractual relationship, no direct assessment, and no direct governance.

The dependency chain problem is the fundamental fourth-party risk dynamic. Modern technology services are built on dependency chains , a SaaS vendor uses cloud infrastructure, cloud-native databases, third-party authentication services, content delivery networks, and specialised data processing services. Each dependency is a fourth-party relationship from the customer's perspective. The SaaS vendor's controls govern the SaaS platform. The cloud infrastructure provider's controls govern the infrastructure. The customer's risk assessment covers the first link. The subsequent links are invisible unless the vendor's assessment documentation surfaces them.

GDPR's fourth-party visibility requirement is the most direct regulatory mandate for fourth-party risk management. Article 28 of GDPR requires that data processors use subprocessors only with the controller's prior written authorisation and that subprocessors are subject to equivalent data protection obligations. This means that an organisation's DPA with a vendor must include provisions that apply to the vendor's subprocessors , and that the organisation has some basis for assurance that those obligations are being met. GDPR regulators in enforcement actions have held controllers responsible for subprocessor breaches where adequate subprocessor oversight was not maintained.

• Subprocessor inventory not obtained , no visibility into which fourth parties process customer data on the vendor's behalf
• Subprocessor SOC 2 or equivalent not reviewed , no assurance for the fourth-party security posture
• Subprocessor DPA chain not validated , whether equivalent data protection obligations flow to subprocessors
• Subprocessor breach notification chain not confirmed , whether breach notification obligations flow upstream within required timelines
• No fourth-party concentration risk assessment , multiple vendors using the same subprocessor creating correlated risk

Why this matters

Fourth-party risk matters because data breaches do not respect the organisational boundaries of the dependency chain. When a subprocessor is breached, the breach notification obligation, the regulatory examination, and the customer impact flow back to the organisation whose data was processed , regardless of how many contractual links separate the organisation from the subprocessor. The Target breach was a third-party risk event (HVAC vendor). The SolarWinds breach was a third-party risk event at the SolarWinds customer level and simultaneously a fourth-party risk event for customers of organisations that used SolarWinds , the breach affected systems at companies that did not directly use SolarWinds but depended on service providers that did.

The concentration risk dimension is the fourth-party risk concern that is most difficult to see from an individual vendor assessment. If multiple vendors use the same cloud infrastructure provider, the same managed database service, or the same authentication platform, a single failure at the shared subprocessor level affects all vendors simultaneously , and all of their customers. The individual vendor assessments do not reveal the correlated exposure that shared fourth-party dependencies create across the vendor portfolio.

Where most teams get this wrong

The most consistent failure is treating vendor contractual responsibility for subprocessors as equivalent to customer risk management of subprocessors. Contractual responsibility allocates liability. It does not eliminate the customer's regulatory obligation, reputational impact, or customer notification requirement if the subprocessor is breached.

• Treating vendor contractual responsibility as customer risk management
• Subprocessor inventory not requested , relying on DPA subprocessor notification without reviewing inventory
• No subprocessor security assessment , fourth-party posture not reviewed
• Breach notification chain not validated , subprocessor obligations not confirmed to flow upstream with required timelines
• Fourth-party concentration not assessed , shared subprocessors across vendor portfolio not identified

What good looks like

Mature fourth-party risk programmes obtain subprocessor inventories from critical vendors, review subprocessor security credentials, validate that DPA obligations flow to subprocessors with equivalent requirements, confirm breach notification chains, and assess concentration risk across the vendor portfolio.

• Subprocessor inventory from critical vendors , complete list of subprocessors handling customer data
• Subprocessor security credentials review , SOC 2 reports or equivalent for material subprocessors
• DPA chain validation , confirmation that equivalent data protection obligations apply to subprocessors
• Breach notification chain confirmation , subprocessor breach notification obligations flow upstream within required timelines
• Fourth-party concentration assessment , shared subprocessors across vendor portfolio identified

Tooling

TPRM Platforms with Fourth-Party Mapping , ProcessUnity, Prevalent

TPRM platforms with fourth-party relationship mapping support visualisation of the dependency chain beyond the direct vendor , tracking which subprocessors are used by which vendors and identifying concentration at the fourth-party level. For TPRM practitioners, asking whether the TPRM platform supports fourth-party relationship mapping provides a specific dependency chain visibility question.

Supply Chain Intelligence , Interos, Coupa Risk

Supply chain intelligence platforms map the extended supply chain beyond direct vendors , identifying which subprocessors vendors use and monitoring those subprocessors for security and operational risk signals. For TPRM practitioners, using supply chain intelligence platforms for critical vendor relationships provides fourth-party visibility without requiring direct engagement with each subprocessor.

Governance challenges

The governance challenge with fourth-party risk is the assessment reach limitation. Customers cannot directly assess their vendors' subprocessors , they have no contractual relationship, no assessment rights, and no direct access. Fourth-party risk governance requires working through the vendor , requesting subprocessor inventories, requiring vendors to manage subprocessor risk to defined standards, and using vendor-provided certifications and SOC 2 reports as assurance mechanisms for the fourth-party level.

• Request subprocessor inventories from Tier 1 vendors , list of all subprocessors handling customer data
• Require vendor to maintain subprocessor SOC 2 or equivalent
• Validate DPA subprocessor obligation language , equivalent requirements applied
• Confirm breach notification chain , how quickly subprocessor breaches reach the customer
• Identify fourth-party concentration across vendor portfolio

If you are a small team

Ask your three highest-risk vendors for a complete list of subprocessors that handle your organisation's data , not just the notice you received under the DPA, but the specific companies, what they process, where they store it, and whether they have SOC 2 or equivalent certifications. That list is the fourth-party inventory for your most critical relationships. Any subprocessor processing more than twenty percent of your data at a vendor that you have not assessed or reviewed the credentials of is a fourth-party risk gap worth addressing.

• Request complete subprocessor inventory from highest-risk vendors
• Review subprocessor SOC 2 or equivalent certifications for material subprocessors
• Validate DPA obligation chain to subprocessors
• Confirm breach notification timeline from subprocessor to customer

What to require

Ask directly:

"Can you provide a complete list of subprocessors that handle our organisation's data , including what each processes, where they store it, and what security certifications they hold?"

"If a subprocessor experiences a breach affecting our data, what is the notification timeline from the subprocessor to you, and from you to us , and is the combined timeline within our regulatory notification requirement?"

Expect as evidence

• Complete subprocessor inventory with functions and data categories
• Subprocessor security certifications , SOC 2 or equivalent
• DPA subprocessor obligation confirmation
• Breach notification chain timeline documentation

A vendor who confirmed subprocessor notification under the DPA should be asked for the complete inventory of subprocessors handling the customer's data and the combined breach notification timeline from subprocessor to customer. The notification was provided. The fourth-party risk management question is separate.

How to evidence it

• Subprocessor inventory records for critical vendors
• Subprocessor security credential review records
• DPA subprocessor chain validation
• Breach notification chain timeline confirmation

Key Takeaway

Your vendor is your third party. Their subprocessor is your fourth party. The data in the subprocessor's infrastructure is your data. The breach notification obligation when the subprocessor is breached is your obligation. The regulatory examination that follows is your examination. Vendor contractual responsibility for subprocessors allocates liability between you and the vendor. It does not change your regulatory position. Request the subprocessor inventory. Review the security credentials. Validate the DPA chain. Confirm the notification timeline. The fourth-party risk does not disappear because the vendor is contractually responsible for it.

More on Compliance

• Assurance vs Validation
• Audit Evidence Quality
• Audit Scope Limitations