Business Continuity vs Disaster Recovery: What Texas Businesses Actually Need

What is the difference between business continuity and disaster recovery?

Business continuity is the plan for keeping critical operations running while a disruption is happening. Disaster recovery is the plan for restoring the IT systems, applications, and data that the disruption took down. Continuity answers how the business survives the outage. Recovery answers how the technology comes back.

The two get blurred together constantly, usually because a vendor sells them as one line item called BCDR. That shorthand is fine for a quote. It’s a problem when it becomes the plan, because the parts of continuity that have nothing to do with servers quietly go unwritten. Your phone tree, your manual workaround for taking orders, your decision authority when the owner is on a plane. None of that lives in a backup console.

Here is the split in practical terms.

Read the bottom row twice. Those two lines carry the whole argument. Those are the two failures we see most often, and they aren’t the same failure. A company can have flawless backups and still lose a week because no one knew who was authorized to send customers to a backup process. Another can have a well-drilled staff who simply have nothing to log into.

Why “we have backups” is not a continuity plan

Backups are a component. One component. They’re not a plan, and they’re certainly not two plans. The federal standard for this work, NIST Special Publication 800-34, does not treat continuity and recovery as one document. It defines a business continuity plan, a disaster recovery plan, a continuity of operations plan, an information system contingency plan, and a cyber incident response plan as five distinct artifacts with different triggers and different audiences.

You don’t need five binders to run a 40 person company in Sugar Land. You do need to notice what the standard is telling you. The people who wrote the reference model for this concluded that one document cannot carry both jobs, because the questions are not related. What does the business do at 9am tomorrow is an operations question. How long until Exchange is back is an engineering question.

The honest version of this is that most small and mid-sized companies are further along on recovery than continuity, and it isn’t because they made a considered choice. Recovery has a product attached to it. Someone sells you backup software, you buy it, you have a thing. That feels like progress. Continuity has no product. It’s a conversation nobody schedules.

What a business continuity plan actually covers

A continuity plan is written for the people running the company, not the people running the servers. If your operations manager can’t use it during a bad week without calling IT, it isn’t a continuity plan. Ready.gov publishes a free framework that covers the same ground, and it is a reasonable place for a first draft.

• The critical function list. Which 5 or 6 things must keep happening for the business to still be a business. Payroll, order intake, patient scheduling, dispatch, invoicing. Everything else waits.
• Maximum tolerable downtime per function. Not per server. How long can order intake stop before you lose the customer rather than the order.
• Manual workarounds. The paper process, the shared phone number, the spreadsheet you fall back to. Written down, with the forms actually printed and stored somewhere reachable.
• Decision authority. Who declares an incident, who can authorize spend, who talks to customers, and who takes over if that person is unreachable. This is the single most skipped item.
• Communication paths that survive the outage. If your phone system and email are both Microsoft 365 and Microsoft 365 is the outage, you need a second channel agreed on in advance.
• Alternate work locations. Where people go if the building is unusable, and what they need to be productive there.
• Vendor and supply dependencies. The third parties whose outage becomes your outage, with contacts and contract terms attached.

Notice how little of that is technical. A good managed IT partner should be in the room for it, because the workarounds have to be realistic against what technology will actually be available. But the business owns the answers.

What a disaster recovery plan actually covers

The recovery plan is the technical counterpart. It assumes something is already broken and describes, step by step, how it comes back and in what order.

• A current system inventory. Every server, application, database, cloud tenant, and integration, with an owner and a tier. Plans go stale here first.
• Recovery order. Domain controllers and identity before applications, applications before reporting. Restoring in the wrong sequence wastes hours you do not have.
• Backup design. Where copies live, how often they run, how long they are kept, and whether at least one copy is immutable so ransomware cannot reach it.
• Failover targets. What actually happens when the primary is gone. A second site, a cloud instance, a virtualized copy running on the backup appliance itself.
• Runbooks per system. The literal steps, written so an engineer who was not there when it was built can follow them at 3am.
• Restore test results with dates. Not the backup success report. Proof that data came back, was readable, and how long it took.
• Recovery objectives per tier. The RTO and RPO numbers that make every decision above either adequate or not.

Backup design deserves a note. The 3-2-1 rule, meaning 3 copies on 2 media types with 1 offsite, is still the baseline that CISA references in its ransomware guidance. It’s also no longer sufficient on its own, because modern ransomware hunts backup repositories before it encrypts anything else. At least one copy has to be immutable or genuinely offline. If an administrator credential can delete it, so can an attacker holding that credential.

RTO and RPO are where the two plans meet

Two numbers connect continuity to recovery, and they are worth understanding precisely because almost everyone gets them backwards at least once.

RTO, the recovery time objective, is how long a system can be down before the damage is unacceptable. It looks forward. It drives architecture and spend. RPO, the recovery point objective, is how much data you can afford to lose, measured in time. It looks backward. It drives how often backups run.

A 4 hour RTO with a 24 hour RPO means you are back online by lunch, working from yesterday’s data. Whether that’s fine or catastrophic depends entirely on the business, which is exactly why leadership sets these numbers and IT prices them. Handing the decision to IT alone produces one of two outcomes. Either everything gets classified as critical and the quote is absurd, or nothing does and you find out in the worst way.

A tiering model we use with clients looks roughly like this. The tiers matter more than the exact hours.

The exercise that makes this real is short. Genuinely short. Take your critical function list from the continuity plan, ask which systems each function depends on, and assign the tier from the function down to the system. Do it in that direction and the tiering argues itself. Do it from the server list up and every system will somehow turn out to be Tier 1.

Where Texas businesses get this wrong

Patterns repeat. These are the ones worth naming, in rough order of how often we find them.

1. Backups that have never been restored. A green dashboard confirms a job finished. It doesn’t confirm the data is usable, that the retention covers the incident, or that anyone knows the decryption key. Until a real restore has been timed, the RTO on paper is a guess.
2. Treating Microsoft 365 as its own backup. Microsoft protects the platform. Your data inside it is your responsibility, and the native retention windows are shorter than most owners assume. A deleted mailbox or a ransomware-encrypted SharePoint library after the window closes is simply gone.
3. A continuity plan that only IT has read. If the plan lives on a network share that the outage took offline, it doesn’t exist during the outage. Print it. Put a copy in a car. Boring advice, and it works.
4. Recovery objectives nobody signed off on. An RTO written by a technician is a technical preference. An RTO signed by the owner is a business commitment with a budget behind it. Only the second one survives a real incident.
5. Planning for the fire and not the Tuesday. Hurricanes and floods get the attention. The far more common event is ransomware, a failed migration, or a single administrator account getting phished. Your plan should handle a boring disaster well before it handles a dramatic one.

That last one deserves the honest correction. We used to lead every one of these conversations with weather, because in Houston that lands. It was the wrong emphasis. The incidents that actually take Texas companies offline for days are overwhelmingly digital, and ransomware preparation belongs at the front of the plan, not in an appendix.

The data backs that up. Sophos found in its State of Ransomware 2025 report that just over half of victims, 53%, were recovered within a week, with a mean recovery cost of $1.53 million excluding any ransom payment. A week offline is survivable for some businesses and terminal for others. Which one you are is a continuity question you should answer before you have to.

How to build both without hiring a risk team

You don’t need a consultant and a 90 day engagement to get to a defensible position. You need about 4 working sessions and the discipline to finish them.

1. List critical functions, not systems. Get leadership in a room for 2 hours. Name the 5 or 6 things the business cannot stop doing, and how long each can pause before real damage starts. This is your business impact analysis, and at this size it fits on one page.
2. Map functions to systems. IT translates each function into the applications and data it depends on, then assigns tiers. Anything that supports no critical function drops to Tier 3 or lower, which is usually where the budget relief comes from.
3. Set RTO and RPO per tier and price them. Leadership picks the targets, IT quotes what each target costs. Adjust until the numbers and the budget agree. Write down what you accepted and why.
4. Write the recovery runbooks. Per critical system, in order, specific enough for someone unfamiliar to execute. Include credentials location, dependencies, and who to call.
5. Write the continuity plan. Decision authority, communications, manual workarounds, alternate locations. Keep it short. A plan people will actually open beats a thorough one they won’t.
6. Test, then correct. Restore something real and time it. Run a tabletop walkthrough of a ransomware scenario with the leadership team. Both will expose gaps, which is the entire point.

On cadence, restore tests should run quarterly at minimum, and a tabletop exercise annually. Reset the clock on both whenever you change core infrastructure, move a system to the cloud, or acquire another business. Plans decay fastest right after the thing that made them out of date.

What Texas changes about the math

Geography and state law both push on these plans in ways a generic template won’t account for.

On the Gulf Coast, the continuity question is not only whether the office floods. It’s whether staff can reach it, whether they have power at home, and whether your primary and backup copies are far enough apart that one storm cannot take both. Houston businesses have their own version of this, which we cover in the hurricane IT prep checklist. Winter Storm Uri in February 2021 made the same point statewide from the opposite direction, when a grid failure took out companies hundreds of miles from any coastline. North Texas adds hail and tornado exposure to the list.

Then there is the legal layer. Texas Senate Bill 2610 took effect on September 1, 2025 and created a safe harbor from punitive damages for businesses under 250 employees that implement and document a recognized cybersecurity framework. Companies with 20 to 99 employees are pointed at CIS Controls Implementation Group 1, and those with 100 to 249 at fuller frameworks such as NIST CSF or ISO 27001. Backup, recovery, and incident response are explicit controls in every one of those frameworks, which means the recovery work you were already considering now carries a legal benefit. Our SB 2610 compliance checklist walks through what qualifies.

Regulated Texas businesses stack requirements on top of that. Healthcare practices answer to HIPAA contingency planning rules as well as state law, which we compare in HIPAA vs Texas SB 2610. Defense suppliers carry CMMC obligations. In each case the recovery plan stops being optional documentation and becomes evidence.

One number worth keeping in view. FEMA has estimated for years that roughly 40% of small businesses never reopen after a disaster, a figure echoed across federal preparedness guidance. The businesses that do reopen are rarely the ones with the best technology. They are the ones who decided in advance what work had to continue and how.

Questions Texas business owners ask about continuity and recovery

Do we need both plans, or is one enough?

If we can only do one this quarter, which comes first?

How often should a disaster recovery plan be tested?

Does cloud software mean we already have disaster recovery?

What does Texas SB 2610 require for backup and recovery?

Who should own the business continuity plan?