To find what you cannot run without, ask one question of each vendor and library: what stops, and how fast, if it is gone for a day? Group the answers into three tiers and spend your continuity effort on the first tier. An up to date inventory makes the exercise quick.
The method in four steps
- Build the list. Include cloud and hosting, identity, source control, CI, registries, DNS and certificates, payments, email, monitoring, support tools, plus the libraries and base images your product ships.
- For each entry, write what stops if it is unavailable for a day. Be specific: customers cannot log in, we cannot deploy, we cannot send invoices.
- Write how quickly the effect appears: immediately, within hours, or after days.
- Note whether a substitute exists and how long a switch would take.
Then sort.
| Tier | Definition | Example effects | Typical response |
|---|---|---|---|
| 1 | Customer facing function stops within hours | Login, payments, core hosting | Documented fallback, rehearsed, owner named |
| 2 | Internal work stops, customers feel it later | CI, source control, support desk | Workaround written down, tested once a year |
| 3 | Inconvenient, easy to replace | Convenience tools | A note |
A worked table
This table uses made up entries to show the format.
| Dependency | What stops in a day | How fast | Substitute | Tier |
|---|---|---|---|---|
| Identity provider | Users cannot sign in | Immediately | Break-glass admin path, no user fallback | 1 |
| Package registry | New builds fail | Within hours | Cache or mirror | 2 |
| Chat tool | Team coordination is slower | Immediately | Phone tree | 2 |
| Charting library | A dashboard looks wrong | Next release | Pin an older version | 3 |
Libraries count too
A library is a supplier in the same way a vendor is. A library with one maintainer and no alternatives is a continuity question for the code you ship. You can find out what you depend on, directly and through other packages, from an inventory generated from your build files or SBOM. Our posts on single points of failure in open source and a rotating dependency owner role help once you have the list.
Safeguard's SBOM and dependency scanning builds this inventory from your repositories, and you can try a free scan at gold.safeguard.sh/scan.
Keeping the list alive
Add an owner for each Tier 1 entry and a review date. Revisit the list when you adopt a new vendor, and when a contract ends. Tie the review to your existing change process so it does not depend on memory.
A worked example: scoring twelve dependencies
This example is hypothetical. A company of forty people lists its dependencies and scores each on three questions: how quickly customers would feel its loss, how hard it is to replace, and whether a workaround exists.
| Dependency | Customers feel it in | Replacement effort | Workaround | Tier |
|---|---|---|---|---|
| Cloud hosting account | Minutes | Months | None practical | 1 |
| Identity provider | Minutes | Weeks | Break-glass admin access | 1 |
| Payment processor | Minutes | Weeks | Queue orders, collect later | 1 |
| DNS provider | Minutes | Days | Second provider, if set up | 1 |
| Email delivery service | Hours | Days | Secondary sender | 2 |
| Source control host | Hours (fixes blocked) | Weeks | Mirror | 2 |
| CI service | Hours (releases blocked) | Days | Spare runner | 2 |
| Package registry | Hours (builds blocked) | Days | Cache or mirror | 2 |
| Logging service | Days | Days | Local logs | 2 |
| Chat tool | Immediate, internal | Days | Phone tree | 2 |
| Design tool | Days | Days | None needed | 3 |
| Charting library | Next release | Hours | Pin an older version | 3 |
Four items are in the first tier, so the team writes a one page fallback for each. Seven in the second tier get a paragraph in the runbook. The rest are noted and left alone. The whole exercise took an afternoon, and it gave leadership a list to approve.
Step by step: running it with your team
- Gather the people who know. Finance knows what you pay for, engineering knows what is wired in, and support knows what customers notice.
- Build the list from several sources: the accounts payable ledger, the single sign-on app list, your cloud console and your build files. Each reveals things the others miss.
- Score each item using the three questions above. Keep the debate short.
- Assign tiers, then assign an owner to each Tier 1 item.
- For each Tier 1 item, write the fallback, who triggers it and how long it takes to switch. If no fallback exists, say so and write what you would tell customers.
- Share the result with leadership so that gaps are an accepted decision, not a surprise.
- Put a review on the calendar, and repeat after any major vendor change.
Questions to put to the vendor
For Tier 1 vendors, ask how they communicate incidents, where their status information lives, whether they publish post-incident reports, how you can export your data and what the process is for leaving. Our post on an exit plan before you adopt a library applies the same thinking to code. Keep the answers with the tier list.
Libraries and the shape of the tail
Among libraries, a few components usually carry most of the risk. Look for those with a single maintainer, those that are no longer updated, and those with no practical alternative. Our post on open source single points of failure provides a checklist. You do not need to treat every package as Tier 1. Treat the few that would stop your product as you would a critical vendor.
Try it yourself
Open the dependency inventory demo and look at how direct and transitive components are listed. Pick one component and ask the tier question about it.
Click through it at your own pace, or open it full screen.
Quick check
How many tiers do I need?
Three is enough for most teams. More tiers add debate without changing what you do.
Should I plan a substitute for every Tier 1 item?
Not always. Some have no practical substitute. For those, the plan is a fallback behavior and a clear message to customers.
How often should the tier list be updated?
Review it twice a year and whenever you add or drop a major vendor. Link the review to procurement so new vendors get a tier at the start.
Last reviewed: 19 October 2026.
