Risk

Cyber Risk Quantification (CRQ): cyber risk in money

· 5 min read · Futture.ai

Cyber Risk Quantification (CRQ) expresses cyber risk in money and probability: how much the organisation expects to lose per year from a scenario, and how likely it is to lose more than an amount it cannot absorb. In the article on the 5×5 matrix we showed why a colour cannot decide a budget. This one is about what happens inside the model.

The unit matters because it changes who can join the conversation. "High risk" is discussed only by security. "between R$ 2 million and R$ 9 million a year, with 90% confidence" is discussed by the CFO, legal and the board — and each of them holds data that improves the number.

The questions CRQ answers

Quantification is only worth the effort when a decision is waiting for the number. The most common are three:

  • How much could we lose in a bad year? Not the average, but the tail: the amount exceeded only in 1 year out of 10 or 1 out of 20.
  • Does this investment pay off? How much the expected loss falls if the control is deployed, compared with what it costs per year.
  • Are we within appetite? If leadership has set limits in money, as discussed in risk appetite, CRQ is the ruler that measures exposure against that limit.

Everything starts with a scenario

CRQ does not quantify "ransomware" or "data breach". It quantifies scenarios: who acts, against which asset or process, with what effect on the business. The difference is practical. "Ransomware" has no frequency or cost you can estimate. "A criminal group encrypts the billing ERP and stops invoicing for several days" does: you can ask finance what a day without invoicing costs and operations how long recovery takes.

A good test for a scenario: if two people from the business read the sentence and picture events with very different costs, it is still too broad.

Frequency: how many times a year

The most widely used open method, FAIR (standardised by The Open Group as Open FAIR), breaks loss event frequency into two factors that can be estimated separately:

  • Frequency of attempts. How many times a year a threat actor acts against that asset. SOC telemetry, incident history and industry reports help here.
  • Chance the attempt succeeds. The attacker's capability compared with the resistance of the controls. This is where open vulnerabilities, exposure and tested control effectiveness come in.

Multiplied, the two give the loss event frequency — fractions included: one event every five years is 0.2 per year.

Magnitude: what each event costs

FAIR separates primary loss, suffered directly by the organisation, from secondary loss, which comes from the reaction of others: customers, regulators, courts, the market. It organises cost into six forms of loss. The table also says whom to talk to for each estimate — it is almost never security:

Form of lossExampleWho estimates
ProductivityRevenue not realised during the outageFinance and operations
ResponseForensics, overtime, communication, notificationSecurity and legal
ReplacementReplacing equipment, rebuilding systemsIT
Fines and judgementsRegulatory sanctions, settlements, lawsuitsLegal and compliance
Competitive advantageLoss of intellectual property or market positionStrategy and product
ReputationCustomers who leave, higher acquisition costSales and marketing

Every estimate goes in as a range — minimum, most likely and maximum — never as a single number. The width of the range is information: it tells you how much you still do not know.

Monte Carlo: from ranges to a curve

With frequency and magnitude as ranges, a Monte Carlo simulation draws thousands of "possible years" and adds up the losses in each. Two results come out:

  • Annualised expected loss. The average of the simulated years. Useful to compare scenarios and to calculate the return of controls.
  • Loss exceedance curve. For each amount, the probability of losing more than it in a year. This is the reading the board cares about: "there is a 10% chance we lose more than R$ 8 million from this scenario next year".

Read the curve, not just the average. Two scenarios with the same expected loss can have completely different tails: one loses a little often, the other almost never loses, but when it does it is a lot. Decisions on insurance and appetite depend on the tail.

Where CRQ helps most

Comparing controls. In an illustrative example, a control costs R$ 600,000 a year and cuts the scenario's expected loss from R$ 4.2 million to R$ 2.9 million. The reduction, R$ 1.3 million, is greater than the cost: the control pays for itself. Another control costs R$ 900,000 and reduces R$ 200,000. The arithmetic is uncomfortable, and it is exactly what the heat map never shows.

Sizing cyber insurance. The policy limit makes more sense when compared with the tail of the curve than with a percentage of revenue.

Reporting in enterprise risk language. The NIST IR 8286 series is precisely about integrating cybersecurity risk into enterprise risk management (ERM). Loss in money and probability is what lets cyber risk sit in the same register as credit, operational and market risk.

The mistakes that sink CRQ projects

  • Trying to quantify the whole register. Start with three to five scenarios competing for the same budget.
  • Using a single number. A value without a range hides uncertainty and invites false confidence.
  • Hiding assumptions. Every input needs a source and an owner. When someone disagrees with the result, the discussion should move to the assumption.
  • Confusing precision with accuracy. "R$ 3,482,117.40" is not more correct than "between R$ 2 and R$ 5 million". It is only more misleading.
  • Never revisiting. An incident, a new control or a change in the business alters the inputs. The model needs a review cadence.

CRQ, scores and CVSS: each in its place

The three are often confused, but they answer different questions. CVSS measures the technical severity of a flaw. A cyber risk score is a posture indicator, good for trend and day-to-day prioritisation. CRQ estimates loss in money for capital decisions. They feed each other: open vulnerabilities and control effectiveness inform the chance of success of a CRQ scenario.

Sources consulted on 4 October 2026: Open FAIR standards — Risk Taxonomy (O-RT) and Risk Analysis (O-RA) —, published by The Open Group; NIST IR 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM), and its companions NIST IR 8286A and 8286B. Amounts are illustrative. This article describes quantification principles and does not recommend a specific tool.

Official references

Read next

← Back to the blog