Vulnerability management process: a risk-based approach

Most organisations do not lack scan results; they have thousands of them. The hard part is deciding which few to fix this week. Here is a vulnerability management lifecycle built around that decision, a prioritisation matrix, example remediation SLAs and a policy template you can adapt.

By Alex Martyushin, founder & risk consultant · Updated 30 October 2026 · 13 min read

What vulnerability management is (and is not)

A vulnerability is a weakness an attacker could use: an unpatched library, a default password, an exposed admin panel, a misconfigured storage bucket. Vulnerability management is the discipline of keeping the number and severity of those weaknesses within what the organisation is willing to tolerate. Three things make it a process rather than a tool:

• It is continuous. New vulnerabilities are published every day, and your estate changes every week. A quarterly scan tells you about the past quarter, not today.
• It ends in a decision. Every finding is fixed, mitigated, accepted with an expiry date, or closed as a false positive. A finding that just sits in a dashboard is not managed.
• It has owners and deadlines. Someone is accountable for each asset, and each priority level has a remediation target.

Vulnerability management is one control within a wider cyber risk picture. If you need to identify and score cyber risks across the business — ransomware, supplier compromise, insider error — start with a cybersecurity risk assessment. This guide covers the operational process that keeps one of the biggest causes of those risks under control.

Vulnerability assessment vs penetration testing

The two are often confused. A vulnerability assessment uses scanners, agents and vendor advisories to list known weaknesses across many systems, usually continuously or at least monthly. A penetration test is a time-boxed exercise in which people try to exploit weaknesses and chain them together to show what an attacker could actually achieve. You need both: assessments give breadth and frequency; pen tests give depth and test whether your prioritisation was right.

The vulnerability management lifecycle

Most frameworks describe the same six stages, sometimes merged or renamed. What matters is that each stage has an owner and an output.

1. Asset inventory

You cannot protect what you do not know about, and you cannot prioritise without context. For each asset record at least: owner, business service it supports, whether it is reachable from the internet, what data it holds, and the software it runs. When a widely used component has a critical flaw, the first question is “where do we run this?” A software inventory or SBOM answers it in minutes rather than days.

Common gaps: cloud resources created outside the normal process, appliances with embedded software (firewalls, VPNs, phone systems), SaaS admin consoles and old marketing sites. Scanning your own domains and IP ranges as an outsider would catches many of them.

2. Discover

Discovery combines several sources, because no single one sees everything:

• Authenticated scans of servers and endpoints (more accurate than unauthenticated ones, which guess versions from banners).
• External scans of everything internet-facing, at least weekly and ideally daily.
• Dependency and container image scanning in your build pipeline for software you develop.
• Cloud configuration checks for misconfigurations that are not CVEs at all.
• Vendor and government advisories for products scanners do not cover well, such as appliances and SaaS.
• Pen test findings and external reports from researchers or customers.

De-duplicate before you prioritise. One missing operating system update can generate dozens of findings; group them by the fix, not by the CVE.

3. Prioritise

This is where most programmes succeed or fail, so it gets its own section below.

4. Remediate, mitigate or accept

There are four legitimate outcomes for a finding:

• Remediate — apply the patch, upgrade the component, remove the software or fix the configuration. This is the default.
• Mitigate — reduce exploitability while a fix is prepared: disable the vulnerable feature, restrict access to a VPN or allow-list, add a web application firewall rule, isolate the system. Mitigation buys time; it does not close the finding.
• Accept — a documented, time-limited decision by someone with the authority to accept the risk. See when a vulnerability becomes a risk.
• Close as false positive or not applicable — with evidence, such as the vulnerable module not being installed or the vendor confirming the product is not affected.

5. Verify

Patches fail silently, servers are restored from old images, and some fixes need a restart that never happens. Rescan after remediation, and only then close the finding. For P1 items, verify within a day of the fix.

6. Report

Report outcomes, not activity: “three internet-facing criticals are past their deadline” says more than “we ran 52 scans”. The KRIs section lists the metrics worth tracking.

Risk-based prioritisation: beyond CVSS

The Common Vulnerability Scoring System (CVSS) rates the technical severity of a vulnerability on a 0–10 scale. FIRST, the organisation that maintains it, is explicit that the base score measures severity, not risk. Treating it as a risk score causes two problems:

• Too many “criticals”. A large share of published CVEs score 7.0 or higher. If every high and critical is urgent, nothing is.
• No context. The same CVSS 9.8 means one thing on an internet-facing login page and something very different on an isolated test server with no data.

Only a small fraction of published vulnerabilities are ever exploited in the wild. A risk-based approach concentrates effort on those, and on the assets where exploitation would hurt most. Combine four inputs:

KEV is the strongest single signal: it lists vulnerabilities with reliable evidence of active exploitation. EPSS fills the gap for the much larger set of vulnerabilities not (yet) in KEV, by estimating which are likely to be targeted. None of these sources is complete, so treat “not in KEV” as “no confirmed evidence yet”, not “safe”.

A prioritisation matrix

The matrix below is a starting point. It deliberately lets exploitation and exposure override CVSS: a medium-severity flaw being exploited on your website outranks a critical one on an isolated lab machine.

Three practical rules make the matrix work:

1. Re-prioritise automatically. Priority is not fixed at discovery. When a vulnerability is added to KEV or its EPSS jumps, its priority and due date should change the same day.
2. Pick the EPSS cut-off from your capacity. 0.1 is an example. A lower threshold catches more future exploitation but produces more P1 and P2 work. Review it after a quarter of data.
3. Let asset owners argue context, not priority. An owner can show that a server is not actually internet-facing; they cannot downgrade a P1 because the patch is inconvenient. That route is the exception process.

Remediation SLAs: examples and benchmarks

A remediation SLA is the maximum time from a finding being identified (or a patch being released) to it being fixed and verified. The table shows example targets for a small or mid-sized organisation. They are examples, not a standard: set yours from your risk appetite, your change process and any requirements that apply to you.

Some frameworks set explicit timeframes, and your SLAs should be at least as strict as any you are assessed against:

• Australia — Essential Eight. The ASD maturity model (November 2023 version) requires, from Maturity Level One, that vulnerabilities in online services are patched within 48 hours of release when the vendor rates them critical or working exploits exist, and within two weeks otherwise. Other applications and operating systems have their own timeframes that tighten at higher maturity levels.
• UK — Cyber Essentials. The requirements for IT infrastructure (v3.3, April 2026) require in-scope software to be updated within 14 days of release where the update fixes vulnerabilities the vendor describes as critical or high risk, or with a CVSS v3 base score of 7 or above, or where the vendor gives no severity details.
• US — federal agencies. CISA sets a due date for each KEV entry that federal civilian agencies must meet. Private companies are not bound by it, but many use KEV due dates as a benchmark for internet-facing systems.
• Payment card data. PCI DSS has its own patching and scanning requirements; see the PCI DSS compliance checklist.

Requirements change, so check the current text from ASD, NCSC/IASME or CISA before relying on a specific timeframe. Notice that both Essential Eight and Cyber Essentials count from the release of the patch, not from when your scanner noticed it. If your scans run monthly, you can be late before you start.

When a vulnerability becomes a risk in the register

Individual vulnerabilities belong in a ticketing system or scanner, not the risk register. Ten thousand line items would bury every other risk. A vulnerability, or a group of them, moves into the risk register when one of these is true:

• It cannot be fixed within its SLA and someone must accept the exposure — for example, a legacy system that cannot be patched without vendor support the business no longer pays for.
• It is systemic — such as all point-of-sale terminals running an unsupported operating system, or patching consistently missing its targets for a whole platform.
• It affects a principal risk — a P1 on the system that underpins a risk already rated critical in the register, such as a customer data breach.

Exceptions and risk acceptance

An exception is a formal, time-limited decision to leave a vulnerability open. A usable exception record contains:

1. The vulnerability or group, the affected assets and their priority.
2. Why it cannot be remediated now (dependency, vendor, downtime, cost).
3. Compensating controls in place: network isolation, access restricted to named users, additional monitoring, a WAF rule, disabled features.
4. The resulting residual risk rating — see inherent vs residual risk for how to assess it.
5. The approver, whose authority must match the residual risk.
6. An expiry date, after which the exception lapses and the finding is overdue again unless re-approved.
7. The remediation plan: what has to happen for the exception to close.

Expiry dates are the single most important field. Exceptions without them become permanent; permanent exceptions become the gaps attackers find. If the same exception has been renewed three times, raise it as a risk in its own right and fund the fix, or retire the system.

Exceptions are where vulnerability management meets risk appetite. If your appetite statement says the organisation has a low appetite for exposure of customer data, an open P1 on a customer-facing system should be beyond what a head of IT can accept alone.

KRIs and metrics to report

Good vulnerability metrics are leading key risk indicators: they show exposure building before an incident. Five that work for most organisations:

Thresholds are illustrative. Report the trend, not just the latest value, and attach a line of commentary to every amber or red figure: why it moved and what is being done.

Vulnerability management policy template

A vulnerability management policy sets the rules; the procedure explains how to follow them. Keep the policy to two or three pages so people actually read it. A patch management policy can be a section of it or a separate document — what matters is that the timeframes match. Suggested sections:

1. Purpose and scope — which assets, environments and suppliers are covered (include cloud, SaaS admin consoles, appliances and developed software).
2. Roles and responsibilities — security, asset owners, IT operations, developers, risk owner and approvers for exceptions.
3. Asset inventory requirements — mandatory fields (owner, criticality, internet exposure) and how new assets are registered.
4. Discovery — scan types and minimum frequency, e.g. external daily or weekly, internal authenticated weekly or monthly, pipeline scanning on every build.
5. Prioritisation — the matrix, the data sources (CVSS, KEV, EPSS, asset context) and when priority is recalculated.
6. Remediation timeframes — SLAs by priority, the clock start (patch release or discovery) and any regulatory timeframes that override them.
7. Emergency process — who can authorise out-of-hours change, take a service offline or apply a mitigation without the usual approvals when a P1 appears.
8. Exceptions and risk acceptance — required fields, approval levels, maximum duration, link to the risk register.
9. Verification — how and when fixes are confirmed before closure.
10. Unsupported software — end-of-life systems must be upgraded, isolated or carried as an accepted risk with a retirement date.
11. Third parties — expectations of suppliers and managed service providers, including notification of critical vulnerabilities in their products.
12. Metrics and reporting — the KRIs, audiences and frequency.
13. Review — annual review of the policy, plus after any significant incident.

Assign an owner to the policy itself and record its next review date. The risk register template has columns for owners, controls and review dates you can reuse for the exceptions log.

Common mistakes

• Prioritising by CVSS alone. It produces a queue of “criticals” too long to finish, while the medium-severity flaw being actively exploited waits its turn.
• Scanning without an inventory. Scanners only find what they are pointed at. The forgotten server is the one that gets compromised.
• Ignoring appliances and embedded software. Firewalls, VPNs, hosting panels and phone systems often bundle runtimes like PHP or OpenSSL that general-purpose patching never touches.
• Counting from discovery instead of release. If your SLA clock starts when your monthly scan runs, a 14-day target can become six weeks of real exposure.
• Exceptions without expiry. Every accepted vulnerability needs an end date and a named approver.
• Closing tickets without rescanning. “Patched” and “fixed” are different until verified.
• No emergency path. If a P1 must wait for the weekly change board, your 48-hour SLA is fiction. Agree the emergency route before you need it.
• Reporting volume instead of risk. Raw counts rise whenever you add a scanner or an asset. Boards need to know where you are exposed and whether it is within appetite.