The Vulnerability Was Never Unknown. It Was Assigned.

Read the public accounts of breaches that began with a known software flaw and the same pattern repeats. The CVE had been disclosed months earlier. It had appeared in a scan report that somebody had read. What did not happen was the fix, and more precisely,what did not happen was anyone confirming the fix had worked.

The industry has spent fifteen years improving the first half of vulnerability management. Scanning is faster, coverage is wider, threat intelligence is better, and prioritisation models are more sophisticated than anything available a decade ago. The secondhalf, where a finding becomes a completed and verified change on a production machine, has barely moved.

In most organisations, detection and remediation sit with different teams, in different tools, under different reporting lines. Security runs the scanner and produces findings. Operations owns the endpoints, the change window, and the consequences of a patchthat breaks an application.

Between them is a transfer that is usually manual. A report is exported and filtered. A list becomes a spreadsheet. Someone raises tickets by hand, or raises a single ticket covering forty machines.

Every step of that transfer loses something. Exploit status rarely survives it. The reasoning behind a severity rating rarely survives it. What arrives on the operations side is often a CVE identifier and a due date, stripped of the context that would explainwhy this one should jump the queue. It then joins a backlog that already contains printer faults and access requests, and competes with them on equal terms.

None of this reflects a failure of diligence. It is what happens when a process crosses an organisational boundary without a system carrying it across.

The standard measures in this field describe detection. Scan coverage, scan frequency, time to detect, findings by severity. All of them can be produced inside a single tool, which is precisely why they became the measures.

The number that describes exposure is different. It runs from the moment a vulnerability is detected on a specific machine to the moment that machine is confirmed clean. Very few organisations can produce it, because the opening event lives in one system andthe closing event lives in another, and nothing joins them.

An organisation that scans daily and remediates in ninety days has excellent detection metrics and a ninety-day exposure window. The dashboard will look healthy throughout.

The most common reporting error I encounter is patch compliance presented as proof of remediation.

Patch compliance figures usually describe deployment jobs that reported success. That is a statement about the deployment tool rather than about the machine. A patch can install and wait on a reboot that never happens, or be superseded by a later release. Anagent can fail quietly. A device can be offline during the window and never get picked up in the next one. A change can be rolled back after it breaks an application, and nothing tells the security team the exposure has returned.

Verification means returning to the endpoint after the change and confirming the finding has gone. It is a small step, and it is skipped constantly, because the ticket is already closed and the report already says ninety-six per cent.

For responsible entities under the Security of Critical Infrastructure Act, the Critical Infrastructure Risk Management Program must be approved by the board, reviewed annually, and reported to the regulator within ninety days of the end of the financial year.Cyber and information security hazards are one of the four hazard categories it has to address.

That obligation is not discharged by holding a scanner licence. It asks whether the organisation has a process that reduces the risk and mitigates the impact, and whether that process can be evidenced. Evidence assembled retrospectively from two disconnectedsystems is weak evidence, and compiling it takes weeks.

The Cyber Incident Review Board established under the Cyber Security Act 2024 conducts no fault reviews of significant incidents and publishes its findings. Where a review examines an intrusion that began with a known CVE, the questions will be straightforward.When did you know, what did you decide, and what confirmed the fix.

If these questions are hard to answer, that difficulty is itself the finding.

Detection has become close to a commodity. Knowing an exposure exists no longer separates the organisations that get breached through known flaws from the ones that do not. Closing it, proving it closed, and being able to produce the record on request is whatseparates them, and almost all of that work sits in IT operations rather than in the security tooling budget.