Every continuity plan has a page it does not like to read: the one listing what arrives from outside. The platforms, the processors, the sole-source components, the cloud regions — your resilience ends exactly where your most fragile critical dependency ends, and most organizations cannot name that dependency, let alone its suppliers’ suppliers. This hub page is the discipline that fixes that: supply chain risk mapping and third-party risk management (TPRM) as one practice — how to inventory what you depend on, tier it by consequence, run diligence proportionate to the tier, and read the evidence vendors hand you like a buyer instead of a fan.
Start with the map: tiers are about consequence, not spend
Tier your dependencies by what breaks when they do. Tier 1 is whatever can stop a critical process inside its recovery window: the core platform, the identity provider, the payment processor, the single plant that makes the part. Tier 2 supports critical work with workarounds that hurt. Tier 3 is everything else — important, replaceable, survivable. The industry habit of tiering by contract value misleads: the $400-a-month service your authentication flows through is Tier 1, and the seven-figure facilities contract may be Tier 2. Map beneath the vendor, too — the fourth parties. Your Tier 1 vendor’s own critical suppliers, hosting regions, and subprocessors are part of your risk whether or not your contract mentions them, a lesson the October 2026 IDCF cloud outage taught hundreds of companies at once: this hub’s six checks after the IDCF outage is the field version of that lesson.
Concentration risk: the pattern the map exists to reveal
Concentration is invisible until you draw it. Three unrelated vendors turn out to host in the same cloud region. The two “independent” suppliers both buy from the same upstream manufacturer. Every critical process routes through one identity platform, one network carrier, one logistics hub. Single-source dependencies are sometimes rational — the only qualified maker, the platform the industry standardized on — but they must be chosen with eyes open, priced for their fragility, and given a rehearsed answer to the question this hub poses elsewhere: your plan names the vendor — has it ever survived the vendor failing? Where no alternate exists, the mitigation moves inside: buffer stock, escrowed configurations, contractual exit assistance, and a recovery objective that honestly assumes the dependency is simply gone.
The TPRM lifecycle, run as a program
Inventory. You cannot tier what you have not listed. Harvest the vendor list from accounts payable, contract files, and — the step everyone skips — the technology estate itself, where shadow services live on departmental cards. Assess. Score each vendor against the tiering: criticality of the process it touches, the data it holds, the access it has into your systems, and the substitutability of the service. Diligence. Proportionate to tier: questionnaires and evidence for Tier 1, attestations for Tier 2, a contract review for Tier 3. Contract. Put the continuity terms in writing while you have leverage — incident notification windows, recovery objectives, audit and evidence rights, subprocessor disclosure, exit assistance and data return. Monitor. Diligence decays; refresh on a cycle and on triggers (incidents, acquisitions, financial distress). Exit. Every Tier 1 relationship should have a documented way out, however theoretical — the time to discover a vendor is irreplaceable is during planning, not during their outage.
Reading a SOC 2 like a buyer
A SOC 2 report is evidence, and evidence has grades. Type I describes the design of controls at a point in time; Type II tests whether those controls operated over a period — typically three to twelve months — and is the one a Tier 1 relationship should produce. Read past the cover: check the period covered (a report ending fourteen months ago describes a company that may no longer exist), the scope (which systems and locations the audit actually included), the Trust Services Criteria covered (security is mandatory in practice; availability and confidentiality are the ones continuity buyers should look for), and the exceptions — the deviations the auditor found, listed in the testing section, with management’s responses. Then read the complementary user entity controls: the section quietly assigning half the control environment to you. A vendor that will not share a current Type II under NDA for a Tier 1 service has given you diligence information too — file it accordingly.
What good looks like
A mapped, tiered, evidenced vendor estate. You can produce, on request: the Tier 1 list with owners on your side; each Tier 1 vendor’s current evidence and the date it expires; the concentration picture — shared regions, shared upstreams, shared platforms; the contract terms that will govern the worst week; and the recovery assumptions your own plans make about each of them, tested at least at tabletop. That is the whole discipline. It is less glamorous than the platforms sold to automate it, and unlike them, it works — because the map, the tiers, and the questions are the substance; everything else is filing.
Related: when the third-party failure is a cyber incident, the playbook changes — see Supply Chain Cybersecurity: When the Vendor Incident Becomes Your Outage, including the replacement lead-time analysis that belongs in the business impact assessment.
Frequently asked questions
What is third-party risk management (TPRM)?
The program that inventories an organization’s vendors and service providers, tiers them by the damage their failure or compromise would cause, runs diligence proportionate to that tier, writes continuity terms into contracts, monitors for change, and maintains exit paths. Supply chain risk mapping is its analytical core — the same discipline applied to physical and digital dependencies alike.
What is concentration risk in a supply chain?
The exposure created when multiple dependencies quietly converge on one point — a single supplier, region, platform, or upstream manufacturer — so that one failure takes out what looked like diversified arrangements. It is found by mapping fourth parties and shared infrastructure, not by reading vendor lists.
What should we ask a critical vendor for as diligence evidence?
A current SOC 2 Type II report (or ISO 27001 certificate with its statement of applicability), their own continuity and recovery test summaries, incident notification commitments, subprocessor lists, and the recovery objectives they will contract to. Proportionality applies: the full set is for Tier 1 relationships.
How often should vendor diligence be refreshed?
On a cycle matched to tier — annually for Tier 1 is the convention — and immediately on triggers: a vendor incident, an acquisition, a change of subprocessor, financial distress signals, or a material change in what the vendor does for you. Evidence has an expiry date whether or not it is printed on it.