Vendor Risk Map¶

Artifact — instantiates Dependency Exposure

Connects each external provider to the services, data, and outcomes riding on it, rates the consequence of its failure, and names an owner and a fallback — turning a vendor list into a governed risk picture.

A procurement list tells you who you pay; the Vendor Risk Map tells you what you'd lose. It takes each external provider and draws the lines forward — to the services it powers, the data that flows through it, the customer outcomes that stop if it stops — then attaches the three things that make a vendor governable rather than merely listed: a criticality rating for how much its failure would hurt, an owner accountable for the relationship, and a fallback for when it degrades or exits. Its distinguishing move is turning an outward view of contracted third parties into a prioritized, owned, backstopped portfolio. Where a supply-chain map looks upstream past your vendors and a contract review reads their terms, the vendor risk map rates the vendors themselves and decides which ones you cannot afford to depend on nakedly.

Example¶

A digital bank lists a dozen third-party providers and treats them as roughly interchangeable line items: a cloud host, a card-processing network, an identity-verification vendor, a credit-bureau feed, and an SMS one-time-passcode provider among them. The Vendor Risk Map draws each provider's forward lines and rates it. Most sort as expected — the cloud host and card network are obviously critical and already have contracts and owners.

The surprise is the SMS provider, easy to dismiss as a minor utility. Mapping its forward dependencies shows that every customer login and payment authorization relies on its one-time passcodes: if it fails, no one can sign in or approve a transaction, and there is no second passcode channel. Its blast radius rates it critical, yet it had no named owner and no backup — a single point of failure hiding behind a small invoice. The map's output is direct: assign an owner, and stand up a fallback delivery channel before the provider's next outage does it for them.

How it works¶

The map's distinctive contribution is rating and backstopping, not discovery. It assumes the vendors are known and asks the governance questions a list never does: for each provider, how bad is its failure (blast radius, data sensitivity, substitutability, concentration), who inside the organization owns the relationship, and what happens when it degrades or walks — a second provider, a manual fallback, a graceful-degradation mode, or an accepted risk. Rating is what lets scarce attention concentrate on the few vendors that could stop the business, and the owner-plus-fallback pairing is what converts "we use them" into "we can survive without them." It often looks past the direct provider to its critical sub-providers, since a vendor's own single point of failure becomes yours.

Tuning parameters¶

Criticality factors — which dimensions set a vendor's rating (blast radius, data sensitivity, substitutability, switching lead time, concentration). Different weightings surface different vendors as the ones to worry about.
Substitutability realism — how honestly "we could switch" is assessed. A provider counted as replaceable but requiring a year to migrate is effectively single-source, and rating it otherwise flatters the picture.
Fallback depth — whether critical vendors need a live second provider, a documented manual mode, or just an accepted-risk sign-off. Deeper fallbacks cost more and are reserved for the highest blast radius.
Sub-provider reach — whether the map stops at direct vendors or extends to their critical dependencies. Extending catches inherited single points of failure but widens the effort.

When it helps, and when it misleads¶

Its strength is prioritization plus accountability for third-party risk: it stops an organization from treating all vendors alike, surfaces the small-invoice provider with an outsized blast radius, and forces the owner-and-fallback discipline that makes a critical dependency survivable. It is the mechanism when outsourced services are the fragility and when the question is which providers you cannot afford to depend on without a backup.

Its failure modes are those of any rating artifact. Ratings are judgments and drift toward optimism — especially on substitutability, where "we could switch providers" quietly ignores the migration year it would actually take. A tidy map can also certify governance it hasn't earned: a critical vendor with a rating and an owner but a fallback that exists only on paper is documented, not protected. And it naturally stops at the vendors you know, missing the fourth-party concentration where several of your providers secretly rely on the same sub-provider^[1]. The discipline is to rate substitutability by real switching time, exercise the fallbacks rather than merely naming them, and extend the map to critical sub-providers where concentration is plausible.

How it implements the components¶

criticality_classification — it rates each provider by the consequence of its failure (blast radius, data sensitivity, substitutability, concentration), so attention concentrates on the vendors that could stop the business.
owner_assignment — every provider gets a named internal owner accountable for the relationship, its status, and its contingency.
contingency_or_substitution_path — for critical providers it defines the fallback: a second vendor, a manual mode, a degradation plan, or an explicit accepted risk.

It does not read the providers' contract terms and dates (Contract and SLA Review), trace physical dependencies upstream past them (Supply Chain Mapping), or watch their live status day to day (Critical Dependency Dashboard).

Instantiates: Dependency Exposure — the Vendor Risk Map applies the archetype to outsourced and third-party providers, rating and backstopping each.
Consumes: Contract and SLA Review supplies the contractual terms and exit options that inform each provider's fallback and rating.
Sibling mechanisms: Contract and SLA Review · Supply Chain Mapping · Assumption Log · Architecture Dependency Review · Critical Dependency Dashboard · Dependency Graph · Dependency Registry · Dependency Review Workshop · FMEA Dependency Table · Impact Analysis · Software Bill of Materials

Notes¶

The vendor risk map, contract review, and supply-chain map form a natural trio on external dependence: contract review reads the terms, the vendor map rates the providers and their fallbacks, and supply-chain mapping traces past them to shared upstream origins. Each answers a question the others don't; used alone, any one leaves an external blind spot.

References¶

[1] Fourth-party risk is exposure to your vendors' vendors — the sub-providers you have no relationship with but still depend on. When several of your third parties quietly rely on the same fourth party (a common cloud region, a shared identity provider), your diversified vendor portfolio hides a concentrated single point of failure. ↩