On the afternoon of April 26, 2024, an EF4 tornado tracked through Elkhorn, on the northwest edge of the Omaha metro, in what the National Weather Service later confirmed was the strongest tornado to hit the area in nearly a decade. Hundreds of homes and businesses across Douglas and Washington counties were damaged or destroyed during the hour it was on the ground. In the weeks that followed, many of the affected businesses discovered that their data remained intact, but the challenge lay in resuming operations.
That’s the part backups don’t cover. A backup is a copy of your data, kept separately from whatever just happened to your building or your network. It says nothing about how the business starts serving customers again or who is responsible for making that happen once the systems are down. Most disaster recovery planning in Omaha stalls right there, at the point where data protection and operational recovery quietly become two different problems.
A backup and a recovery plan solve different problems
The Cybersecurity and Infrastructure Security Agency treats backups as a baseline protection, a secure, separate copy of your data you can restore from after ransomware, hardware failure, or physical damage. Its own guidance explains why backups alone aren’t the finish line. Ransomware was present in 44% of the breaches Verizon analyzed in its 2025 Data Breach Investigations Report, and a copy of your data does you no good if nobody has tested whether, or how fast, it can be restored. CISA recommends regular restore testing for exactly this reason.
A disaster recovery plan covers more ground than that. FEMA’s Ready.gov guidance describes an IT disaster recovery plan as something built alongside your broader business continuity plan, with recovery priorities and timelines set through a formal review of what each system and process is worth to the business. In practice, that means defining how long each system can be down and how much data loss is tolerable before the damage becomes serious.
What a real plan pins down
Two terms sit at the core of any real DR plan. The recovery time objective is how long a system can be down before it starts hurting the business in a way that matters. The recovery point objective is how much data you can afford to lose, measured in time, between your last good backup and the moment things went wrong.
These numbers aren’t the same across every system, and treating them as if they are is where a lot of plans go wrong on paper before they’re ever tested in practice. A 30-person accounting firm might tolerate its internal file archive being down for three days. Payroll and client billing are a different story. An outage there during the wrong week can damage client trust in a way that’s hard to repair. A real plan sets different recovery targets for different systems, names who own getting each one back online, and spells out who talks to clients and vendors while that’s happening. Job titles aren’t enough here. People change roles, take vacation, or leave the business, and a plan built around the title IT manager, rather than a named person and a backup person, is a plan that stalls at exactly the wrong moment.
The oversights that only show up on the day it counts
Backups exist, but nobody has restored from them in a test setting, so there’s no real answer for how long a full restore takes under pressure. One person holds the credentials or knowledge required to start recovery, and they’re unreachable when it matters most. The plan itself lives on a shared drive on the same network that just went down or assumes internet access that the incident has taken away. And there’s rarely anything in writing about what staff should tell clients or vendors in the first hour, so that job falls to whoever’s phone rings first.
These oversights are common precisely because they only reveal themselves under the exact conditions a plan is supposed to cover.
Where to start, realistically
A finished, formal plan isn’t a prerequisite for making progress right now. Start by listing your critical systems in order of what stops the business from operating if it goes down. Your line of business application comes before your intranet. Your billing system comes before your archived files. Set a recovery time and recovery point target for each one, using Ready.gov’s business impact analysis approach as a starting framework if you don’t already have your own. Name an owner and a backup owner for each system, using individual names so the plan doesn’t stall when someone is on leave. Then run one test. Pick a single system and restore it from backup on a set date. That gives you a real, measured restore time to plan against.
Data protection and recovery planning is one of the areas our cybersecurity services team works through with clients directly, alongside the technical defenses and monitoring built around it. Whether that planning currently belongs to an internal team or an outside IT support partner, the plan itself needs to exist somewhere your business can reach it when the network it depends on is the thing that’s down.
A backup preserves your data. Whether the business can act on that data while the systems are down is the job of a disaster recovery plan. Confusing the two usually becomes clear at the worst possible time, when a business most needs to prove it can still open its doors.
