When a TPRM program tiers vendors, the default rubric is usually annual spend. Tier one is anyone over a million dollars a year, tier two is anyone over a hundred thousand, tier three is everything else. This is convenient because procurement already tracks spend, and it gives the program a defensible-sounding criterion. It is also wrong in a way that has hurt almost every organization that has had a third-party incident in the last decade.
Spend correlates with risk only loosely. The most expensive vendors are usually the most strategic, but they are also usually the most mature, the most audited, and the most resilient. The vendors that have caused the worst incidents are often small, cheap, and embedded so deeply in critical paths that nobody noticed they were a single point of failure until they failed. SolarWinds was not a million-dollar vendor for most of its customers. The MOVEit file transfer software that became the vector for the Cl0p ransomware campaigns was not in the top fifty spend categories at most affected organizations. A $40,000-per-year API provider can take down a critical product if its API is the load-bearing component of your authentication flow.
Tiering by blast radius fixes this. Blast radius asks the right question: if this vendor were compromised, unavailable, or hostile tomorrow, how bad would it be? The answer is not always correlated with how much you pay them.
Defining Blast Radius
Blast radius is a function of four variables. The first is data exposure: what data does the vendor have, in what classification, in what volume. A vendor with read access to your customer PII has a different blast radius than a vendor that processes anonymized analytics. The first can land you in the news. The second probably cannot.
The second variable is system criticality: where does the vendor sit in your business processes. A vendor whose outage takes down the checkout flow has a different blast radius than a vendor whose outage takes down an internal reporting dashboard. The internal dashboard has a workaround. The checkout flow loses revenue per minute.
The third variable is integration depth: how easy is it to remove the vendor. A vendor that can be swapped out in a week has a different blast radius than one that has been integrated into your data model so deeply that swapping out would take a year. The latter is a hostage situation. Even a low-criticality vendor becomes high blast radius if the cost of escape is prohibitive.
The fourth variable is trust scope: what privileges does the vendor have. A vendor with write access to your production database has a different blast radius than one with read-only access to a sanitized data lake. A vendor whose code runs in your build pipeline (a CI provider, a code-signing service) has nearly unlimited blast radius because they can inject artifacts that you will then sign and ship.
A blast radius score combines these four variables. It does not require precision to be useful. A 1-to-5 score on each, with weighting for the highest variable, is enough to separate the vendors who could end your week from the vendors who could not.
Where Spend Misleads You
Two common patterns expose the failure mode of spend-based tiering. The first is the infrastructure tax pattern. Critical infrastructure providers (DNS providers, certificate authorities, package registries, container registries, dependency mirrors) are often cheap. Some are free. Their blast radius is enormous because everything you ship passes through them. A spend-based tier puts them in tier three or off the list entirely. A blast radius tier puts them in tier one because they are the kind of dependency that, if compromised, can pivot into your entire fleet.
The second pattern is the niche specialist pattern. A small vendor with a specialized product (a tax calculation engine, a fraud detection model, a content moderation pipeline) may be cheap to license but irreplaceable in your stack because nothing else does what they do. If they fail, you cannot ship that feature. If they are compromised, you have shipped their compromise to your customers. Spend-based tiering puts them in the bottom tier because the line item is small. Blast radius tiering surfaces them as critical.
The Tiering Rubric We Use
The blast radius rubric we recommend has four tiers, with explicit criteria.
Tier zero: existential vendors. Vendors whose compromise or extended outage could threaten the survival of the business. Cloud infrastructure providers, payment processors, identity providers, and code-signing services usually live here. Tier zero gets the full TPRM treatment: continuous monitoring, SBOM ingest, contract review with security clauses, quarterly business reviews, joint incident playbooks, and a documented continuity plan.
Tier one: critical vendors. Vendors whose compromise would cause significant business disruption, regulatory exposure, or customer impact, but not existential threat. Most of your customer-facing SaaS providers, your data warehouse, your CRM, and your communication platforms live here. Tier one gets continuous monitoring, SBOM ingest, annual deep review, and contractual security requirements.
Tier two: standard vendors. Vendors with meaningful risk but contained blast radius. Internal tooling, productivity software, and most analytics providers live here. Tier two gets standard onboarding due diligence, periodic monitoring, and annual review.
Tier three: low-risk vendors. Vendors with minimal data access, no system criticality, and easy replaceability. Most procurement-only relationships live here. Tier three gets baseline onboarding and monitoring for major events only (breach disclosure, M&A, public security incident).
How Safeguard's TPRM Module Operationalizes This
Safeguard's TPRM module supports blast radius tiering directly. During vendor onboarding, the module asks four structured questions corresponding to the four variables above, calculates a blast radius score, and assigns a tier. The tier determines the depth of evidence required, the monitoring cadence, and the alert thresholds.
The module also re-evaluates blast radius continuously. If the vendor's data access changes (the integration is expanded, new datasets are connected), the score recalculates and the tier may shift. If the vendor's system criticality changes (the product they provide becomes load-bearing for a new business process), the score recalculates. The tier is not a one-time judgment. It is a live assessment that should change as the relationship evolves.
The SBOM ingest is tier-aware. Tier zero and tier one vendors have their SBOMs continuously evaluated. Tier two vendors have their SBOMs evaluated weekly. Tier three vendors have SBOM ingest as optional. This is what makes the tiering useful in practice: the depth of monitoring matches the blast radius, so the team's attention is allocated where it actually matters.
The Conversation With Procurement
Procurement teams sometimes resist blast radius tiering because it complicates their workflow. The pushback is usually some version of "we have always tiered by spend; can you just use our existing categorization." The honest answer is no, because their existing categorization will route low-spend, high-blast-radius vendors into low-touch processes that miss the actual risk.
The compromise that works is to keep the procurement tiering for procurement purposes and run a parallel security tiering for TPRM purposes. The two views can coexist. Procurement cares about contract negotiation effort and approval routing. Security cares about how bad it gets when the vendor breaks. Those are different questions, and they deserve different answers. Pretending they are the same question is how the cheap vendors who hold the keys to the kingdom keep getting under-monitored.