Blog Post

Cyber Risk Register vs. Vulnerability Register

October 21, 2026

Table of Contents

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.

‍

Quantification view showing average annual loss and an extreme percentile against targets, above recommended control actions each carrying a coverage change and the dollar effect of making it
A control moving from one coverage level to another with a dollar effect attached is the step that connects a technical finding to a figure somebody can act on.

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.

Tomer Shoolman

Product Manager

Register Comparison FAQs

Speak to an Expert

What is the difference between a cyber risk register and a vulnerability register?

How does a vulnerability roll up into a cyber risk with a financial figure?

Where do teams double-count between the two registers?

What gets lost between a vulnerability register and a risk register?

Why is technical risk acceptance dangerous for a risk register?

Who should own each register?