Cyber risk in euros

Cyber risk in euros is a probability-weighted expected loss exposure: a figure that expresses how often a loss event is expected to occur and how much it then costs, with an honest range around it. It is not a gut feeling, not a colour code, not a maturity score. It is a cardinal quantity in the same unit the rest of the strategy is weighed in, and therefore the only form in which cyber risk becomes comparable at board level with credit risk, market risk and operational risk. An organisation that cannot put cyber into that unit cannot allocate capital against it either.

This piece explains why that so rarely happens, how to do it properly, and which open methods help you along the way without getting locked into a product. It is written for the CFO who holds the conversation internally with the CISO and the board, and who will need to defend, in person, why a figure is or is not worth the money.

Why does cyber risk stay in technical language?

The answer is as simple as it is persistent: because the side that does the work and the side that allocates the money do not use the same unit. The security function reports in heatmaps, in maturity levels, in threat statements and in patches. Finance steers on expected cash flows, on risk-adjusted return, on expected losses. That difference is not harmless. It means the board is effectively presented with an ordinal weighting for cyber, while everything else on the risk register is weighed cardinally. Comparing one investment with another becomes impossible: high against high, amber against amber, it says nothing about the choice you are making.

There is a second reason, and it lies with the advisory market itself. Much of what presents itself as quantification is in practice a sales pitch for a tool or a service, with the outcome constructed so that the vendor's own solution comes out well. That is exactly what the CFO tests for when spending budget, and exactly where credibility breaks fastest. Quantification is a shared language between CFO and CISO, not a tool purchase. Reverse that frame and you buy a report and keep the problem.

A third reason is more practical. A defensible figure requires inputs that are not always to hand: incident frequencies, how far revenue depends on specific systems, recovery times, contractual exposures. Many organisations do not have that ready on the shelf. That is not a reason to avoid it; it is a reason to start somewhere. A range with an honest bandwidth is always stronger than a falsely precise single figure, and always stronger than a colour on a matrix.

How do you translate a risk into a figure a CFO recognises?

The translation is no conjuring trick; it is a class of calculation model resting on three variables. A loss scenario has a frequency (how often it is expected to occur per year), a magnitude (how much it then costs, covering direct damage, recovery costs, lost revenue, contractual penalties and liability) and a range (the probability distribution around both). The product of frequency and magnitude, expressed as an expected annual loss with a probability range, is the quantity finance steers on. It is the same mathematics you use in credit risk and in operational risk, simply applied to a different type of event.

Three steps make it concrete.

Define the scenario, not the threat. Not "ransomware in general", but "a ransomware incident that takes our ERP production environment down for so many working days". A scenario has a clear beginning, a clear end and a clearly affected part of the business. Only then can you calculate it. A threat category without a bounded scenario cannot be translated, and is probably the reason earlier attempts got stuck in a matrix.

Estimate frequency and magnitude as a range. Frequency need not be exact: a reasoned estimate of "between once every three years and once every eight years" is more useful than a hard number no one can stand behind. Magnitude calls for a combination of direct costs (forensic investigation, recovery, legal), second-order costs (lost revenue, fines, damage claims, higher premiums) and long-tail costs (customer churn, reputation, contractual consequences). Suppose an outage of a core system lasts eight hours and the daily revenue tied to it is X; the lost-revenue component of those eight hours is then a calculable value, not a gut feeling.

Work it out as an expected annual loss, with a range. Multiply frequency by magnitude and present the result as an expected annual loss within an interval, for example "with roughly 80% probability, the annual loss from this scenario falls between amount A and amount B". This is what the literature calls annual loss exposure or annual loss expectancy. What matters about this figure is not the false precision, it is the unit: euros, year, probability. That is what lets you compare, prioritise and allocate.

What this produces is not a prediction. A CFO knows as well as an actuary that a range is no guarantee of the future. What it produces is a defensible yardstick: a way to weigh two controls against each other on risk-adjusted return, to judge an insurance policy on what it does and does not cover, and to show the board what an investment moves ("this step lowers the expected annual loss from X to Y, and here is how"). Risk reduction, not risk elimination. That is the honest claim that holds up.

Which open methods give this figure authority?

The authority of a figure does not come from the party that calculates it. It comes from the method it rests on. Four open frameworks come up consistently in the literature, and the CFO does well to know them by name, so that in a board meeting they can say where the number comes from.

NIST SP 800-30, the US federal guideline for risk assessment of information systems, sets out the structured way to turn threats, vulnerabilities, likelihood and impact into a risk statement. The guideline is open, freely available and a global reference. It is not a calculation model in itself; it is the framework a calculation model fits within, and it makes the risk statements traceable for anyone who tests them later.

FAIR, Factor Analysis of Information Risk, is the most widely used open standard that fills in the calculation model itself. FAIR is standardised by The Open Group as O-RT (Risk Taxonomy) and O-RA (Risk Analysis). Its core is exactly the three variables above: the frequency of loss events, the magnitude of the loss, and the probability distribution in which both are expressed. FAIR is not a product. It is a method, and the specification is public. An adviser who says they use FAIR is doing something you can verify.

ISO 27005, the international standard for information security risk management, provides the organisational context in which the calculation model operates: how risk management connects to the wider management system, how you arrive at risk criteria, and how you set up treatment and monitoring. For a CFO, this is the document that wraps governance around the figure: not just the number, but also who is allowed to approve it and how often it is reviewed.

DNB publications on risk management, in particular the Good Practice Information Security guidance and the supervisory letters under DORA, set out the Dutch context for financial institutions. DNB expects the ICT risk management framework to be formally approved by the management body, the risk to be reported in board-level terms, and the directors to be able to account for the trade-off. For the Dutch CFO this is not an external reference; this is their supervisor.

Build your figure on these four frameworks and you have a story that holds up. Not because the number is beyond challenge, but because the reasoning is publicly testable.

What this means for the conversation with your board

The gain from cyber risk in euros is a governance gain, not a technical one. Three effects in turn.

First, the board finally gets a trade-off on its own table. Not "are we doing enough about cyber", but "we lower the expected annual loss from this scenario by this amount, for this cost, with this residual risk". That is a decision a board knows how to make. "Approve or feel guilty" disappears, and in its place come two or three scenarios with an honest range. That is what good governance draws out and what the supervisor expects from a careful trade-off.

Second, the insurance decision gets sharper. A policy that covers part of the expected loss can now be judged on what it actually covers and what it leaves out. The long tail that rarely falls within a policy (reputational damage, customer churn, contractual consequences with supply chain partners) becomes visible as retained risk in euros, and thereby a standalone item in the trade-off. It is the same discipline with which finance already looks at market risk and credit risk.

Third, the relationship with your CISO changes. Not because they start speaking a different language, but because the two of you share a yardstick. An investment request framed in maturity points now arrives as an expected risk reduction in euros per year, with an investment set against it and a residual risk stated explicitly. That is not marketing. It is how finance and risk already work across the rest of the organisation, finally extended to cyber.

The question, then, is not whether you quantify, but whether you do it defensibly. False precision is a breaking point; a range with an honest bandwidth is a foundation. The method is open, the unit is known, the supervisor expects a traceable trade-off. What is usually missing is not knowledge, it is the discipline to work through two or three scenarios honestly and the nerve to put the result on the table.

Make this move and you take the first real step the board and the CFO have wanted from cyber since the subject reached their agenda. Not shouting louder about the threat. Not another matrix. A figure, in the same unit, with the range beside it, and the method behind it that anyone can verify. That is how you express cyber risk in the language of finance.