Vulnerability Management: How to Build a Programme That Actually Reduces Risk

Every organisation has more vulnerabilities than it can fix. Tens of thousands of new CVEs are published every year, and a single scan of a mid-sized network can return thousands of findings. Vulnerability management is the continuous process of finding, prioritising, fixing and verifying weaknesses so that the ones attackers will actually use get fixed first.

The vulnerability management lifecycle

1. Asset discovery: you cannot scan what you do not know exists. Maintain an inventory covering servers, endpoints, cloud resources, network devices and internet-facing assets.
2. Assessment: authenticated scanning, agent-based scanning, cloud posture tools and periodic penetration testing.
3. Prioritisation: decide what matters most (see below).
4. Remediation: patch, reconfigure, or apply compensating controls.
5. Verification: rescan to confirm the fix worked.
6. Reporting: track trends, SLA compliance and risk over time.

Why CVSS alone is not enough

The Common Vulnerability Scoring System (CVSS) rates technical severity. Version 4.0 was published by FIRST in 2023, though many tools still show 3.1 scores. Severity is useful, but a large share of vulnerabilities rated high or critical are never exploited in the wild, while some medium-rated ones are exploited heavily. Patching strictly by CVSS wastes effort.

A risk-based approach combines three signals:

• Known exploitation: the CISA Known Exploited Vulnerabilities (KEV) catalogue lists vulnerabilities confirmed as exploited. Anything on KEV that affects you should jump to the front of the queue.
• Likelihood of exploitation: the Exploit Prediction Scoring System (EPSS), also from FIRST, estimates the probability that a vulnerability will be exploited in the next 30 days.
• Asset context: is the system internet-facing? Does it hold sensitive data? Is it Tier 0, such as a domain controller?

Set remediation SLAs

Define target fix times by risk rather than raw severity. An example policy:

• Known exploited and internet-facing: as fast as possible, typically within days.
• Critical risk: 7 to 15 days.
• High risk: 30 days.
• Medium risk: 60 to 90 days.
• Low risk: next scheduled maintenance, or accept the risk formally.

Adjust to your environment, and document exceptions with an owner, a compensating control and an expiry date.

When you cannot patch

Legacy systems, vendor-controlled appliances and critical production servers sometimes cannot be patched quickly. Use compensating controls: network isolation, disabling the vulnerable feature, a web application firewall rule, stricter access control and extra monitoring in your SIEM.

Metrics that matter

• Mean time to remediate, by risk level.
• Percentage of findings fixed within SLA.
• Number of known exploited vulnerabilities open, which ideally should be zero.
• Scan coverage: the share of assets scanned in the last 30 days.

Avoid "total vulnerabilities" as a headline metric; it rises every time you add assets or scanners and says little about risk.

Common mistakes

• Unauthenticated scans only, which miss most missing patches.
• Throwing thousands of findings at IT teams without prioritisation or ownership.
• Ignoring cloud misconfigurations, which are often riskier than missing patches. See my Azure misconfigurations guide.
• No verification scan, so "fixed" tickets are closed without proof.

Need help building or fixing a vulnerability management programme? Get in touch.

References and further reading

1. CISA Known Exploited Vulnerabilities Catalog
2. FIRST: Exploit Prediction Scoring System (EPSS)
3. FIRST: Common Vulnerability Scoring System (CVSS)
4. NIST National Vulnerability Database