
Blog Post
Cyber Risk Register vs. Vulnerability Register
October 21, 2026
The two registers hold different objects, run on different clocks and answer to different people. Where they are treated as one list at different levels of detail, items get counted twice and others fall between them.
A vulnerability register holds findings on assets and numbers in the thousands. A cyber risk register holds loss scenarios and numbers in the tens. Neither is a summary of the other.
What Does Each One Hold?
Different units, which is the distinction everything else follows from.
The Vulnerability Register
One entry per weakness per asset, covering missing patches, misconfigurations and exposed services. Owned by security operations, fed by scanning, and moving on a daily cycle as findings open and close.
The Cyber Risk Register
One entry per loss scenario, describing an event that could cost the organization money. Owned by risk or governance, fed by assessment, and moving on a quarterly cycle as treatment decisions are taken and reviewed.
Why Neither Summarizes the Other
A scenario is supported by many findings and is not their sum. Some scenarios rest on no vulnerability at all, covering insider action, supplier failure and regulatory change, so a register fed only by scanning will never contain them. What a cyber risk register holds sets out the structure in full.
How Does a Vulnerability Reach a Financial Figure?
Through three steps, and skipping any of them produces a number nobody can defend.

Finding to Control Coverage
An individual finding carries no value. What it changes is the coverage of a control across a population, so fifty unpatched systems move a patching coverage figure rather than creating fifty small losses.
Coverage to Scenario Likelihood
Coverage feeds the frequency term of the scenarios that control protects against. A drop in patching coverage raises the likelihood of exploitation scenarios and leaves insider scenarios untouched, which is why the mapping has to be per control rather than global.
Likelihood to Currency
The scenario already carries a loss magnitude, so a change in likelihood changes the expected loss directly. Cyber risk quantification is what holds the magnitude, and the method behind it explains where it comes from.
Where Do Teams Double-Count?
Three places, and all three inflate the reported position rather than the real one.
- The same weakness in both registers: A severe finding logged as a vulnerability and again as a risk entry because it felt significant.
- Severity aggregation: Counting critical findings as a proxy for risk level, which counts one asset repeatedly where it carries several findings.
- Double-credited remediation: Claiming the reduction once when the finding closes and again when the scenario is reassessed.
Which Is Most Common
The first, because it feels like diligence. A critical finding promoted into the risk register acquires a second owner, a second treatment plan and a second appearance in reporting, while the underlying weakness is one thing.
The Test
Ask whether any risk register entry names a specific asset and a specific technical weakness. Where one does, it is a finding wearing a scenario's clothing.
Where Do Items Get Lost?
Four places, and the third is the one nobody catches.
Findings on Unlisted Assets
A weakness on an asset nobody inventoried belongs to no scenario, so it never influences any figure. The loss happens at the inventory rather than at either register.
Scenarios With No Technical Expression
Insider action, supplier failure and regulatory change produce no scan finding. A program building its risk register upward from vulnerability data will systematically omit them.
Acceptance That Does Not Propagate
A finding marked accepted at the technical level leaves the remediation queue and stops appearing in operational reporting. The scenario it contributed to is never told, so the risk register continues to assume a treatment that nobody is performing.
Closures That Do Not Update the Scenario
The mirror image. Findings close, coverage improves and the register entry keeps its original severity until somebody reassesses it by hand.
Who Should Own What?
Two owners with one connection point between them.
The Operational Owner
Security operations owns findings, their triage and their closure. The measure of success is coverage achieved rather than findings closed, since closing the easy ones improves a count without moving a figure.
The Risk Owner
Risk or governance owns scenarios, their treatment decisions and their acceptance. The measure is exposure against appetite, which needs the coverage figures the first owner produces.
The Connection
Control coverage, which is the only object both parties need and the one both can agree on. Measured control effectiveness is where the two registers meet without either becoming the other, and what a register platform stores decides whether that connection exists in the tooling.
What Should Be Established?
Three checks, and the first takes one pass through the register.
Whether any risk register entry names a specific asset and technical weakness, since those are findings that migrated and are now counted twice. Whether accepted findings notify the scenarios they support, because acceptance at one level silently invalidates an assumption at the other. Then whether the register is fed by anything other than scanning, as a register built upward from technical data omits every scenario with no technical expression. A quantified register holds the scenario layer, and the finding layer stays where it belongs.
One Connection Point, Not One List
A vulnerability register holds findings on assets in the thousands and a cyber risk register holds loss scenarios in the tens, with different owners and different clocks. A finding reaches a financial figure in three steps, moving control coverage, which moves scenario likelihood, which moves expected loss against a magnitude the scenario already carries. Double counting happens when a severe finding is promoted into the risk register, when critical counts stand in for risk level, and when a remediation is credited twice. Items are lost on unlisted assets, in scenarios with no technical expression, and above all when a technical acceptance never reaches the scenario that assumed the treatment was happening.
To see control coverage connect findings to a scenario's loss figure, book a demo with our cyber risk experts.
Register Comparison FAQs
Speak to an ExpertWhat is the difference between a cyber risk register and a vulnerability register?
The unit each one holds. A vulnerability register carries one entry per weakness per asset, covering missing patches, misconfigurations and exposed services, owned by security operations and moving daily as findings open and close. A cyber risk register carries one entry per loss scenario describing an event that could cost money, owned by risk or governance and moving quarterly as treatment decisions are taken.
How does a vulnerability roll up into a cyber risk with a financial figure?
Through three steps. An individual finding carries no value, but it changes the coverage of a control across a population, so fifty unpatched systems move a patching coverage figure rather than creating fifty small losses. Coverage feeds the frequency term of the scenarios that control protects against. The scenario already carries a loss magnitude, so a change in likelihood changes expected loss directly.
Where do teams double-count between the two registers?
Three places. A severe finding logged as a vulnerability and again as a risk entry because it felt significant, which is the most common and feels like diligence. Severity aggregation, where counting critical findings stands in for risk level and counts one asset repeatedly across several findings. And double-credited remediation, where a reduction is claimed when the finding closes and again when the scenario is reassessed.
What gets lost between a vulnerability register and a risk register?
Four things, and one is rarely caught. Findings on assets nobody inventoried belong to no scenario. Scenarios with no technical expression, covering insider action and supplier failure, never appear in a register built upward from scan data. Closures fail to update scenario severity. And a finding marked accepted at the technical level leaves the remediation queue while the scenario continues to assume a treatment nobody is performing.
Why is technical risk acceptance dangerous for a risk register?
Because acceptance at one level does not propagate to the other. A finding marked accepted stops appearing in operational reporting and leaves the remediation queue, which is a legitimate operational decision. The scenario that finding contributed to is never notified, so the risk register continues to carry a likelihood that assumes a control is being maintained when the organization has decided it will not be.
Who should own each register?
Security operations owns findings, their triage and their closure, measured on coverage achieved rather than findings closed, since closing easy ones improves a count without moving a figure. Risk or governance owns scenarios, treatment decisions and acceptance, measured on exposure against appetite. Control coverage is the single object both parties need and the point where the two registers meet without either becoming the other.




