Downtime and ransomware cost far more than the invoice for IT repair or the ransom figure on the extortion note. The real bill includes lost revenue while systems are unavailable, emergency remediation, customer attrition, and the cost of running a business by hand while the tools it depends on sit offline. We see the same pattern across client environments: the plan existed on paper, but nobody had actually run it before the day it mattered. Most owners only see the full total after an incident forces them to add it up.
For most SMBs, the real cost of downtime and ransomware runs well beyond the ransom demand itself. It includes lost sales during the outage, emergency IT labor, breach notification and legal costs, higher insurance premiums, and customers who leave once they learn systems went down. The ransom, when one is paid, is usually the smallest line item.
There is no single number that applies to every company. The real figure depends on your industry, your size, and how much of your operation runs through digital systems, but the pattern holds everywhere: the longer systems stay down, the faster the cost curve bends upward.
A retail or professional services business loses sales the moment point-of-sale, email, or scheduling goes dark, and those transactions rarely come back later in the day. A manufacturer or distributor loses more than sales. Idle staff still draw a paycheck, shipping windows get missed, and contract penalties kick in when orders arrive late. None of that shows up on an IT invoice, which is exactly why owners underestimate it until they live through it.
Professional services and healthcare practices carry a different version of the same math. Billable hours do not get recovered once the day is gone, and a scheduling or records system outage does not just cost revenue, it can trigger compliance obligations around patient records and appointment continuity. The dollar figure changes by industry, but in every case the business is paying for downtime whether or not a check gets written for it.
The ransom demand is usually the smallest line item in a ransomware event, not the largest. The FBI's Internet Crime Complaint Center 2025 annual report recorded more than 3,600 ransomware complaints with reported losses above $32 million, and the report notes those adjusted figures do not normally include the cost of lost business, downtime, wages, or equipment. The number federal law enforcement tracks is close to the ransom and the direct cleanup cost. Everything downtime actually does to your business sits outside that figure.
Once an attack succeeds, the costs branch out in directions most owners never budget for:
Cyber insurance adds its own wrinkle. Insurers increasingly require proof of tested backups, multifactor authentication, and endpoint monitoring before they pay a claim in full, and a business that cannot produce that proof can see a claim reduced or denied. The policy bought to cover this risk only works if you can document the controls the underwriter assumed you had in place.
Add those together and the ransom payment, when one is even made, rarely accounts for half of what the incident costs before the business is fully back to normal. The Verizon 2026 Data Breach Investigations Report found that ransomware now shows up in 48 percent of all breaches, which means this is closer to a when than an if for most companies. The IBM Cost of a Data Breach Report 2026 put the global average cost of a breach at $4.99 million, a record high and a reminder that these costs keep climbing across organizations of every size, not only the enterprises that make headlines.
Ransomware rarely announces itself immediately. Attackers typically sit inside a network for days or weeks before triggering encryption, moving between systems, elevating access, and locating backups to disable before locking anything down. By the time your team notices something is wrong, the attacker has usually already mapped the environment and picked the moment that does the most damage.
Once the encryption event hits, recovery is not a single afternoon. Containment comes first: isolating infected systems, confirming what was touched, and cutting off the attacker's access before restoring anything. Rebuilding starts only after that, and rebuilding from a clean, verified backup takes hours to days depending on the volume of data and how recently the backup was tested. A business without a tested RTO finds out its real recovery timeline during this exact window, which is the worst possible time to learn it is longer than the business can afford.
Recovery Time Objective and Recovery Point Objective are the two numbers that turn disaster recovery from a philosophy into a plan you can hold your provider to. NIST defines RTO as the length of time your systems can stay in recovery before the outage starts damaging the business, and RPO as the point in time your data must be restored to, counted backward from the last clean backup. Together they set the line between an outage you can absorb and one that changes the trajectory of the business.
Most SMBs have never set either number on purpose. They inherited a backup schedule from whoever configured the server years ago and assumed it was adequate because nobody had needed to test it. That assumption is exactly what turns a manageable outage into a costly one, because a backup that has never been restored is a guess, not a plan.
| Question it answers | RTO | RPO |
|---|---|---|
| What it measures | How long systems can stay down before the cost becomes unacceptable | How much data loss the business can absorb, counted back from the last clean backup |
| Who should set it | Leadership, based on revenue and contract exposure | IT, based on backup frequency and verified restore testing |
| How it gets proven | Timed recovery drills | Backup restore verification |
A written business continuity plan and a plan your team has actually rehearsed are two different things, and the gap between them only shows up during a real incident. An untested plan fails in predictable ways: contact lists are outdated, backup credentials have expired, and the one person who knew how to execute the failover left the company last year.
None of that surfaces until the day the plan is needed, and by then the recovery time it promised on paper is nowhere close to what the business actually experiences. A tested plan gets rehearsed on a schedule, with a real failover and a real restore, not a document review once a year. If your last test was a conversation instead of a drill, you do not have a tested RTO. You have a hope.
A tabletop exercise, run once or twice a year, is the cheapest way to close this gap. Walk through a simulated outage with the actual people who would respond, not just the plan on paper, and you find the outdated phone number or the missing credential before an attacker does. Skipping this step because the business is busy is exactly how untested plans stay untested for years.
A business can have a well-tested internal plan and still go down because of something entirely outside its control. The more a company depends on outside providers for functions it cannot run without, the less control it has over its own recovery timeline, no matter how well the internal plan is written.
Common dependencies show up in nearly every SMB outage:
Concentration makes this worse. A business running its email, payment processing, and core application through a single provider has one point of failure it does not control, and that provider's outage becomes the business's outage with no internal lever to pull. Diversifying critical dependencies where practical, and knowing exactly which ones cannot be diversified, is part of an honest continuity plan.
A continuity plan that only covers systems you own and ignores these dependencies is incomplete. CISA's guidance on ransomware puts maintained, tested, offline backups at the center of recovery for exactly this reason: when a vendor, a cloud provider, or your own systems go down, a verified backup is often the only recovery path that does not depend on someone else's timeline. A managed IT and security program that actively watches these dependencies, not just your own servers, is the difference between learning about a vendor outage from a client and learning about it from your own alerts.
Put real numbers on RTO and RPO instead of assuming last year's backup schedule is good enough. Test the plan on a schedule instead of waiting for an actual outage to find the gaps, and make sure the plan accounts for the vendors and infrastructure you do not control, not just the servers you own.
If you have not put your current setup through a real assessment recently, a cybersecurity assessment gives you a specific, prioritized list of what to fix instead of a general sense that you should be doing more. If you are choosing a provider to help close the gap, the Securafy Cybersecurity Buyer's Guide lays out the questions to ask before you sign a contract, so you are not finding out what your provider actually covers during the next outage.
The cost of downtime and ransomware is not fixed. It is a direct result of whether your RTO, RPO, and continuity plan are documented, tested, and built around the vendors and systems you actually depend on.
If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. Securafy AI University gives your people role-based AI training with security built into the material, not bolted on afterward.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.