Set three tiers: Tier 1 for systems whose failure stops revenue, safety or legal operation; Tier 2 for systems that hurt when down but have a workaround; Tier 3 for everything else. Assign them together with the business owner, and let the tier shorten or lengthen the time allowed to fix.
What business criticality means
Business criticality is how much the organization suffers when an asset is compromised or unavailable. It is not the same as technical severity. A severe flaw in a lab server can matter less than a moderate flaw in the system that issues invoices.
The CVSS v4.0 specification says the Environmental group includes the relative importance of a vulnerable system within a technical infrastructure. CISA's SSVC model asks similar questions in other words, using mission prevalence and public well-being impact as decision values. Both point the same way: importance is a property of your environment, so your team has to supply it.
A three tier model
| Tier | Test | Examples |
|---|---|---|
| 1 | If it is down or breached for a day, we lose revenue, break a safety duty or stop a regulated process | Checkout, authentication, core data store |
| 2 | Staff or customers are hurt but can work around it | Reporting, internal admin tools |
| 3 | Few people would notice for a week | Prototypes, demo sites, retired apps |
Keep the test wording short and concrete. A tier called High is an argument waiting to happen. A tier defined by a one day outage is easier to apply.
Getting the business to answer
Security teams should not decide criticality alone, and business teams should not be asked to rate hundreds of services.
- Ask for the top ten processes that make money or keep the company legal.
- Map each process to the systems that run it.
- Mark those Tier 1.
- Ask each engineering lead to nominate Tier 2 systems, and review the list once.
- Default the rest to Tier 3, with a note that anyone may argue for a higher tier.
Name an approver for each Tier 1 system. When a fix could cause downtime, that person decides the window.
What the tier changes
The tier should alter response time and the approval path, not just a label.
- Tier 1: shortest fix window, security can request an emergency change.
- Tier 2: standard window.
- Tier 3: longer window, batched updates.
Do not publish numbers here as a rule for every company. Set windows that your teams have actually met in the past, then tighten them. A policy nobody can meet teaches people to ignore it.
Pitfalls
- Everything becomes Tier 1. Cap Tier 1 at a small share of your estate and review it quarterly.
- Tiers go stale after reorganizations or retirements.
- Shared platforms inherit the highest tier of anything that depends on them. A logging pipeline that feeds fraud detection is more than a logging pipeline.
- Tier alone should not excuse an exploited flaw. Combine it with exploit evidence.
Writing it down
Store the tier in the same place as the owner and the environment. A finding with no tier should default to Tier 2 until someone decides, so that nothing is quietly deprioritized.
Where Safeguard fits
Safeguard provides asset discovery, vulnerability management and policies, so a tier you record can drive which findings a gate stops. Autonomous fix pull requests are off by default, with every category on Manual. Safeguard also offers a free scan at gold.safeguard.sh/scan if you want to see your own dependency findings first.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a tier would change the order of the findings queue.
Quick check
How many Tier 1 systems is reasonable?
There is no fixed number. If most of the estate is Tier 1, the tier no longer helps. Aim for a short list the business can name from memory.
Who owns the tier decision?
The business owner of the process, with security advising. Security alone should not set it.
Sources
Last reviewed: 19 October 2026.
