Cyber Risk Quantification: Pricing Your Bad Days
By Yonatan Hoorizadeh — CISSP, CISM, CRISC, AAISM
Published By: Purple Shield Security
Published: October 12, 2026
Last updated: October 12, 2026
Cyber risk quantification turns security risk into money. Instead of reporting how many vulnerabilities were closed, a security leader names the few loss scenarios that would seriously hurt the business, puts a dollar range on each, and ranks fixes by how much they reduce that expected loss. Finance teams and boards can then make real decisions.
What is cyber risk quantification, and why are boards asking for it?
Cyber risk quantification is the practice of expressing security risk as a range of likely financial loss over a set period, usually twelve months. Boards ask for it because they approve spending in dollars, not in vulnerability counts. A report showing thousands of closed findings tells a director nothing about whether the company is safer or what that work was worth.
Ivan Milenkovic, VP Risk Technology EMEA at Qualys, made this point in an October 2026 interview with Help Net Security. He argues that most security scoring has no anchor to a potential loss. He compares it to a credit score, which only means something because it sits on top of a money question: how likely is this borrower to fail to repay this amount?
The pressure to answer that question is growing. According to Milenkovic, a single frontier AI model surfaced more than 6,000 candidate high- or critical-severity flaws across more than 1,000 open-source projects. No security team fixes all of that. The job has shifted from closing everything to deciding, in writing, which issues matter and which ones the business will carry.
Why do most first attempts at a security economic model fail?
Most first security economic models fail because they start from the bottom. A team exports ten thousand scanner findings and tries to add them up into a dollar figure. Severity scores were never designed to carry financial meaning, so the total means nothing to a CFO. Milenkovic recommends reversing the order: start with loss, then work down to the assets that drive it.
In practice, that means naming the handful of scenarios that would genuinely hurt the business. Milenkovic offers examples such as a payment platform down for three days, a regulator's letter about customer data, or ransomware spreading across a region. Each scenario gets a loss range. Only then does the team map the systems and exposures that feed each scenario.
Milenkovic accepts that the first version of a loss model will be wrong, just as early credit models were, and that it improves as real outcomes feed back in. His rule from his own CISO years is blunt: “if the number has been touched by a human, I don't believe it.”
For a mid-market company, that rule is the destination, not the starting line. Most 200-person firms do not have the asset inventory or telemetry to feed a model automatically on day one. A workable compromise is to allow human estimates in version one, but record every assumption, name who made it, and replace estimates with system data as the program matures. The real problem is an undocumented guess, not a guess.
How should a CISO decide what to fix first when everything looks critical?
A CISO should rank fixes by value at risk: how much a specific exposure adds to plausible future loss. A critical flaw on an unused test server adds almost nothing. A moderate flaw on an internet-facing revenue system can add a great deal, especially when attackers are already exploiting it. Severity describes how bad a flaw is. Value at risk describes what it could cost the business.
Milenkovic describes a business unit ranked worst in its group for exactly this reason. Servers disconnected from revenue, but heavy with Common Vulnerabilities and Exposures (CVE) entries, were scored the same as the payment gateway. The team spent its hours patching the wrong machines.
Prioritization turns political when the only evidence on the table is technical, because technical arguments rarely settle a budget fight. A dollar range usually does. One practical input from the field: the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog. An exposure on a revenue system that also appears on the KEV catalog belongs at the top of the list, whatever its severity score says.
Boards should not be debating individual CVEs. Asset-level detail feeds the model, but the board question is broader, according to Milenkovic: are security controls scaling across the enterprise relative to what the company stands to lose?
What does a CFO need from a security leader?
A CFO needs a number that fits in a spreadsheet, a range around it, and a decision attached. Security leaders tend to speak in binary terms (secure or not secure), while finance works in probabilities, percentages, and ranges. Closing that language gap is the security leader's job. The CFO, chief risk officer, and treasurer have been pricing uncertainty their whole careers.
Milenkovic suggests bringing four things to every CFO conversation:
The loss scenario, expressed in dollars as a range.
How likely that loss is over the next twelve months, and what the estimate rests on.
What the security team proposes to spend, and how far the loss range moves if it does.
What happens if the company does not spend it, including who signs to accept the risk.
The last item is the one security leaders forget most often, according to Milenkovic. Finance cannot approve or reject a risk that has no owner. Once the executive whose budget absorbs the loss has to sign the risk acceptance, the conversation changes quickly.
How do you show the value of an incident that never happened?
The value of a security program that prevents incidents shows up in measurable change, not in the absence of bad news. Milenkovic recommends reporting what moved each quarter: how long critical exposures survived on the systems behind each loss scenario, how much plausible loss sits in past-due fixes, whether controls held when tested (such as a backup restore that worked), and whether insurers offered better renewal terms.
What does a practical first model look like for a mid-market company?
A mid-market company can build a usable first cyber risk model in a few weeks without specialized software. Pick three loss scenarios, estimate a low, likely, and high cost for each using financial data the company already has, map each scenario to the handful of systems that drive it, and assign a named executive owner. That is enough to change the next budget conversation.
The dollar figures are closer than most teams think. Finance already knows revenue per day for downtime scenarios. The current cyber insurance policy shows limits, retentions, and sublimits for ransomware or business interruption, which is the company's existing view of what it could lose. Incident response retainer rate cards, outside counsel fees, and penalty clauses in customer contracts fill in the rest.
Scenario choice should follow company size and regulatory exposure. A few decision rules from the field:
Under about 250 employees with no full-time security leader: three scenarios in a spreadsheet, reviewed quarterly. A quantification platform can wait.
HIPAA covered entities and business associates: one of the three scenarios should be a reportable breach of protected health information, since notification costs, regulator scrutiny, and patient trust usually dominate the loss.
PCI DSS merchants: include a cardholder data compromise, with forensic investigation costs and card brand assessments in the range.
Public companies: tie scenarios to the materiality thresholds the disclosure committee already uses, since SEC rules require a Form 8-K within four business days of determining an incident is material.
Ready for more rigor: the Factor Analysis of Information Risk (FAIR) standard offers a structured way to model loss frequency and magnitude.
A three-scenario model with named owners is a natural first deliverable for a vCISO (virtual Chief Information Security Officer) or fractional CISO engagement, and it is the kind of work Purple Shield Security's vCISO services are built around. The model matters less than the habit it creates: every quarter, the same scenarios, the same owners, and a visible trend.
Can one risk model satisfy both the board and the cyber insurer?
One risk model should serve both the board and the cyber insurance underwriter. The two audiences need different levels of detail, but the facts underneath must match. Milenkovic warns that anything a company tells an underwriter has to hold up on the day it files a claim, so telling the board one story and the insurer another is a bigger problem than presentation.
Boards need decisions and the rationale behind them. Underwriters want the evidence underneath: control maturity, how long exposures stay open, and how fast the company expects to recover. Milenkovic notes that carriers now underwrite more granularly on controls, privacy exposure, and emerging AI risk, so the same data that drives the model should drive the insurance submission.
Timing matters. Milenkovic notes that UK cyber insurance pricing stayed soft through the second quarter of 2026, with better terms for buyers who can evidence strong controls, while specialist underwriters warn of an inflection point. For US mid-market firms, the renewal questionnaire is a useful stress test: any control answer that cannot be backed by system evidence points to the same gap in the risk model.
A strong board update built on this model has five parts, as Milenkovic's own sample update shows: a cause, a number, a decision, a date, and a link to the CFO's instruments, such as insurance limits and reserves.
Frequently asked questions
Do we need special software to quantify cyber risk?
No. A first model works in a spreadsheet with three loss scenarios and a low, likely, and high dollar estimate for each. Quantification platforms and FAIR-based tools make sense once the company has a reliable asset inventory and wants to automate inputs. Buying a tool before the scenarios and owners exist usually produces a polished dashboard nobody acts on.
Where do the dollar figures come from if we have never had a breach?
Start with data finance already owns: revenue per day of downtime, cyber insurance limits and retentions, incident response retainer rates, outside counsel fees, and penalty clauses in customer contracts. Write down every assumption and who made it. Replace estimates with real figures as incidents, tabletop exercises, and insurance renewals produce better data.
Who should sign a cyber risk acceptance?
The executive whose budget would absorb the loss should sign, not the IT manager or the security lead. Record the acceptance in a risk register with an expiry date, such as 90 or 180 days, so the decision is revisited rather than forgotten. A risk acceptance without an owner and a date is just an unpatched issue with paperwork.
How often should a cyber risk model be updated?
Review the model at least quarterly, and immediately after any material change: a new revenue system, an acquisition, a significant incident, or a cyber insurance renewal. Keep the same scenarios across quarters so leadership can see a trend. A trend line is more persuasive to a CFO than any single number.
Does cyber risk quantification help with cyber insurance renewals?
Yes. Underwriters price on evidence of controls, exposure windows, and recovery capability, which is the same data a loss-based model uses. Using one set of facts for both the board and the insurer also protects the company at claim time, when inconsistent answers on the application can become a dispute.
If your board is asking what security spending is worth and the honest answer is a vulnerability count, that gap is fixable. Purple Shield Security helps mid-market and enterprise leadership teams build their first loss-based risk model through risk assessment services and vCISO support, so the next budget conversation starts with a dollar range, an owner, and a decision.
