A resilience budget request usually dies in one of two ways. Either it arrives as a red-amber-green heat map, which finance cannot put into a spreadsheet, or it arrives as a single expected-loss figure calculated to the dollar, which finance rightly suspects was made up. Both get the same answer: "Let's revisit next cycle."
The fix is not more precision. It is a model simple enough for a finance team to check, honest about its uncertainty, and built to answer one question: at what point does this spending pay for itself?
What follows tracks one illustrative company from business impact analysis to budget request. Every number in it is invented and rounded on purpose.
Price the impact in terms finance recognizes
Most business impact analyses already rate impacts by category and time, as in "severe financial impact after 72 hours." Finance needs the same information in dollars per day, built from components it can verify:
- Lost margin, not lost revenue. If a day of downtime costs $1 million in sales, the business loses the contribution margin on those sales, not the full million. Using revenue is the fastest way to lose a CFO's trust.
- Deferred versus lost. Some orders come back after the outage. Some go to a competitor for good. Estimate the split with sales leadership.
- Extra expense. Overtime, expedited freight, temporary equipment, outside specialists, incident response firms.
- Contractual penalties. Fill-rate penalties, service credits, liquidated damages. Pull the actual contract terms rather than guessing.
- Regulatory and legal costs. Notification, fines where they genuinely apply, legal fees. Describe these qualitatively if you cannot size them honestly.
Impacts usually accelerate. Day one is often absorbed by workarounds and goodwill; by day five, penalties start and customers begin looking elsewhere. Model losses in time bands rather than as a flat daily rate. If your BIA did not capture how impacts grow over time, our guide to running a business impact analysis people actually finish covers how to collect it.
Expected loss, with ranges instead of decimals
Expected annual loss is frequency times severity. The formula is fine. The trouble starts when someone writes "annual probability: 3.47 percent." Nobody knows that, and putting it in the deck invites the CFO to doubt everything else on the page.
Use ranges instead:
- Frequency as a band, such as "between once in 10 years and once in 25 years" for an event of this severity, which works out to 4 to 10 percent a year. Say where the band came from (industry incident reporting, conversations with your insurer, your own near-miss history) and say plainly that it is a judgment.
- Severity as a low case and a high case, each built from the cost components above.
Then present expected loss as a range. The aim is not a precise number. It is to find out whether the decision changes anywhere inside the range. If an investment pays for itself across the whole range, the debate is over. If it pays only at one end, the useful conversation is about which end you believe, and that is a conversation finance teams are good at.
A worked example
Company P (illustrative): a mid-size packaging manufacturer with $300 million in annual revenue, two plants, and one ERP system that handles order entry, production scheduling and shipping. Two grocery chains account for about 30 percent of revenue, and their contracts carry fill-rate penalties.
Scenario: ransomware encrypts the ERP and its on-network backups. Recovery has never been tested end to end, and the IT team estimates 10 to 20 business days to rebuild.
Daily impact: at 250 shipping days a year, revenue is about $1.2 million a day. At a 35 percent contribution margin, that is about $420,000 of margin a day.
| Outage period | Assumption | Lost margin per day |
|---|---|---|
| Days 1 to 3 | Manual workaround ships about 60% of orders | About $170,000 |
| Day 4 onward | Workaround degrades and penalties begin | About $300,000, including penalties |
On top of that sits $1 million to $2 million of extra expense: incident response, overtime, expedited freight and rebuilding systems.
Severity:
- Low case, 10 days: (3 × $170,000) + (7 × $300,000) + $1 million, or about $3.6 million.
- High case, 20 days: (3 × $170,000) + (17 × $300,000) + $2 million, or about $7.6 million.
Frequency: 4 to 10 percent a year, the once-in-25 to once-in-10-years band.
Expected annual loss today: about $140,000 at the low end (4 percent of $3.6 million) and about $760,000 at the high end (10 percent of $7.6 million).
That range is wide, and that is acceptable. It still says something useful: the exposure is worth somewhere between a modest and a substantial sum each year, with a tail event that would dent the year's earnings. The full cost of ransomware downtime usually runs higher than first estimates, so resist the temptation to trim the high case.
Three options
Accept. No new spending. The company carries the exposure, partly offset by its existing cyber policy.
Transfer more of it. Raise the cyber policy limit for an added premium of about $60,000 a year. Insurance pays a share of business interruption loss and extra expense after the retention and any waiting period. It does not shorten the outage, may not cover contractual penalties, and does nothing about a grocery chain that moves its volume elsewhere. Our briefing on business interruption insurance explains what to confirm with a broker before relying on it.
Reduce it. Immutable backups, a documented and tested ERP rebuild, and a clean recovery environment (the approach covered in our piece on immutable backups and clean-room recovery), bringing recovery to 3 to 5 days. Cost: $350,000 one-time plus $100,000 a year. Spread the one-time cost over five years and the annualized cost is about $170,000.
With recovery in 3 to 5 days, severity falls to roughly $1 million to $2.1 million, and expected annual loss to about $40,000 to $210,000.
| Option | Annualized cost | Expected annual loss | Severe-case loss | What it does not fix |
|---|---|---|---|---|
| Accept | $0 | $140,000 to $760,000 | About $7.6M, partly insured | Everything |
| Higher insurance limit | About $60,000 | Lower net loss; outage unchanged | About $7.6M gross, less recoveries | Outage length, lost customers, possibly penalties |
| Faster recovery | About $170,000 | $40,000 to $210,000 | About $2.1M | Data theft, notification costs |
The reduction option lowers expected loss by about $100,000 a year at the low end and about $550,000 at the high end, against an annualized cost of $170,000. It does not pay at the bottom of the range and pays comfortably at the top. That is the honest answer, and it leads to a better question.
Find the breakeven, not the answer
Using midpoints, the investment cuts severity by about $4 million per event, from roughly $5.6 million to roughly $1.6 million. At $170,000 a year, it breaks even if an event like this happens more often than about once every 24 years.
Now the CFO is not being asked to accept a probability. The question is whether a company of this profile, with its only backups sitting on the same network as production, is likely to go more than two decades without a serious ransomware incident. Most finance teams can answer that, and the answer rarely favors doing nothing.
Then add what the model leaves out but finance will recognize: grocery contracts that could be lost outright, cyber insurance applications that routinely ask about backup and recovery controls, and the likely view of an auditor or examiner looking at an untested recovery plan. In this example the sensible recommendation is the reduction option, with the insurance limit revisited at renewal once the new controls can be shown to the underwriter.
Phase the spending so it earns trust
Large one-time requests make finance nervous, with good reason. Phasing helps when each phase delivers something measurable and gates the next:
| Phase | Spend | Delivers | Gate to the next phase |
|---|---|---|---|
| 1 (quarter 1) | $60,000 | Immutable copy of ERP data; documented manual order-entry process | Successful test restore of ERP data |
| 2 (quarters 2 and 3) | $220,000 | Clean recovery environment and rebuild runbook | Timed end-to-end rebuild within 5 days |
| 3 (quarter 4) | $70,000 | Same protection extended to warehouse and payroll systems | Annual recovery test schedule approved |
The three phases add up to the $350,000 one-time cost. If phase 1 shows the problem is smaller than feared, the company can stop there, and finance will remember that you offered the exit.
Metrics a finance team will trust
Finance trusts numbers that are demonstrated, comparable over time and hard to game. Good candidates:
- Demonstrated recovery time against target for each critical service, taken from the most recent test rather than the plan document.
- Share of critical services with a successful recovery test in the last 12 months.
- Expected-loss range before and after each investment, updated when assumptions change.
- Insurance limits and retentions compared with the modeled severe-case loss.
- Open audit and examination findings on continuity and recovery, with their ages. Our briefing on surviving a BCM audit or regulatory examination covers what examiners look for.
Skip metrics that measure activity instead of capability: number of plans written, training completion rates, page counts. They are easy to report and tell a CFO nothing about whether the money worked.
The one-page request
Before the budget meeting, fit the case on a single page:
- The exposure in one sentence: "A ransomware outage of our ERP would cost an estimated $3.6 million to $7.6 million."
- The frequency band, and where it came from.
- The options table: accept, transfer, reduce, each with an annualized cost.
- The breakeven: "This pays for itself if we expect such an event more often than about once in 24 years."
- The phased ask, with the gate for each phase.
- What you will report back, and when: test results, demonstrated recovery times, the updated loss range.
If the CFO can check every number on that page with a calculator and still disagrees, you have had a real argument about risk appetite. That beats another year of "revisit next cycle."
