Ransomware Is a Balance Sheet Event

Most finance leaders receive one cybersecurity briefing a year. It covers the security budget, the tooling roadmap, and the training completion rate. It is a useful conversation and it is almost entirely about prevention.

What it rarely covers is the number that will actually land in your P&L if prevention does not hold, and how much of that number is already determined by decisions your organization has made or deferred.

I want to make the case that this belongs in the CFO chair, not because finance should run security, but because the shape of the exposure is financial and the controls that change it are capital decisions.

The ransom is the smallest number on the page

When a ransomware incident makes the news, the ransom is the figure that gets quoted. In the actual accounting, it is rarely the largest line and it is sometimes not a line at all.

The costs that show up instead are these. Incident response and forensics, engaged at emergency rates. Outside counsel. Rebuilding and restoring systems, which is labor measured in weeks and often includes contractors. Business interruption for however long operations are degraded, with fixed costs continuing throughout. Notification and regulatory response, with deadlines that vary by jurisdiction and do not pause because your systems are down. Customer attrition, which arrives on a lag and is the hardest to model. Then the insurance consequences, which include the retention you absorb and the premium you renegotiate at your next renewal from a materially weaker position.

There is also a cost that never appears in any report. Your finance organization spends a quarter on incident work instead of the close, the forecast, and whatever you were actually trying to accomplish this year.

IBM's Cost of a Data Breach Report for 2026 put the global average at 4.99 million dollars, a 12 percent increase and the highest figure in the twenty years the study has run. The US average was 11.5 million. Notably for anyone modeling this, IBM found that detection and escalation costs together with lost business accounted for nearly two thirds of the total. The direct technical remediation is not where most of the money goes.

The one differential you can forecast

Almost everything about a cyber incident is difficult to forecast. Whether you are attacked, when, by whom, and how far they get are all genuinely uncertain, and I am skeptical of anyone who prices that precisely.

One thing is not uncertain, and it is the number I would put in front of a board.

Sophos studied outcomes for nearly 3,000 organizations hit by ransomware and separated them by a single variable: whether the attacker succeeded in compromising their backups. Median overall recovery costs for organizations whose backups were compromised came to 3 million dollars. For organizations whose backups were intact, the figure was 375 thousand dollars. That is an eight times difference, and it excludes any ransom paid.

The same split shows up in recovery time. Organizations whose backups survived were nearly twice as likely to be fully recovered within a week.

This is not a risk model. It is an observed differential between two populations, separated by one control. And unlike almost every other variable in cybersecurity, it is a control you can verify the state of today, before anything happens.

Why this gets crowded out of the budget

Prevention spending has a structural advantage in every budget cycle I have ever sat through. It is continuous, it is operational, and it produces monthly metrics. Recovery capability is lumpy, often capital, and produces no metric at all in the years it is not needed.

So it loses. Not because anyone decides it should, but because it is the line that can always be deferred one more cycle without an immediate consequence.

The counterargument is that prevention and recovery are not competing for the same job. Prevention determines how often you are attacked. Recovery determines what an attack costs you. The first number has been improving across the industry. The second one has not. Sophos found the average cost of recovering from a ransomware attack rose 11 percent last year, to 1.7 million dollars excluding any ransom.

Both deserve a budget line, and they should be evaluated against different questions.

There is a familiar version of this distinction in enterprise risk management. Frameworks separate controls that reduce the likelihood of an event from controls that reduce its impact. Prevention is the first category. Recovery is the second. Both belong in the risk register, both carry real cost, and both are supposed to be tested.

That last part is where it breaks down. If you are carrying a material risk in your ERM model and your response to it is a control nobody has exercised, you do not have a control. You have an assumption with a budget line attached. We would not accept that on the financial reporting side, where testing operating effectiveness is the entire point. Recovery capability deserves the same standard, and the test is not whether a backup job completed successfully. It is whether a full restore finished inside the recovery time you committed to.

Your insurer has already made this a finance conversation

If you needed a forcing function, underwriting has become one.

Cyber insurance applications used to be a questionnaire. They are now closer to a technical audit, and the control set that carriers treat as pass or fail has converged. Multifactor authentication, endpoint detection, a documented and exercised incident response plan, and backups that are immutable or air-gapped with documented restore testing.

Two things follow from that, and both sit with finance.

First, the presence or absence of these controls is now priced into your premium and your available limits. Second, and more consequential, the application is an attestation. If you attest to a control you do not actually have, or that is not enforced in the way the underwriter understood it, you are exposed to a coverage dispute at precisely the moment you need the policy to respond. The signature on that document is usually yours.

I would treat the underwriting questionnaire less as a compliance chore and more as free consulting. Carriers see claims data across thousands of organizations. Where they have converged on a required control, they have done so because it changed outcomes.

Three numbers to bring to your next board meeting

What an hour of downtime costs us. Revenue that does not happen, plus fixed costs that continue, plus the labor cost of everyone who cannot do their job. Most organizations have never calculated this, which means every recovery investment gets debated without a denominator.

Our tested recovery time, against our committed one. Not the recovery time objective in the policy document. The elapsed time from the last full restore test, measured and written down. If those two numbers are far apart, that gap is your real exposure and it is currently unfunded.

What a denied or reduced claim would cost us. Take your current cyber policy limit and ask what the balance sheet looks like if it responds at half or not at all.

None of these require a security background to ask, and all three will tell you more about your actual exposure than a tooling roadmap will.

The decision underneath all of it

You cannot forecast whether you will be attacked. You can forecast, with reasonable confidence, what the two possible outcomes cost, because the industry has now measured both of them at scale.

That turns a risk question into a capital allocation question, and capital allocation is a conversation finance should be leading.

About the EchoLeaf SafeRoom™

The EchoLeaf SafeRoom™ is a physically air-gapped, immutable vault. Once data is written it cannot be encrypted, altered, or destroyed, and it is not reachable through production credentials or production network paths. It is built for the side of the differential you want to be on. That's how you get back to live in hours, not weeks.

If you want to assess your own position, our [Ransomware Recovery Readiness Checklist] walks through thirty specific controls, and it is written to be completed by your infrastructure and security leads and then reviewed by you.