The cost of downtime: the cyber loss nobody puts on the invoice

Ask a business owner what a ransomware attack costs and they will quote the ransom. Ask them about downtime and they go quiet, because nobody hands you an invoice for it. There is no line item that says "three weeks of half-working operations." But in most serious incidents, business interruption is the largest cost, larger than the ransom, often larger than the recovery, and it is the one companies estimate worst.

The arithmetic, and the number everyone fumbles

The skeleton is simple:

Downtime cost = daily revenue × days down × revenue-loss fraction

Daily revenue is easy. Days down you can estimate. The fraction is where people go wrong, in both directions.

Some assume zero, as if a few days offline rounds away. Others assume 100%, as if every hour down is an hour of revenue vaporized. Both are wrong. The reality is partial. During an outage some of the business keeps limping: phones work even if the system does not, staff process things manually, customers wait instead of leaving. And a chunk of "lost" sales is deferred, not gone, because the customer still needs what you sell and buys it next week. So the honest loss fraction sits well below 100%. In our model we use about 30% of daily revenue lost while degraded, which is deliberately conservative and matches what survivable incidents actually look like.

Thirty percent of daily revenue for two weeks is still a serious number for a mid-market firm. That is the point. You do not need apocalyptic assumptions for downtime to dominate the bill.

How long you are actually down

Recovery time is not a constant, and it tracks size and preparation more than the malware. Our model anchors operational downtime by company size: roughly 3 days for a micro business, 5 for a small firm, 8 for a mid-market company, and 12 or more once you are large, because bigger estates mean more systems to rebuild and more interdependencies to untangle. Sophos's ransomware data lands in a similar place: full recovery routinely runs into weeks for larger victims.

But these are averages for the prepared. The variance is enormous, and it is almost entirely a function of whether you can actually restore.

Your RTO is probably fiction

Most companies have a recovery time objective written down somewhere. Four hours. One business day. Whatever the document says. During a real incident that number frequently turns out to be aspirational, and the gap is where the cost lives.

The failure modes are boringly consistent. The backups existed but lived on a share the ransomware reached and encrypted too, because they were online and writable. Nobody had ever tested a full restore, so the team discovers mid-incident that restores run at a crawl, or that the last good backup is older than anyone thought. The RTO assumed you would restore one critical system, but everything depends on Active Directory and that has to come back first, clean, before anything else is trustworthy. The runbook was written by someone who left, and the people doing the recovery at 3am are improvising.

Every one of those turns a planned two-day recovery into a real two-week one, and the downtime cost scales linearly with it. This is why disaster recovery is not a backup product you buy. It is a tested process you rehearse. The companies that recover fast are the ones that did a real restore drill last quarter and found the broken things on a Tuesday afternoon instead of during the worst week of their year.

The costs you will not see for months

Direct revenue loss is the part you can model. There is a tail you cannot, and it is real. Idle payroll while staff cannot work. Overtime and contractor cost to dig out of the backlog once you are back. Missed contractual deadlines and the penalties attached. And the slow one: customers who quietly went elsewhere during the outage and never came back. Churn from a visible incident does not show up in the recovery budget, but it shows up in next year's revenue.

You cannot put a precise figure on the churn. You can refuse to pretend it is zero.

Make downtime boring

The entire cost of business interruption collapses if you can restore quickly and confidently, which loops straight back to backups and rehearsal. Offline or immutable backups so they survive the attack. A tested restore on a real schedule, not a green checkmark in a backup console. A recovery runbook someone has actually run. None of it is exciting. All of it is cheaper than two extra weeks down.

Model the downtime line for your own business by size and revenue alongside the four other scenarios, and the methodology shows every assumption including that loss fraction. The ransom gets the headlines. The downtime gets the money.