Your vendors have vendors. The analytics tool you approved runs on a cloud provider, sends email through a delivery service, and may pass your data to an AI model provider for a feature you never switched on. Those companies are your fourth parties. You have no contract with them, you did not review them, and a failure at any of them can still reach your data.
Fourth-party risk is easy to describe and hard to manage, because your usual tools do not work on it. You cannot send a questionnaire to a company that does not know you exist, and you cannot audit a contract you are not party to.
This article covers where fourth parties show up, what the frameworks expect, the levers you actually have, and the mistakes that waste effort.
What counts as a fourth party
A fourth party is any organization your vendor relies on to deliver the service you buy. The term has no definition in the major frameworks; it is industry shorthand. Some programs extend it to "nth parties" further down the chain, but in practice the risk you can do anything about sits one level beyond your direct vendors.
Not every fourth party matters. Your vendor's office cleaning company is a fourth party in the literal sense and irrelevant to your risk. The ones that matter are those that store or process your data, or that the vendor's service cannot run without: hosting, databases, payment processing, identity, email delivery, customer support platforms, and increasingly AI model providers.
Where fourth parties show up
You rarely have to guess. Fourth parties appear in documents you are already collecting.
Sub-processor lists
Under GDPR Article 28(2), a processor may only engage another processor with the controller's prior specific or general written authorization. Where the authorization is general, the processor has to inform the controller of intended changes and give the controller the opportunity to object. This is why most vendors that process personal data publish a sub-processor list and offer change notifications.
Article 28(4) adds that the same data protection obligations must flow down to the sub-processor by contract, and that the original processor remains fully liable to the controller for the sub-processor's performance.
SOC 2 subservice organizations
A vendor's SOC 2 report names its subservice organizations: the providers whose controls the vendor depends on to meet its commitments. Under the carve-out method, the most common choice, the subservice organization's controls are excluded from the auditor's testing. The report lists the controls the vendor expects the subservice organization to operate, and the vendor's own controls for monitoring it.
Read that section closely. A carved-out subservice organization is a fourth party your vendor's report does not cover. You need to know which ones handle your data, and what the vendor does to oversee them.
Contracts and documentation
Data processing agreements, security pages, architecture documentation and questionnaire answers often name hosting providers and key dependencies. Collect them during due diligence rather than reconstructing them later.
What the frameworks expect
Most frameworks address fourth parties indirectly, through what they expect of your vendor management.
GDPR makes the sub-processor chain explicit, as above. If you are a processor yourself, your own customers will expect the same notice and objection rights from you. The GDPR framework page covers the processor obligations.
ISO/IEC 27001:2022 Annex A control 5.21 covers managing information security risks in the ICT products and services supply chain. It is the control auditors associate most closely with fourth-party risk.
SOC 2 brings subservice organizations into the system description, and CC9.2 covers vendor risk. If your own report carves out a provider, your auditor will expect controls for monitoring it.
DORA addresses subcontracting for financial entities in its ICT third-party risk provisions, including the conditions under which ICT services supporting critical or important functions may be subcontracted. The DORA framework page covers the scope.
NIST SP 800-161 Rev. 1 provides guidance on cybersecurity supply chain risk management for organizations that want a fuller treatment.
The levers you actually have
You cannot manage a fourth party directly. You can manage your vendor's management of it. Five levers carry most of the weight.
Assess your vendor's vendor management. Ask how the vendor reviews its own critical vendors, how often, and against what. A vendor with a defined process for its suppliers is a better risk than one without, whatever its own controls look like.
Identify the critical fourth parties for your top-tier vendors. For each tier one vendor, list the fourth parties that hold your data or that the service depends on. It is usually a short list. You do not need the full list for every vendor. For each critical fourth party, record its role, the data it handles, where it operates, and whether the vendor's SOC 2 report includes it or carves it out. That short record is what you check when a change notice or an outage report arrives.
Secure notice and objection in the contract. For personal data, GDPR gives you this through the processing agreement. For other data, negotiate it. Notice of a new sub-processor is worth little if you only find out after your data has moved.
Require flow-down. The contract should oblige the vendor to impose security and confidentiality terms on its sub-processors at least as strong as those it owes you.
Watch for changes. Subscribe to sub-processor change notices, and treat a new critical fourth party as a trigger for a short reassessment.
Questions to ask a vendor
These questions fit into due diligence or an annual reassessment:
Which sub-processors or subservice organizations will store, process or have access to our data?
Which of them, if unavailable, would stop your service from working?
How do you assess those providers before engagement and on an ongoing basis?
How do you notify customers of changes, and how much notice do you give?
What security terms do your contracts with them include?
For carved-out subservice organizations in your SOC 2 report, which of your controls monitor them?
The answers are self-reported. Weigh them against what the vendor's SOC 2 report and processing agreement say, and note where they disagree.
Mistakes that waste effort
Questionnaires to fourth parties. They have no obligation to answer you and usually will not. Direct the effort at your vendor.
Mapping every fourth party. A complete map of every vendor's every supplier is expensive and goes stale quickly. Focus on critical fourth parties of critical vendors.
Assuming the vendor's report covers its dependencies. Under the carve-out method, it does not. Read which controls the vendor relies on others to operate.
Ignoring AI features. A vendor adding an AI capability often adds a model provider as a new sub-processor. Check the notices for it.
Treating fourth-party risk as separate. It belongs in the same register and the same review cycle as the vendor itself, recorded against that vendor.
How TrustLynce helps
TrustLynce's third-party risk module keeps your vendor inventory, tiers, reviews and reassessments in one place. Fourth-party findings from a review stay with the vendor they belong to, and come back for attention at that vendor's next reassessment.