Put each service in one of three tiers based on exposure, data sensitivity and business impact, then set fix deadlines per tier and per severity. A single company wide deadline makes the critical systems wait behind trivial ones and burns trust. Tiering takes an afternoon and prevents most arguments later.
Why tiering comes first
When a thousand findings arrive, the question is not "how severe is this CVE" alone. It is "how severe, in which service". A high severity library issue in an internal batch job and in a public login service are not the same urgency. Tiers capture that context once, so you do not rediscover it for every finding.
A three tier model
| Tier | Typical members | Test |
|---|---|---|
| 1 | Internet facing, handles customer or payment data, revenue critical | An outage or breach is a company event |
| 2 | Internal production services, partner facing with limited data | Hurts a team or a customer segment |
| 3 | Tools, experiments, deprecated services | Low impact, often replaceable |
Use three questions to place a service.
- Can an outsider reach it?
- Does it hold data we would have to disclose if lost?
- Would customers notice within a day if it stopped?
Two or three yeses means tier 1. One means tier 2. None means tier 3.
Turn tiers into deadlines
Build a matrix and agree it with engineering leads before you publish it. Here is the shape, with blanks for your own numbers.
| Severity | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Known exploited | set a short window | set a short window | next cycle |
| Critical | |||
| High | |||
| Medium |
CISA describes its Known Exploited Vulnerabilities catalog as the authoritative source of vulnerabilities exploited in the wild. Many teams treat a KEV listing as an automatic upgrade to the shortest window, in any tier. That is a policy choice, so decide it explicitly.
Where the tier is stored
Keep the tier next to the owner in your catalog or service inventory, so scanners and dashboards can read it. If tier lives only in a slide, it will not be applied.
Review and exceptions
Review tiers when a service changes exposure, such as moving from internal to public. Allow exceptions with an owner, a reason and an expiry date. An exception with no expiry is a permanent decision made by accident.
Quick check
Who decides a service's tier?
The service owner proposes it and a security lead approves it, using the same three questions for everyone.
Should every tier get the same deadline for known exploited issues?
That is a policy choice. Many teams use their shortest window for all tiers, and relax it only for tier 3.
Safeguard's policies and gates can encode severity and exposure rules, and a free scan shows findings on one project.
Sources
Last reviewed: 19 October 2026.
