Fourth-Party Risk Management: How SaaS and HealthTech Teams Map and Monitor Their Vendors' Vendors

Short answer: Fourth-party risk management is the practice of identifying and overseeing the vendors your vendors rely on, such as their cloud hosts, subprocessors and PHI subcontractors. You do it through your direct vendors: request their subprocessor lists, map which fourth parties touch your data, flow down contract terms, and watch for changes and shared dependencies.

Related guides:

• TPRM lifecycle: the 5 stages of third-party risk management
• Vendor tiering model
• Understanding third-party risk: everything you need to know

Key takeaways

• You rarely have a contract with a fourth party, so you manage fourth-party risk through your third parties: their subprocessor lists, their SOC reports and the terms you flow down to them.
• Focus only on fourth parties that store, process or keep running your critical services. Mapping every vendor of every vendor is not realistic for an SMB, and neither SOC 2 nor ISO 27001 asks for it.
• HIPAA and GDPR both put written flow-down obligations on the chain. A missing subcontractor BAA or an unannounced GDPR subprocessor is a compliance gap, not just a risk.
• The most common hidden exposure is concentration: several of your vendors quietly depending on the same cloud region, identity provider or payment processor.
• SOC 2 and ISO 27001 auditors want evidence of a repeatable process, such as a reviewed subprocessor inventory and documented review of carved-out subservice organizations.

---

What is fourth-party risk management?

Fourth-party risk management is the extension of your vendor risk program to cover the suppliers your direct vendors depend on to deliver their service to you. A third party is any vendor you contract with directly. A fourth party is a vendor of that vendor. Beyond that, people talk about nth-party risk, meaning any supplier further down the chain.

For example, you sign with a customer support platform (third party). It hosts on a major cloud provider, uses an email delivery service and sends ticket text to an AI model provider (fourth parties). If any of those fail or leak data, your customers feel it, even though you never chose them.

The goal is not full due diligence on every fourth party. It is to know which ones matter, confirm your vendor manages them, and react quickly when something changes.

Third-party vs fourth-party risk: what is different?

The main difference is leverage: you can assess and contract with a third party directly, but you can only influence a fourth party through the vendor in between. That changes how you collect evidence and what you can realistically require.

Dimension	Third-party risk	Fourth-party risk
Relationship	Direct contract between you and the vendor	No contract with you; governed by your vendor's contract
Visibility	Questionnaires, SOC reports, security reviews you request	Subprocessor lists, vendor SOC reports, vendor disclosures
Assessment method	You assess the vendor yourself	You assess how your vendor manages its own vendors
Contract leverage	Direct security, breach and audit clauses	Flow-down clauses, notice of changes, right to object
Typical evidence	Completed questionnaire, SOC 2 report, signed DPA or BAA	Current subprocessor list, carve-out section of the vendor's SOC 2, subcontractor BAA confirmation
Main failure mode	Weak controls at the vendor	Unknown dependencies, silent subprocessor changes, shared single points of failure
Who owns it	Your vendor risk owner	Your vendor risk owner, relying on each vendor's own program

Where do fourth parties hide in a SaaS or HealthTech stack?

Fourth parties usually sit in four places: infrastructure, data processing, embedded services and support tooling. Knowing where to look makes the mapping exercise much faster.

• Cloud and hosting providers. Almost every SaaS vendor you use runs on one of a small number of hyperscale cloud platforms. If your own product also runs there, an outage in one region can hit you and several vendors at once.
• GDPR subprocessors. Any vendor acting as your processor that passes personal data to another processor has a subprocessor. Under GDPR, that onward engagement needs your written authorization, either specific or general, and the same data protection obligations must flow down.
• PHI subcontractors. Under HIPAA, a business associate that lets a subcontractor create, receive, maintain or transmit PHI on its behalf must have a business associate agreement with that subcontractor. Your EHR integration partner's hosting provider, backup service and support desk may all be in scope.
• AI and analytics providers. Vendors increasingly route your data to model providers, analytics platforms or enrichment services. These are fourth parties even when they are buried in a feature release note.
• Identity, payments and communications. Authentication providers, payment processors and SMS or email gateways are often shared by many of your vendors, which is where concentration risk builds up.

HealthTech teams should pay special attention to the PHI path. Our guide to HIPAA third-party risk requirements covers your direct BAA obligations; the fourth-party question is whether each of those business associates has its own downstream BAAs in place.

How do you map and monitor fourth parties? A 6-step process

Start from your highest-risk vendors, collect their subprocessor information, map it to your data and services, and set triggers for change. This process works for a team of one or two people.

1. Pick the vendors that matter. Use your existing tiers. Only your critical and high tiers, usually vendors that hold sensitive data or keep your product running, need fourth-party mapping. If you do not have tiers yet, set them up first using the tiering guide linked above.
2. Collect each vendor's fourth-party information. Ask for the current subprocessor list (most vendors publish one on a trust page), the subservice organizations named in their SOC 2 report, and confirmation of downstream BAAs or GDPR flow-down terms where relevant.
3. Map fourth parties to your data and services. For each fourth party, record what of yours it touches (personal data, PHI, production uptime, none), its location and its role. A simple table with vendor, fourth party, data type, region and function is enough.
4. Look for shared dependencies. Sort the map by fourth party. If the same cloud region, identity provider or payment processor appears under several critical vendors, record it as a concentration risk and check whether your continuity plan covers it. Our guide to vendor concentration risk explains how to evaluate and reduce it.
5. Score and decide. Fold fourth-party findings into each vendor's risk rating rather than scoring fourth parties separately. A vendor with an undisclosed PHI subcontractor or a subprocessor in an unexpected jurisdiction should score higher. See how to determine vendor risk scores for a practical scoring method.
6. Monitor for change. Subscribe to subprocessor change notifications, note the objection window in each DPA, and recheck the map at each vendor's periodic review. Also trigger an ad hoc review when a widely used fourth party has a public breach or outage.

Fourth-party mapping checklist

• Critical and high-tier vendors identified
• Current subprocessor list on file for each, with the date collected
• SOC 2 subservice organizations and carve-outs noted
• Downstream BAA confirmation for every vendor that handles PHI
• GDPR subprocessor notifications subscribed and objection windows tracked
• Shared dependencies flagged and reviewed against your continuity plan
• Fourth-party findings reflected in vendor risk ratings

Which contract clauses give you fourth-party visibility?

The clauses that matter most are disclosure, notice of change, flow-down and liability. Since you cannot sign with a fourth party, your contract with the third party is the only lever you have. Look for or negotiate:

• Subprocessor disclosure. The vendor maintains and shares an up-to-date list of subprocessors, including their function and location.
• Advance notice and right to object. The vendor tells you before adding or replacing a subprocessor and gives you a reasonable window to object. GDPR requires this mechanism when you give general written authorization to a processor.
• Flow-down of obligations. The vendor imposes security, confidentiality and data protection terms on its subprocessors that are at least as protective as the ones it agreed with you. For PHI, this means a subcontractor BAA.
• Vendor accountability. The vendor stays responsible for the acts and omissions of its subprocessors, so you are not left chasing a company you have no contract with.
• Breach notification that covers the chain. The vendor must notify you of incidents at its subprocessors that affect your data, within a defined timeframe.
• Data location and transfer terms. Where fourth parties are outside your required regions, the contract states the transfer mechanism and any restrictions.
• Audit and assurance rights. You can request evidence, such as the vendor's own SOC 2 or ISO 27001 certificate, showing how it oversees its suppliers.

If you cannot redline a large vendor's paper, review its standard DPA and BAA against this list, record gaps as accepted risks with an owner, and revisit them at renewal.

What do SOC 2 auditors, ISO 27001 auditors and enterprise buyers expect?

All three groups expect a documented, repeatable way of knowing which fourth parties matter and confirming they are overseen, not a perfect map of your entire supply chain.

SOC 2. The Trust Services Criteria expect you to assess and manage risks from vendors and business partners. In practice, auditors look at how you handle the subservice organizations in your vendors' reports. When a vendor uses the carve-out method, its report excludes the subservice organization's controls, so you should review the complementary subservice organization controls it lists and confirm those fourth parties are covered somewhere, for example by their own SOC reports. Your own SOC 2 report will also describe your subservice organizations, so your customers apply the same logic to you.

ISO 27001. The 2022 version of Annex A includes supplier relationship controls, including one specifically for managing information security in the ICT supply chain and one for monitoring and change management of supplier services. Auditors typically want to see that your supplier agreements address onward suppliers and that you review changes to them.

Enterprise and healthcare buyers. Security questionnaires from larger customers increasingly ask for your subprocessor list, where data is hosted, how you are notified of subprocessor changes, and whether your PHI subcontractors have signed BAAs. Health systems often want the downstream BAA chain confirmed before go-live. A current list and a short process description shorten these reviews.

Keep fourth-party review inside each vendor's onboarding, periodic review and offboarding rather than running it as a separate project.

How SecureSlate helps

SecureSlate gives SMB SaaS and HealthTech teams one place to run vendor risk management. You can record each vendor's subprocessors in your vendor inventory, keep due diligence such as DPAs, BAAs and SOC reports alongside it, and keep your subprocessor disclosures current. Policy templates help you document your supplier and subprocessor process, continuous control monitoring and evidence collection keep it audit-ready, and multi-framework mapping links the same work to SOC 2, ISO 27001, HIPAA and GDPR. A trust center lets you publish your own subprocessor list for customers.

Start your free SecureSlate trial

FAQ

What is an example of fourth-party risk?

Your payroll software vendor hosts its platform with a cloud provider and uses a separate document storage service. If that storage service is breached, your employees' data is exposed even though you never contracted with it. That storage service is a fourth party, and the exposure is fourth-party risk.

Is a subprocessor the same as a fourth party?

Usually, yes. A subprocessor is a fourth party that processes personal data on behalf of your processor. The term comes from data protection law such as GDPR. Not every fourth party is a subprocessor, because some, such as a vendor's office software supplier, never touch your data.

Do I need a BAA with my vendor's subcontractors?

If you are a HealthTech SaaS vendor handling PHI, you are usually the business associate, and yes: HIPAA requires you to have a BAA with each subcontractor that creates, receives, maintains or transmits PHI on your behalf. Your customers, in turn, will ask you to confirm that chain. If you are the covered entity, you sign a BAA with your direct business associate, and that business associate must have its own BAAs with its subcontractors. Your job is to confirm those downstream agreements exist, typically by asking the vendor in writing.

How far down the supply chain should an SMB go?

For most SMBs, one level beyond your critical vendors is enough, plus any shared dependency that could take down several vendors at once. Go deeper only when a specific risk, regulation or customer contract requires it.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.