From Scanner Output to Risk Register: Connecting Vulnerability and Risk Management

Illustration for: From Scanner Output to Risk Register: Connecting Vulnerability and Risk Management

Vulnerability scanners produce findings by the tens of thousands. Risk registers hold entries by the tens. The gap between those two numbers is where a lot of security programmes quietly fail: the scan data never informs the risk conversation, and the risk register describes a world the scanner contradicts every week. Connecting the two is mostly a matter of aggregation and honesty.

A scan export is not a risk register

I have seen a 40,000-row scanner export attached to a board paper as “our cyber risk position”. It is nothing of the sort. A scan finding is an observation: this host, this plugin, this CVE, this CVSS score. A risk is a statement about the business: what could happen, how likely, how bad, who owns it, what we are doing about it.

The difference matters operationally. Nobody can prioritise 40,000 rows. Nobody owns them. They churn completely between monthly scans, so trend lines drawn through raw counts mostly measure scanner coverage and plugin updates, not security. And the rows are wildly unequal: one row might be an unauthenticated remote code execution flaw on an internet-facing server, and the row beneath it a self-signed certificate on a printer. Treating the export as the register flattens that distinction and exhausts everyone.

Vulnerability management and risk management are different disciplines with different cadences. One is an operational pipeline measured in days. The other is a governance process measured in quarters. They must feed each other, but they are not the same thing.

Two track diagram of the fast scan, triage, fix, verify pipeline above the slower identify, assess, treat, review governance cycle, with arrows exchanging themes and acceptance decisions

Different cadences, one system: aggregated themes flow down to the register and acceptance decisions flow back to triage.

CVSS is not risk

CVSS measures the technical severity characteristics of a vulnerability in the abstract. It says nothing about your environment. A 9.8 on an isolated lab machine with no data may matter less than a 7.5 on your internet-facing payment gateway. Prioritising purely by CVSS means treating those the same, which no rational attacker does.

Actual priority is a function of at least three things:

• Exploitability in the real world. Is there a public exploit? Is it being actively exploited? CISA’s Known Exploited Vulnerabilities catalogue and EPSS scores exist precisely because the answer is no for the overwhelming majority of CVEs. Well under ten per cent of published CVEs are ever seen exploited in the wild; those that are deserve most of your urgency.
• Exposure. Internet-facing beats internal. Reachable by ordinary users beats reachable only by administrators. A vulnerability behind three network hops and an authentication boundary is a different proposition from the same CVE on the perimeter.
• Asset criticality and data. This is why vulnerability management collapses without a decent asset inventory. The same finding on a domain controller, a customer database and a test VM represents three different risks, and only the inventory can tell you which is which.

A simple decision matrix combining these beats raw CVSS every time:

Aggregate findings into thematic risks

The bridge from scanner to register is aggregation. Individual CVEs almost never belong on a risk register; the patterns behind them do. Ten thousand findings usually collapse into a handful of themes:

• 60 per cent of overdue criticals sit on one unsupported operating system. The risk is “reliance on end-of-life platforms”, not any single CVE.
• The same web application framework flaw recurs across 30 sites. The risk is “no managed patching for third-party libraries in the development pipeline”.
• Findings on network appliances stay open three times longer than server findings. The risk is “network infrastructure outside the patching process”, with an owner and a fix that is organisational, not technical.

Framed this way, each register entry has a cause, an owner, a treatment plan and a measurable indicator (the vulnerability data itself becomes the metric). Executives can act on “our appliance estate has no patching owner” in a way they never could on a CVE list. And the treatment addresses the generator of findings rather than mopping the floor while the tap runs.

Funnel from 40,000 scan findings down to six to eight thematic risks with named owners

From 40,000 findings to a handful of thematic risks a named owner can carry. The funnel is the connection between the two worlds.

The reverse flow matters too. When the risk register accepts something (“we will not upgrade platform X until 2027”), the vulnerability pipeline should inherit that decision, so the same findings stop being re-triaged every month.

SLAs by severity, and by exposure

Remediation timelines should be published, agreed with the teams doing the work, and measured. A defensible UK-typical starting point:

• Known-exploited or P1: 48 hours to 7 days, with emergency change procedures pre-agreed so the clock is achievable.
• High or P2: 14 to 30 days.
• Medium or P3: 90 days.
• Low or P4: next maintenance cycle, or explicitly not remediated at all.

Two refinements make SLAs credible rather than decorative. First, split targets by exposure: internet-facing systems get roughly half the internal timeline. Cyber Essentials already pushes this direction by expecting critical and high-severity patches applied within 14 days. Second, measure and report the breach rate honestly, by team. An SLA nobody meets and nobody reports on is worse than none, because it manufactures false assurance. Expect a fight about the numbers the first quarter you publish them. That fight is the process starting to work.

When to accept, and how to document it

Some findings will not be fixed, and pretending otherwise clogs the pipeline with permanently overdue items that train everyone to ignore the dashboard. Acceptance is legitimate when the cost of remediation clearly exceeds the risk, when a fix breaks a business-critical dependency, or when the platform is scheduled for decommissioning anyway.

The bar is documentation, not comfort:

• What is being accepted, on which assets, and why the alternative was rejected.
• Who accepted it: the business owner of the affected system, not the security analyst. Acceptance is a business decision made with security advice.
• Compensating controls in place, if any.
• An expiry date. Every acceptance is temporary and gets re-argued at review, because exploitability changes. A quiet CVE can join the KEV list overnight, and your acceptances should be searchable enough to find the affected records that day.

A pile of undocumented, silently ignored findings is risk acceptance too. It is just acceptance nobody agreed to and nobody will defend in front of a regulator or insurer.

A working loop

The end state is a loop, not a handover. Scan findings, filtered through exploitability, exposure and criticality, feed a short list of thematic risks with owners. The register’s decisions, including acceptances, feed back into triage so effort goes where it changes something. Start by taking your latest scan export and forcing it into no more than eight themes. If a theme cannot be written as a sentence a finance director would understand, it is not finished. Those eight sentences are worth more than the 40,000 rows they came from.

Circular loop connecting scanner findings, prioritisation, thematic risks on the register and decisions and acceptances, with acceptances suppressing re-triage

A loop, not a handover: register decisions feed back so the same findings are not re-triaged every month.

Vulnerability findings list with CVSS scores in RaptorGRC

Vulnerability findings triage in RaptorGRC.