A financial cyber-risk estimate can look precise while resting on undocumented choices. Before calculating an annual loss figure, record the event being counted, why its frequency is plausible, which losses belong in the estimate, the range for each input, and the evidence or judgment behind it. This page supplies an input register and a worked sensitivity check. The NIS2 risk-management overview concerns governance and applicable security measures; it does not require every organization to produce a monetary cyber-loss model. This article addresses the separate analytical task of making an optional estimate understandable and challengeable.
The NIST SP 1303 enterprise-risk guide describes integrating cybersecurity risk information with enterprise risk management. The NIST Cybersecurity Framework provides a common language for outcomes and governance. Neither source dictates the illustrative numbers below or certifies that one formula will predict a particular incident. The useful discipline is to expose assumptions so a decision-maker can see what would change the conclusion. Monetary figures without a stated scope, time horizon, or uncertainty should not be treated as measured facts.
Define one event before discussing frequency
“Data breach” is too broad an event for a useful calculation. Specify the asset, attack path, observable threshold, and business consequence. For example: an external actor obtains a privileged account for a customer-support platform, exports records, and the organization must investigate, contain, notify where required, and restore trust in the service. This is distinct from a failed login, an accidental disclosure to one recipient, and a destructive ransomware outage. Combining them into a single frequency may hide different controls and different loss distributions.
Set a period, such as one year, and state what counts as one event. If an attacker makes three exports before detection, does the model count one incident or three? If a supplier and the organization are hit by the same underlying outage, how are correlated losses handled? Define the unit before using incident statistics. The event description should also explain what is outside scope: unaffected subsidiaries, speculative fines, harms that are borne by a partner rather than the organization, or losses already counted elsewhere.
An event tree can help without requiring a sophisticated model. Start with an attempted compromise, then identify conditions needed for successful access, data export, delayed detection, and material loss. Each condition should map to a control or observation. The DORA ICT risk-management discussion covers a different regulatory setting; it can help an in-scope entity connect analysis to governance, but it does not make the example event frequency authoritative for other sectors.
Record the frequency rationale, not merely the number
Suppose a team chooses an illustrative range of 0.05 to 0.30 material events per year for the scenario. That is not a forecast from this article. The input register must explain where the range came from: internal incidents, attempted compromises, threat intelligence with matching exposure, a comparable peer set, a structured expert elicitation, or a conservative planning assumption. Each source has limitations. A zero in the internal incident log may mean the event is rare, that detection is weak, or that the organization has limited observation history.
Do not convert every security alert into a realized loss event. A phishing message is not a successful account takeover; a takeover is not always a data export. If using a chain of conditional estimates, show each denominator and how uncertainty compounds. If the analyst instead estimates material incidents directly, say so and avoid multiplying by conditional probabilities again. The input register should include the source period, population, adjustments for current exposure, and the person who reviewed the reasoning.
External frequency data can be misleading when the organization differs in size, industry, architecture, or detection quality. Record those differences. A statistic about all reported breaches does not directly estimate the frequency of the narrow event in your environment. Expert judgment can still be useful if the experts state their assumptions independently, discuss major disagreements, and revise a range with reasons. Averaging unsupported guesses does not turn them into evidence.
Separate loss categories and avoid double counting
For the example event, potential costs may include incident response, external investigation, legal advice, notification work, restoration, interruption, customer support, contractual remediation, and longer-term business effects. Some categories are direct expenditures; others are uncertain opportunity costs. Record the method and timing for each. Do not simply add a broad “breach cost” benchmark to detailed line items: the benchmark may already include those items. The ISO 27001 versus GDPR overview can help separate security-management and privacy obligations, but the applicable legal response to a specific incident needs its own assessment.
For interruption, write affected transactions × contribution margin per transaction × fraction not recovered, or another explicit formula suited to the business. Do not use gross revenue as loss if transactions are likely to move to a later day. For response labor, estimate hours by role and the cost basis chosen by finance. For outside services, distinguish a retainer already paid from an incremental call-out expense. Legal penalties should not be entered as a routine fixed charge; their availability and amount depend on facts, jurisdiction, authority decisions, and procedures. If considered at all, label them as a highly uncertain conditional scenario, reviewed by counsel.
The register should link every category to the event boundary. If a supplier pays part of a recovery cost under a contract, note the assumption and collectability; do not simply subtract the full promise. Insurance may reimburse some amounts subject to exclusions and limits, but the underlying event still occurs. Keep gross and net consequences separate so the decision-maker can see operational harm even when a financial transfer is expected.
A usable input-register template
Each row needs a stable ID, definition, unit, central or range values, source, date, owner, and sensitivity priority. Keep a column for what would invalidate the input. A spreadsheet may be adequate; the analytical quality comes from the definitions and evidence, not the software used.
| Input | Definition and unit | Illustrative range | Evidence or uncertainty to record |
|---|---|---|---|
| F1 | Material events in one year | 0.05–0.30 | Sparse internal history, external comparison |
| L1 | Response and investigation per event | €40k–€120k | Retainer terms, expected hours |
| L2 | Business interruption per event | €0–€150k | Duration and unrecovered margin |
| L3 | Customer support and remediation | €10k–€80k | Affected population and service method |
| D1 | Days until containment | 1–10 days | Logging coverage and response exercise |
| C1 | Correlation with supplier outage | Unknown | Shared dependency mapping needed |
These figures are deliberately fictional, not market data. The table does not assert that all upper bounds occur together or that multiplying midpoints yields a meaningful expected loss. F1 and the loss rows represent different kinds of uncertainty. D1 may influence L2 and L3, so it should not be treated as an independent cost to add. C1 flags a dependency that could affect multiple scenarios; a portfolio model would need to account for it.
Add an explicit “decision use” field. Is the estimate being used to compare two control options, set a contingency budget, inform an insurance discussion, or rank risks? The required precision differs. A rough order-of-magnitude range may support screening, while a capital or contractual decision may justify deeper data collection and independent challenge. An attractive single number should not be the goal of every analysis.
Work through a transparent, limited calculation
Consider a simplified scenario with an assumed material-event frequency of 0.10 per year and a conditional loss of €200,000 if the event occurs. Multiplication gives €20,000 expected annual loss under those assumptions. This is an arithmetic illustration, not an observed annual bill or a statement that one incident occurs every ten years on schedule. If the annual frequency is 0.05, the same calculation gives €10,000. At 0.30, it gives €60,000. The input range alone changes the result sixfold.
Now suppose the loss conditional on the event is between €100,000 and €350,000. A crude lower combination, 0.05 × €100,000, is €5,000; the upper combination, 0.30 × €350,000, is €105,000. These endpoints are a sensitivity envelope, not a confidence interval. They may pair assumptions that do not occur together. Document any correlation: a long undetected event may both be less frequent and cause a larger loss, or a common supplier failure may make several loss lines rise together. Avoid presenting the envelope as a probability distribution without a justified model.
If a proposed control costs €25,000 per year and appears to reduce event frequency from 0.10 to 0.06 with no change in conditional loss, the illustrative expected reduction is (0.10 − 0.06) × €200,000 = €8,000 annually. On this narrow financial model the control is not justified by expected loss reduction alone. That does not prove it should be rejected: legal duties, safety, trust, risk appetite, severe-tail exposure, and benefits across other scenarios may matter. It does show that an unsupported “60% risk reduction” claim should be challenged before appearing in an investment case.
Test assumptions one at a time and together
A sensitivity check asks which input drives the decision. Vary event frequency while holding losses fixed, then vary interruption duration and response expense. Finally vary plausible combinations, especially where the inputs are linked. In the example, the frequency range moves the result much more than a small change to investigation hours. The next research action should therefore focus on frequency rationale or on a control-effect estimate, not on refining a negligible cost line to the nearest euro.
Use a simple decision threshold if appropriate. If management would fund a control only when expected annual reduction exceeds its annualized cost, solve for the required reduction and examine whether it is plausible. For a €25,000 annual cost and €200,000 conditional loss, frequency would need to fall by 0.125 events per year in the simplified model. A baseline assumption of 0.10 makes that impossible without also changing other scenarios or loss severity. Showing this arithmetic can prevent an optimistic control-effect estimate from entering the record unnoticed.
Keep qualitative considerations visible next to the calculation. A low expected value can coexist with a very severe but rare outcome that exceeds the organization’s ability to absorb it. Some obligations or commitments are not optional merely because their modeled return is small. Conversely, a large calculated number based on invented inputs should not be treated as proof of a legal breach. The model informs judgment; it does not replace authority, incident analysis, or governance.
Challenge source quality and model boundaries
For each input, ask what observation would change it. A tabletop exercise may reveal response delays. A restoration test may narrow interruption duration. Contract review may bound supplier assistance. Logging changes may alter detection probability, but only after they are implemented and tested. Assign the evidence collection to an owner and a date. If data will not be available soon, preserve a wide range and explain why a decision is still being made.
Independent review should check arithmetic and meaning. Are euros in a loss row actually incremental? Does an annual frequency apply to the same event defined at the top? Are upper ranges added even though they overlap? Has a loss been counted in both interruption and customer remediation? Did the analyst use an incident rate from a population unlike this one without adjustment? These checks often improve an estimate more than a complex simulation.
Version the register. If the organization adopts a new identity control, changes provider, enters a new market, or observes an incident, update the assumptions and preserve the former version. The difference between two estimates may reflect exposure, data quality, or a changed method. A version note lets readers distinguish these. If the time horizon changes from annual to multi-year, state how frequency and loss assumptions were transformed, rather than relabeling the output.
Connect the input register to a decision
The final decision record should include the event definition, input table, calculations, major sensitivities, limitations, proposed action, owner, reviewer, and date for reconsideration. It should also state whether the estimate is gross or net of insurance, whether it covers one scenario or a portfolio, and which obligations were considered outside the model. A committee can then disagree with one assumption without discarding the entire analysis. The register makes challenge constructive: replacing a weak estimate with a better observation changes a visible row and an explainable result.
Do not describe monetary quantification as an NIS2 requirement for every organization. The NIS2 compliance guide and the DORA compliance guide concern different legal scopes and duties. For an in-scope entity, the applicable text and national implementation must be examined on their own terms. A quantified model can support management discussion, but the existence of a number is not proof that the mandated measures are sufficient. A clear statement of uncertainty is more useful than a precise-looking value without a defensible event and input record.