# Fourth parties and concentration risk

> How your vendors' vendors and shared dependencies can stop your business, with public incidents, a dependency mapping method and a tabletop exercise outline.

Source: https://docs.lumina-erp.com/first-and-third-parties/fourth-parties-and-concentration-risk/

**In short.** A fourth party is a vendor your vendor relies on, and concentration risk is what happens when many of your vendors, or you and your whole industry, share the same one. You cannot manage every fourth party, but you can map which shared dependencies sit under your critical services, decide which single points of failure you will accept and rehearse a manual fallback for the rest.

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](/first-and-third-parties/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.

:::caution[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.

## Sources

- [Widespread IT Outage Due to CrowdStrike Update (CISA alert, July 19, 2024, with later updates)](https://www.cisa.gov/news-events/alerts/2024/07/19/widespread-it-outage-due-crowdstrike-update)
- [Helping our customers through the CrowdStrike outage (Microsoft, July 20, 2024)](https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/)
- [AA20-352A, Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations (CISA)](https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a)
- [ED 21-01, Mitigate SolarWinds Orion Code Compromise (CISA, December 13, 2020)](https://www.cisa.gov/news-events/directives/ed-21-01-mitigate-solarwinds-orion-code-compromise)
- [Colonial Pipeline Cyber Incident (U.S. Department of Energy)](https://www.energy.gov/ceser/colonial-pipeline-cyber-incident)
- [The Attack on Colonial Pipeline: What We've Learned and What We've Done Over the Past Two Years (CISA, May 7, 2023)](https://www.cisa.gov/news-events/news/attack-colonial-pipeline-what-weve-learned-what-weve-done-over-past-two-years)
- [Change Healthcare Cyberattack Underscores Urgent Need to Strengthen Cyber Preparedness (American Hospital Association)](https://www.aha.org/change-healthcare-cyberattack-underscores-urgent-need-strengthen-cyber-preparedness-individual-health-care-organizations-and)
- [Interagency Guidance on Third-Party Relationships: Risk Management (Federal Register, June 9, 2023)](https://www.federalregister.gov/documents/2023/06/09/2023-12340/interagency-guidance-on-third-party-relationships-risk-management)
- [Regulation (EU) 2016/679 (GDPR), Article 28 Processor (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)
- [SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (NIST)](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final)
- [CISA Tabletop Exercise Packages (CISA)](https://www.cisa.gov/resources-tools/services/cisa-tabletop-exercise-packages)

---

Epicor, Prophet 21, P21 and DynaChange are trademarks or registered trademarks of Epicor Software Corporation registered in the United States and other countries. Kinetic is a trademark of Epicor Software Corporation. Lumina ERP is an independent consultancy and is not affiliated with, sponsored by or endorsed by Epicor.