Business continuity is an operational discipline, not a backup product. The organizations that recover fastest decided in advance what has to come back first and proved they could do it.
Uptime Institute's 2026 Annual Outage Analysis found that 57 percent of operators surveyed put the cost of their most recent major outage above $100,000, with one in five above $1 million.
Attackers now go after the recovery path directly. Sophos research found that 94 percent of ransomware victims said adversaries attempted to compromise their backups.
Recovery time and recovery point objectives are business decisions, not technical settings, and they should be set system by system.
Regulators are moving from "have a plan" toward "prove you can restore," including a proposed 72 hour restoration requirement in healthcare.
If you cannot say how long your ERP would take to come back today, you do not have a recovery plan. You have a hope.
Ask an IT team whether backups are running and you will almost always get a yes. Ask when someone last restored a production system from those backups, in a timed exercise, with the network down, and the room usually goes quiet. That gap between a green dashboard and a proven recovery is where business continuity services earn their keep. It is also where most mid sized organizations are far more exposed than they believe.
The cost of finding out the hard way keeps climbing. Uptime Institute's 2026 Annual Outage Analysis reports that 57 percent of operators surveyed said their most recent major outage cost more than $100,000, and for the second year running, one in five put the figure above $1 million. Those numbers are not reserved for hyperscalers. A 200 person manufacturer in Grand Rapids that loses ERP, shipping, and label printing for a day and a half is working the same math with fewer people to absorb it.
What Are Business Continuity Services, and What Do They Cover?
Business continuity services cover the planning, technology, and testing that keep an organization operating through a disruption and get critical systems back within a defined window. The scope is wider than storage. It includes identifying which processes cannot stop, mapping the systems those processes depend on, setting recovery targets, protecting the recovery path itself, and rehearsing the whole thing before an incident forces the issue.
That last piece is where most programs are thin. Plenty of organizations have purchased the technology. Far fewer have run the exercise.
Business Continuity Planning vs. Disaster Recovery Planning
The two terms get used interchangeably, and the distinction matters more than it sounds. Business continuity planning asks how the organization keeps serving customers during a disruption, including manual workarounds, communication, and staffing. Disaster recovery planning is the technical subset: how systems, data, and infrastructure get restored, in what order, and how fast.
A hospital that can chart on paper for six hours has a continuity plan. A hospital that can bring the EHR back in six hours has a recovery plan. You need both, and they should be written by people who have talked to each other.
The Dependency Map Most Organizations Skip
Recovery order is usually guessed rather than derived. The finance team assumes ERP comes first, the plant assumes the MES comes first, and nobody has checked what each one actually depends on. Restoring an application before its identity provider, license server, or database is online just burns hours you do not have.
A dependency map is unglamorous work and it is the single highest return hour in the entire process. The same discipline that produces a documented risk assessment applies here: findings, owners, and dates. It turns an argument during an outage into a checklist written when everyone was calm.
Why Do Backups Fail Exactly When You Need Them?
Backups fail at restore time because they were designed to satisfy a job status, not a recovery objective. The job completes, the dashboard turns green, and nobody validates that the resulting copy is complete, clean, isolated from the production domain, and restorable inside the window the business assumes.
Attackers understood this before most boards did. Sophos research on compromised backups found that 94 percent of organizations hit by ransomware said the attackers attempted to compromise their backups, and when those attempts succeeded, overall recovery costs ran roughly eight times higher and victims were nearly twice as likely to pay. CISA's #StopRansomware Guide is direct about the countermeasure: keep offline, encrypted backups of critical data and regularly test their availability and integrity in a disaster recovery scenario. Immutability and isolation belong to your layered cybersecurity controls, not to a storage checklist.
Five Ways a Backup and Disaster Recovery Plan Fails Quietly
The backup account is a domain admin. One compromised credential reaches production and the recovery copies in the same motion. If your backup system trusts the same directory as everything else, it is not a separate line of defense.
Nothing is immutable. Snapshots that can be deleted by an authenticated session are inventory, not insurance.
Restores are never timed. A restore that technically works but takes 40 hours fails a 12 hour objective. Untimed tests hide that completely.
Coverage drifts. A new SQL instance, a new file share, a new SaaS tenant, and six months later a system nobody protected is carrying a core process.
Configuration is not captured. Data comes back and the environment does not. Firewall rules, certificates, integrations, and application settings are frequently the long pole in the rebuild.
What Does an Hour of Downtime Actually Cost You?
More than the number in most budgets, because the visible line items are the smallest part. Idle labor, expedited freight, contractual penalties, overtime to recover backlog, and the customer who quietly sends the next order somewhere else all belong in the total.
Manufacturers carry an outsized share of this exposure. Dragos tracked 119 ransomware groups affecting roughly 3,300 industrial organizations in 2025 in its 2026 OT Cybersecurity Year in Review, up from 80 groups the prior year, with manufacturing accounting for more than two thirds of victims. Dragos also flags a pattern worth internalizing: when ransomware encrypts the virtualization layer hosting OT applications, operators lose visibility and control even though the physical equipment is untouched. In manufacturing and OT environments, the hypervisor is production infrastructure.
Here is the arithmetic, using illustrative figures rather than published averages. A 250 person manufacturer loses ERP and shipping for eight hours. Roughly 180 staff are unable to work at a fully loaded $38 per hour, which is about $54,700 in idle labor alone. Add a single day of missed shipments against a $95,000 daily revenue run rate, then expedited freight to catch up, then two engineers on recovery for three days. The eight hour event is a six figure event before anyone opens the incident invoice.
Idle labor. How to calculate it: Affected headcount x hours x fully loaded rate. Illustrative eight hour example: 180 x 8 x $38 = $54,700.
Lost or delayed output. How to calculate it: Daily revenue run rate x portion of day lost. Illustrative eight hour example: $95,000 x 1 day = $95,000.
Recovery labor. How to calculate it: Internal and external hours at incident rates. Illustrative eight hour example: 2 engineers x 3 days.
Catch up costs. How to calculate it: Overtime, expedited freight, penalties. Illustrative eight hour example: Varies by contract terms.
Customer impact. How to calculate it: Churn risk, missed SLA credits. Illustrative eight hour example: Hardest to quantify, easiest to underestimate.
Figures above are illustrative and meant to be replaced with your own numbers.
How Do RTO and RPO Turn Good Intentions Into a Plan?
Recovery time objective defines how long a system can be down. Recovery point objective defines how much data you can afford to lose, measured backward from the moment of failure. Together they convert a vague desire to "get back fast" into engineering requirements and a budget conversation.
The mistake is setting one pair of numbers for the whole environment. Protecting everything at the same tier is expensive and, worse, it flattens priorities during an incident when priority is the only thing that matters. Tier the environment instead, and make the business owner of each process sign off on the target. This is the point where business resilience stops being a value and becomes a measurable commitment.
Tier 1. Example systems: ERP, EHR, MES, identity, core network. What the target should reflect: Processes that halt revenue or patient care within hours.
Tier 2. Example systems: File shares, email, line of business apps. What the target should reflect: Painful within a day, survivable with workarounds.
Tier 3. Example systems: Reporting, archives, internal tooling. What the target should reflect: Restored after the business is running again.
Two rules keep this honest. Every target gets validated by an actual timed restore, never an estimate from a vendor datasheet. And every target gets revisited when the environment changes, because the migration that moved your ERP to a new platform almost certainly changed what recovery looks like.
What Does Compliance Require for Business Continuity Planning?
More than it used to, and the direction of travel is clear. The HIPAA Security Rule already requires a contingency plan covering data backup, disaster recovery, and emergency mode operations. The proposed update HHS published in January 2025 goes further, calling for written procedures to restore critical systems and data within 72 hours of a loss and a criticality analysis that ranks systems for restoration priority. That rule remains a proposal, not law, but it signals exactly where scrutiny is heading for healthcare IT environments.
Manufacturers see the same pressure from a different direction. CMMC and TISAX assessments both examine recovery capability, and defense supply chain requirements reach organizations that never considered themselves regulated. Assessors increasingly want evidence: test records, restoration logs, documented objectives. Documentation with no timed restore behind it does not survive compliance readiness work or an actual assessment.
How Do Business Continuity Services Fit Into a Wider IT Strategy?
They belong in the same conversation as security and operations, because in practice they are the same conversation. Ransomware is a continuity event. A failed hypervisor upgrade is a continuity event. A regional ice storm that takes out power to a plant for two days is a continuity event. Treating business resilience as a separate project managed by a separate vendor is how gaps end up living in the seams between providers.
That argues for a single accountable owner across fully managed or co-managed IT operations, security, and recovery. It also argues for proximity. When a site needs hardware staged, a rebuild supervised, or someone physically present at 6 a.m., a provider four hours away shows up and a national remote operation opens a ticket. Great Lakes organizations feel this every winter, and severe weather rarely announces itself in advance.
Frequently Asked Questions
How often should a disaster recovery plan be tested?
At least annually for a full exercise, with targeted restore tests quarterly, and always after a major environment change such as a migration, a new ERP module, or a network redesign. Untested plans age faster than most teams expect.
Is cloud infrastructure automatically backed up?
No. Most cloud and SaaS platforms operate a shared responsibility model where the provider guarantees platform availability and the customer remains responsible for their own data, retention, and restoration. Microsoft 365 and Azure workloads both need deliberate backup and disaster recovery design.
What is the difference between high availability and disaster recovery?
High availability handles component failure inside an environment, usually through redundancy and automatic failover. Disaster recovery handles the loss of the environment itself, including corruption and encryption that replication will happily copy to the standby site.
Where should a business continuity planning effort start?
Start with a business impact analysis: which processes cannot stop, what they depend on, and how long the organization can operate without them. Every technical decision that follows depends on those answers, and skipping this step is why so many plans protect the wrong systems first.
Find Out What Your Recovery Actually Looks Like
Most organizations do not need another backup product. They need an honest assessment of what would happen if a core system disappeared this afternoon: what comes back, in what order, how long it takes, and who owns each step.
Centaris is an IT and cybersecurity partner serving organizations across Michigan and the Great Lakes region, with deep experience in manufacturing and healthcare environments where downtime carries regulatory and operational consequences. We assess first, show you where your recovery path is exposed, and design continuity and disaster recovery around targets your business actually sets, delivered fully managed or co-managed on a predictable monthly subscription. Schedule a no-obligation assessment and find out what your recovery plan would really do.
