Retire first the legacy system that combines the most exposure, the most sensitive data, known exploited vulnerabilities and the highest cost to keep protected, weighed against how hard it is to replace. A short scoring table beats a debate, as long as people agree on the factors before they see the results.
Why rank at all
Budgets allow a few retirements a year. Without a method, the loudest team or the most recent scare wins. NIST's patch management guide defines the work as identifying, prioritizing, acquiring, installing and verifying patches, and it describes patching as a routine operating cost. Systems that cannot be patched still need the prioritizing step. A ranking is how you do it for them, and it keeps the cost of mitigation visible next to the cost of replacement.
Five factors
- Exposure. How many hosts can reach it, and does any path touch the internet or third parties?
- Data and function. What does it hold or control? Customer records and safety functions weigh more than a lab tool.
- Known exploitation. Does any component appear in CISA's Known Exploited Vulnerabilities catalog? CISA describes the catalog as the authoritative source of vulnerabilities exploited in the wild and advises using it as one input when prioritizing fixes.
- Support status. Is support ended, ending soon, or still available?
- Cost to keep safe. Hours per month on exceptions, monitoring, special backups and vendor negotiations.
Then weigh against a sixth: effort to replace. A system that scores high on risk and is easy to replace goes first.
A worked scoring table
Score each factor from 1 (low) to 3 (high). The numbers below are illustrative.
| System | Exposure | Data | Exploited | Support | Cost | Risk total | Replace effort | Priority |
|---|---|---|---|---|---|---|---|---|
| Old file server | 2 | 2 | 1 | 3 | 1 | 9 | Low | High |
| Plant historian | 1 | 3 | 1 | 3 | 3 | 11 | High | Plan, isolate |
| Reporting app | 3 | 2 | 3 | 3 | 2 | 13 | Medium | Highest |
The reporting app goes first, because it is reachable, has a component with known exploitation, and the replacement is manageable. The plant historian scores high but is hard to replace, so it stays isolated while a longer plan is built.
Rules for using the table
- Agree weights before scoring. Otherwise people adjust them to get the answer they want.
- Treat known exploitation as a trigger, not just a score. A KEV entry affecting an exposed legacy system should prompt immediate review of compensating controls.
- Re-score on a schedule. Exposure and support status change.
- Keep the table with the exception register. One source of truth.
What the table does not capture
Business criticality that cuts the other way: a system that looks safe to retire but supports a contract renewal next quarter. Add a column for deadlines and dependencies. The score informs the decision, people still make it.
Quick check
Should the oldest system go first?
Not necessarily. Age is a weak signal on its own. A newer system with exposure and known exploitation can be riskier than an old isolated one.
How many factors are too many?
More than six or seven and people stop scoring honestly. Keep to a few that drive decisions.
Sources
- NIST SP 800-40 Rev 4, Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
