Fourth parties and concentration risk

A fourth party is a business your vendor depends on: the cloud platform under your hosted ERP, the payment gateway under your web store, the subcontractor who actually runs your 3PL night shift. Concentration risk is the related problem that appears when many of your vendors, or you and most of your industry, lean on one provider. One failure then hits everything at once.

You cannot vet every fourth party, and you should not try. What you can do is map the shared dependencies under your few critical services and name the single points of failure. Then decide in advance which ones you will accept and how you will keep shipping when one goes down.

At a glance

The terms below come up throughout this section, each with an invented distributor example.

Term	Plain meaning	Distributor example (invented)
Third party	A business you contract with directly	Your hosted ERP provider
Fourth party	A business your third party contracts with	The cloud platform and region your ERP provider runs on
Subprocessor	A fourth party that processes personal data on your vendor's behalf	The email delivery service your CRM uses to send your quotes
Shared dependency	One provider under several of your vendors	Your ERP host, EDI network and web store all run on the same cloud platform
Concentration	Too much of one function in one place	85% of your LTL volume with one carrier, or one sole-source supplier for your top line
Single point of failure	A component whose failure stops a process with no fallback	One internet circuit at the only warehouse

Why fourth parties matter

Your contract is with the third party, but the service you get depends on the chain behind it. That chain is hard to see for three reasons.

• Many software vendors change hosting, support subcontractors or data processors without telling customers unless the contract requires it.
• A vendor's SOC 2 report often carves out its cloud host, so the report does not tell you how that host performed. See security and data sharing with vendors.
• A handful of cloud platforms, payment networks, identity providers, endpoint security products and content delivery networks sit under a large share of business software. Diversifying your vendors does not diversify those.

Some rules already push on this. The 2023 interagency guidance for banks lists a third party's reliance on subcontractors among the due diligence factors. It asks banks to consider subcontractor risk in contracts and monitoring (Federal Register, June 9, 2023, retrieved 2026-09-28).

GDPR Article 28 lets a processor engage a sub-processor only with the controller's prior written authorization. It requires the processor to inform the controller of changes so the controller can object, and it holds the original processor liable for the sub-processor (EUR-Lex, retrieved 2026-09-28). Even if neither rule applies to you, both are good models for contract terms.

Not legal advice

Whether a subprocessor or subcontractor clause is required in your contracts depends on the data, the laws that apply to you and your customers' contracts. Involve counsel before relying on any template language.

What public incidents show

The events below were widely reported, and we summarize them from public government or industry sources. We describe them only to show how dependency and concentration play out. We draw no conclusion about any company's practices beyond what the cited source states.

Event	Dependency lesson
July 2024 faulty security content update	A security tool is itself a third party with deep access
2020 SolarWinds Orion compromise	A trusted vendor update became the attack path
2021 Colonial Pipeline ransomware	One operator of shared infrastructure affected many downstream businesses
2024 Change Healthcare ransomware	A clearinghouse most customers never think about sat between providers and their cash

July 2024 faulty security content update

CISA reported on July 19, 2024 that a content update to a widely used endpoint security product caused a widespread outage of Microsoft Windows hosts, and that it was not malicious activity. Microsoft estimated on July 20, 2024 that about 8.5 million Windows devices were affected, under 1% of all Windows machines (retrieved 2026-09-28).

A tiny share of devices caused wide economic disruption because the affected product was concentrated in large enterprises and critical services.

2020 SolarWinds Orion compromise

CISA Emergency Directive 21-01 (December 13, 2020) ordered federal agencies to act on a compromise of a network monitoring product. CISA Alert AA20-352A described a supply chain compromise that delivered a backdoor through the product's software (retrieved 2026-09-28).

Signed, legitimate software from a vendor can still carry risk into every customer at once.

2021 Colonial Pipeline ransomware

The U.S. Department of Energy states that on May 7, 2021 the company proactively shut down its pipeline system in response to a ransomware attack and restarted on May 13, 2021. CISA later recalled the lines at gas stations across the eastern seaboard (retrieved 2026-09-28).

Precautionary shutdowns are a real, sometimes correct, response, and your plan should assume one.

2024 Change Healthcare ransomware

The American Hospital Association describes Change Healthcare as processing 15 billion health care transactions a year, touching 1 in 3 patient records. It states that a ransomware attack on February 21, 2024 incapacitated significant portions of its functionality. An AHA survey in March 2024 of nearly 1,000 hospitals found 94% reported a financial impact (AHA, retrieved 2026-09-28).

The AHA notes that how hard each hospital was hit varied with factors including cash reserves and vendor redundancy.

The pattern for a distributor is the same at smaller scale. A payment processor, an EDI network, a tax calculation service, a cloud region or a dominant carrier can stop order-to-cash for you and your competitors on the same morning.

Where concentration hides at a distributor

Each area below tends to concentrate on one provider, and the last column shows what an outage there would stop.

Area	Typical concentration	What it would stop
Hosting and cloud	ERP, web store, EDI and CRM on the same cloud platform, sometimes the same region	Order entry, customer portals, electronic orders
Identity	One identity provider for email, ERP single sign-on and VPN	Everyone logging in to anything
Payments	One processor and gateway for cards in the web store, the ERP and the counter	Card acceptance everywhere
EDI	One value-added network for all trading partners	Orders from and invoices to your largest customers
Tax	One tax calculation service called at order entry and invoicing	Invoicing, if the ERP blocks posting without a tax result
Freight	Most LTL volume with one carrier, or one parcel carrier for all small packages	Outbound shipping
Warehousing	One 3PL, or one building with one internet circuit	Physical fulfillment
Supply	A sole-source supplier for a line that drives a large share of revenue	Sales of that line
People	One partner consultant or one internal admin who knows the integrations	Recovery itself

How to map your dependencies

You do not need special tools. A spreadsheet and a few conversations with your tier 1 vendors will do.

1. Start from processes. List the handful you cannot stop for more than a day: take an order, pick and ship, invoice, collect cash, pay suppliers, pay people.
2. List every third party each process touches. Include software, hosting, payment and tax services, networks, carriers, 3PLs and anyone with remote access.
3. Ask each tier 1 vendor for its key dependencies: hosting platform and region, payment or messaging providers, subprocessors that touch your data and critical subcontractors. Many vendors publish a subprocessor list.
4. Look for repeats. Any provider that shows up under two or more critical processes is a shared dependency, so mark it.
5. Mark single points of failure, meaning anything with no alternative and no manual workaround.
6. Record recovery expectations. For each, note the vendor's stated recovery time objective (RTO) and recovery point objective (RPO), and compare them with how long you can cope.
7. Decide whether to accept, mitigate or change, and write down the decision and the owner. Accepting a risk on purpose is a valid outcome.

Example dependency map (invented)

The map below is for an invented electrical distributor with three branches and a web store.

Process	Third parties	Shared fourth parties	Single point of failure?	Can cope for
Take web orders	Web store platform, payment gateway, tax service	Cloud platform A (web store, tax service)	Payment gateway	4 hours
Take EDI orders	EDI network, ERP host	Cloud platform A (ERP host)	EDI network	1 day
Enter counter and phone orders	ERP host, identity provider	Cloud platform A	Identity provider	2 hours
Ship	ERP host, primary LTL carrier, parcel carrier	Cloud platform A	Primary LTL carrier (80% of volume, invented)	2 days
Invoice and collect	ERP host, tax service, payment processor, bank	Cloud platform A (ERP host, tax service)	Tax service, if invoicing blocks without it	3 days

In this example, cloud platform A sits under four of five critical processes. That is not automatically wrong, since large cloud platforms often have better resilience than a small company can build. It does mean one regional outage touches almost everything, and the plan has to say what happens then.

Single points of failure and mitigations

Each common single point of failure has more than one mitigation, and each mitigation has a cost.

Single point of failure	Mitigation options	Cost and trade-off
Hosted ERP in one cloud region	Ask about multi-region recovery and tested failover; keep a daily offline export of open orders, inventory by bin and customer contacts	Multi-region adds cost, but the export is cheap and covers the first day
Identity provider	Break-glass admin accounts stored offline; local fallback accounts for the ERP where supported	Break-glass accounts need tight control and testing
Payment gateway	A second gateway configured and tested; a manual card terminal at branches	Second gateway adds fees and integration work
Tax service	Allow invoicing with a cached or default rate and a later true-up, if counsel and your tax adviser agree	Some tax exposure during the outage
EDI network	Trading partner portals or email fallback agreed in advance for top customers	Manual keying, error risk
Dominant LTL carrier	Qualified second carrier with rates loaded and a few shipments a month to keep the relationship live	Slightly higher rates on the secondary share
Sole-source supplier	Qualify an alternate for top items; hold extra safety stock on the rest	Carrying cost, and the alternate may need customer approval
Single warehouse internet circuit	Second circuit from a different provider and path, or cellular backup	Monthly cost, and you need to confirm different physical routes
One person who knows the integrations	Written runbooks and a second trained person; partner support retainer	Time to document

Manual fallbacks and runbooks

A manual fallback is the procedure your staff follow when a system is down: paper or spreadsheet orders, handwritten pick lists, a phone tree to customers, a manual card terminal. It only works if it is written down, printed and practiced. A useful runbook for each critical process has these parts:

• Trigger. Who declares the fallback and on what signal.
• First hour steps. What to stop, who to call, what to tell customers.
• Offline data. Where the last export of open orders, inventory and customer contacts lives, and how to open it without the affected system.
• Manual procedure. How to take, pick, ship and record orders by hand, with forms ready.
• Re-entry. How manual transactions are keyed back and reconciled when systems return.
• Contacts. Vendor support and escalation contacts, carrier contacts, key customer contacts, all on paper.

A tabletop exercise outline

A tabletop exercise is a structured discussion where the team walks through a scenario without touching real systems. CISA publishes free Tabletop Exercise Packages you can adapt. A 90-minute version for a mid-sized distributor runs in five segments.

Segment	Time	What happens
Set-up	10 min	Facilitator sets the rules (no blame, no real systems, decide as if it were real) and names a note-taker
Inject 1, the outage	20 min	Order entry and the web store go down on a Monday morning
Inject 2, it drags on	20 min	The outage runs into the afternoon with trucks due
Inject 3, it is a breach	20 min	The host reports ransomware and possible data access
Debrief	20 min	What worked, what was missing, which runbook or contract term to fix, owners and dates

The three injects, as the facilitator reads them out:

1. It is 7:30 a.m. Monday. Order entry and the web store are both down. The ERP host says its cloud provider has a regional outage, with no restoration time. What do you do in the first hour, and who decides?
2. It is 1 p.m. and still down. Your largest customer's EDI orders are queuing, and trucks arrive at 3 p.m. Do you ship from paper? How do you price and invoice later?
3. It is 5 p.m. The host now says the outage was a ransomware attack and data may have been accessed. What changes? Who calls counsel, the insurer and customers?

Invite operations, finance, IT, customer service and a branch manager. For a stronger exercise, add your ERP host or managed IT provider. Keep the output short: a list of gaps, each with an owner and a date.

Questions to ask your tier 1 vendors

• Which hosting platform and regions run our service, and is failover to another region tested? When was it last tested?
• Who are your subprocessors and critical subcontractors, and will you notify us before adding or changing one?
• What is your RTO and RPO for our service, and are those contractual or targets?
• Which of your own vendors could take our service down, and what is your plan for each?
• Did your SOC report carve out any subservice organization, and how do you monitor it?
• Were you affected by any widely reported outage in the last three years? What changed afterward?
• Can we take a full export of our data on demand, in a format we can open without you?

Red flags

These signs in a vendor answer or in your own setup mean a dependency is unmanaged.

Red flag	Why it matters
Vendor will not name its hosting platform or subprocessors	You cannot see shared dependencies or answer your own customers
No contractual notice of subprocessor changes	Your data can move to a new provider without your knowledge
RTO and RPO are "best effort" for a tier 1 service	Recovery is whatever happens, with no plan behind it
Every critical process shares one identity provider with no break-glass access	One outage locks everyone out of everything
Manual fallback exists only as an idea	Staff will improvise under pressure, and re-entry will be messy
Alternate carrier or supplier "qualified" years ago and never used	Rates, contacts and approvals will not work on the day you need them

Start with one process

Pick the one process that would hurt most if it stopped for a day, usually order entry or shipping. Map its third and fourth parties on one page, mark the single points of failure and write a one-page manual fallback for it. Then run a 90-minute tabletop on that process with the people who would be on the floor. Repeat for the next process each quarter.