Vulnerability management: how to build the process
The scanner is the easy part. How to build the full process: inventory, risk-based prioritisation, remediation SLAs and metrics that matter.
Many companies “have vulnerability management” that in practice looks like this: once a quarter someone runs a scanner, a PDF with 4,000 findings lands in the administrators’ inboxes and… that’s it. A year later the same list is longer, and the oldest items remember the previous CEO. Meanwhile the statistics are brutal: a large share of successful breaches exploit vulnerabilities whose patches existed for months. What makes the difference is not the scanner but the process — from inventory, through priorities, to enforceable remediation deadlines. Here’s how to build it.
Rule zero: you can’t fix what you can’t see
The foundation is an asset inventory: servers, endpoints, network devices, cloud, containers, applications — with owners and business criticality. Without it, the scanner examines only what it knows, and the attacker enters through what nobody knows: a forgotten subdomain, a test server, a “temporary” device. Good practice:
- the inventory refreshes automatically (network scans, cloud APIs, endpoint agents), not a manual spreadsheet,
- the external attack surface is also mapped “from the internet” regularly — what the attacker sees often differs from what the CMDB sees,
- every asset has an owner; a vulnerability without an owner never gets fixed.
Scanning: frequency and coverage
A rhythm that works in practice: internet-facing assets — scanned at least weekly (ideally continuously), the internal network and endpoints — every 2–4 weeks, plus a scan after every significant change. Scan with credentials — without them you see maybe a third of the truth. Remember the layers classic scanners miss: application dependencies (supply chain), container images, cloud configuration and your M365 tenant.
Prioritisation: CVSS is not enough
The biggest trap: sorting by raw CVSS. A 9.8 on an isolated test server can be less urgent than a 6.5 on an internet-facing payment system — we covered this in our piece on prioritising CVEs. An effective formula combines three questions:
- Is it being exploited? Sources: the CISA KEV catalogue (confirmed active exploitation), the EPSS score (exploitation probability), public exploit reports.
- Is it reachable in our environment? Internet exposure, segmentation, required authentication.
- What does the asset protect? Business criticality, data, connections to other systems.
A practical model: priority = exploitation (KEV/EPSS) × exposure × asset criticality. A simple matrix with those three axes beats any thousand-row “red report” on outcomes.
Remediation SLAs and the exception path
The process becomes real when it has deadlines agreed with system owners before the first vulnerability appears:
| Class | Example | Deadline |
|---|---|---|
| Critical, exploited (KEV), internet-facing | RCE on the VPN | 24–72 h |
| Critical/high, internet-facing | Admin panel with a known flaw | 7 days |
| High internal / medium external | Privilege escalation on a server | 30 days |
| The rest | Low, defence-in-depth | 90 days / conscious acceptance |
Equally important is the exception path: when a patch is impossible (a legacy system, a maintenance window a month away), the risk decision is made consciously — with mitigation (network isolation, WAF, strengthened monitoring), a risk owner and a review date. An exception without an expiry date isn’t an exception — it’s capitulation.
Remediation: the bottleneck is organisational
Scanning is cheap — fixing costs. Three things that unblock the flow:
- Patching automation where change risk is low (workstations, browsers, standard software): deployment rings (pilot → the rest) instead of manually approving every patch.
- Integration with team workflows: vulnerabilities arrive as tickets in the owner’s system (Jira/DevOps), not as a PDF in a mailbox. What isn’t in the backlog doesn’t exist.
- Fixing causes, not symptoms: if every scan returns the same items (old libraries in images, a vendor with no update process), the problem is the process — and fixing that should be the ticket.
Metrics that mean something
The board doesn’t need the vulnerability count (it will always be large). Report what describes risk and throughput:
- Time to remediate (MTTR) per class — especially for critical exploited ones,
- SLA compliance — what % of critical/high vulnerabilities were fixed on time,
- Exposure: the number of open KEV vulnerabilities on internet-facing assets (target: zero, measured in hours),
- Scan coverage: % of inventory assets actually scanned with credentials,
- Debt: the trend of items overdue against SLA (direction matters more than the value).
Five numbers on one slide, monthly — enough to make the programme accountable.
Where penetration testing fits
A scanner finds known vulnerabilities; it won’t find logic flaws, bad permissions or attack chains linking minor weaknesses. A mature programme therefore combines continuous scanning (breadth) with periodic penetration tests (depth) — here’s how to prepare for one. Pentest findings feed the same process: the same SLAs, the same exception path, the same backlog. For clients under ongoing care we merge both loops into one rhythm: scan → priorities → fix → retest.
Frequently asked questions (FAQ)
Which scanner should we choose? It matters less than it seems. Any reputable scanner (commercial or open source like OpenVAS) will find 90% of the same things. Choose by: coverage of your environment (cloud? containers?), credentialed scanning, ticket integrations and deduplication quality. The rest is process.
We have 4,000 open vulnerabilities. Where do we start? With the three-question filter: (1) what’s in CISA KEV and internet-facing — fix this week; (2) what’s critical on business-relevant systems — this month; (3) slice the rest by cause (e.g. “old OpenSSL everywhere” is one project, not 800 tickets). After two such cycles the list becomes manageable.
How often should we report and to whom? Operationally: a weekly review of new criticals with system owners. For management: a monthly dashboard with the metrics above. After every loud industry CVE: a one-off “does it affect us, what we did” note — it builds board trust better than a hundred slides.
Does the cloud change this process? It changes the tools, not the rules. It adds: configuration scanning (CSPM), container images in the registry, IaC checks before deployment. The upside: in the cloud remediation is often faster (a new image instead of patching a server). The downside: the inventory changes hourly — automated inventory stops being optional.
We don’t have people to run this. What can we realistically do? The minimum viable variant, deployable now: automatic updates everywhere possible; a weekly external-surface scan; a subscription for someone else to watch the rest. We offer that model in our support packages — a monthly scan with prioritisation and a concrete “fix these 12 things” list. Let’s talk.
Summary
Vulnerability management is a loop: see everything → scan regularly → prioritise by risk (KEV/EPSS × exposure × criticality) → fix within deadlines → measure and repeat. The scanner is the smallest problem in that loop. If you want to test your process against reality — a penetration test will show which of your “low” findings chain into a path to your data.
