Why a backup is not a continuity plan

Most businesses, when asked about their business continuity plan, point to their backups. That is a reasonable instinct. Backups are important. But a backup is only an answer to one specific question: if we lost our data, do we have a copy?

A continuity plan answers a different set of questions. Who is responsible for making decisions when a system goes down? Which systems need to come back first? How long can each system be offline before it causes serious damage to the business? How do you keep customers informed when service is disrupted? Who covers which responsibilities when the person normally responsible is unavailable?

A backup cannot answer any of those questions. A backup is data. A business continuity plan is a set of decisions made in advance so that when something goes wrong, your team is executing a known process rather than improvising under pressure.

The distinction matters especially in 2026 because the threat landscape has changed in a specific way. Modern ransomware attacks now routinely target backups first. Attackers know that if they can compromise or encrypt your backups before they launch the main attack, your options narrow dramatically. A backup stored on the same network as your primary systems, reachable through the same credentials, is not a safety net. It is another target. This is why immutable off-site backups, backups that cannot be modified or deleted for a set period, have become a non-negotiable standard rather than a nice-to-have.

The backup assumption most businesses are making
A green light on your backup dashboard means the backup ran successfully. It does not mean the backup is restorable. Many businesses discover, at the worst possible moment, that their backup files are corrupted, incomplete, or stored in a format that their current software can no longer read. A backup that has never been tested with an actual restore is not a backup you can rely on. In 2026, the standard is automated restore verification: every backup is tested to confirm it restores correctly, and the results are documented. If your backup strategy doesn't include this, the backup is an assumption, not a guarantee.

Business Continuity vs Disaster Recovery, the distinction that matters

These two terms are used interchangeably in most conversations. They shouldn't be. They describe different things, and treating them as the same often leaves gaps in both.

BCP, Business Continuity Plan
Keeps the business running
The BCP is the strategic umbrella. It covers everything your business needs to continue operating during a disruption: how your team communicates, where people work if the office is inaccessible, how customers are kept informed, who makes decisions and when, and which functions keep running in reduced capacity while others are paused.
Think of it as the overall emergency plan for the whole organisation.
DR, Disaster Recovery
Restores the technology
Disaster recovery is a technical subset of the BCP. It covers the specific steps required to restore IT systems, data, and infrastructure after a failure. It answers questions like: in what sequence do systems come back online? Who executes the restore? What do we do if the primary data centre is unreachable?
Think of it as the technical manual for getting the servers back up while the BCP keeps everything else moving.

The practical consequence of confusing these two is common: businesses build a technically sound disaster recovery process and assume it covers business continuity. Then an incident occurs, the technical team executes the DR plan and restores the systems, but nobody knows how to communicate with customers during the outage, nobody has the authority to redirect the support team's work, and leadership is making decisions ad hoc in a crisis. The systems came back. The business response was chaotic.

A resilience audit looks at both layers. The DR plan tells you the technology will recover. The BCP tells you the business will keep functioning while that happens.

RTO and RPO, the two numbers every plan needs per system

These are the most important metrics in business continuity planning, and the ones most commonly left vague or undefined. Getting them right requires a specific conversation per system, not a single number applied across your entire IT environment.

RTO
Recovery Time Objective
How quickly do we need this system back?

RTO is the maximum amount of time your business can tolerate a system being unavailable before the impact becomes unacceptable. Every system has a different answer. The question to ask is: if this system went down right now, how long before we lose customers, violate a contract, or cause serious operational harm?
  • Payment processing system: RTO might be 30 minutes or less
  • Customer-facing website: RTO might be 2-4 hours
  • Internal HR system: RTO might be 24-48 hours
  • Archive reporting tool: RTO might be 3-5 days
RPO
Recovery Point Objective
How much data can we afford to lose?

RPO is the maximum amount of data loss your business can tolerate, measured in time. It drives your backup frequency. If your RPO for a system is 4 hours, you need to back that system up at least every 4 hours. If it's 15 minutes, you need near-continuous backup.
  • Financial transaction data: RPO might be 15 minutes or less
  • Customer records: RPO might be 1-2 hours
  • Email and communications: RPO might be 4 hours
  • Internal project files: RPO might be 24 hours

The reason these numbers matter so much is that they determine your infrastructure costs. A system with an RTO of 30 minutes requires high-availability failover, a secondary environment that is always running and can take over instantly. A system with an RTO of 48 hours can tolerate a more manual recovery process. Getting these numbers right means you're investing in resilience where it actually matters, not applying the same expensive solution to every system regardless of business criticality.

The Business Impact Analysis, how you determine RTO and RPO
RTO and RPO don't come from a guess or a technical default. They come from a Business Impact Analysis (BIA): a structured process of asking system owners and business leaders what the operational and financial consequences of a given system being unavailable would be over time. The BIA produces a ranked list of systems by criticality, which drives your recovery sequencing, your backup frequency, and your infrastructure investment. A resilience audit will almost always check whether a BIA was completed, when it was last updated, and whether the RTO and RPO targets in the plan match the current business environment.

The eight areas a resilience audit covers

Whether you are preparing for a regulatory audit (SEC, FINRA, HIPAA), a cyber-insurer review, or an internal assessment before something goes wrong, these are the eight areas that will be examined. Most businesses find gaps in at least three or four of them when they look honestly.

1
Business Impact Analysis (BIA)
Foundation, everything else is built on this

The BIA is the document that identifies your critical systems, ranks them by business importance, and defines what happens if each one is unavailable. Without a BIA, every other element of the plan is guesswork. Recovery priority decisions during a crisis become gut calls rather than documented choices.

A BIA should be reviewed and updated at least annually, and whenever significant changes occur, a new system introduced, a major process changed, a key vendor relationship altered. An audit will check when the BIA was last updated, whether it reflects your current technology stack, and whether system owners were involved in the criticality assessment.

What auditors look for A documented BIA, signed off by relevant business owners, updated within the last 12 months, with a clear system criticality ranking that maps to your RTO and RPO targets.
2
Defined RTO and RPO targets per system
Metrics, the specific numbers that drive infrastructure and backup decisions

Most plans have vague language around recovery timelines. "We will restore systems as quickly as possible" is not a target, it is the absence of one. An audit looks for specific, documented RTO and RPO values for each critical system, and checks whether the infrastructure and backup configuration actually support those targets.

A very common finding in resilience audits is the gap between stated RTO and actual recovery capability. The plan says a system will be back within four hours. The restore process, when tested, takes eight hours. The gap was never noticed because the restore had never actually been timed.

What auditors look for Documented RTO and RPO per system in the BCP, with evidence that the backup frequency and recovery infrastructure are configured to actually meet those targets.
3
Backup integrity and immutability
Data protection, the 2026 standard has changed significantly

The 2026 standard for backups goes beyond "we have a copy." Auditors now look for three specific properties. First, the backup is off-site, stored in a location separate from your primary systems so a single incident cannot affect both. Second, the backup is immutable, meaning it cannot be modified or deleted for a defined retention period. This directly addresses modern ransomware that targets backups before launching the main attack. Third, restores are verified, not assumed to work, but actually tested and documented.

Immutability is the property most often missing. A backup stored on a network drive that your regular admin credentials can reach is not immutable. A backup in a separate cloud environment with write-once retention policies configured is. The distinction matters when ransomware has been inside your network for days before you detected it, which is the typical pattern.

What auditors look for Off-site backups with immutable retention policies, automated restore verification with documented results, and backup frequency that matches your RPO targets per system.
4
Disaster recovery procedures
Technical playbook, the step-by-step that your team follows during a crisis

The disaster recovery plan is a technical document. It covers the specific steps to restore each critical system, in the correct sequence, with clear ownership of who executes each step. It distinguishes between scenarios: a server hardware failure requires different steps than a ransomware infection, which requires different steps than a data centre outage.

A common gap is the assumption that the person who knows how to do the restore will be available when needed. The DR plan should be detailed enough that a competent IT professional who did not design the environment can execute it. If the plan lives in the head of one person, the business is one unavailable person away from a significantly worse outcome during a crisis.

What auditors look for Documented step-by-step recovery procedures per system and per scenario, with named owners for each step and clear escalation paths if a step fails or the primary person is unavailable.
5
Incident response roles and escalation paths
Governance, who makes decisions, in what order, when

During an actual incident, the most expensive thing is confusion about who is in charge. Should this be escalated to the CEO or handled at the IT manager level? Who decides whether to invoke the DR plan? Who is authorised to communicate publicly? Who approves the call to bring in an external incident response firm?

A well-structured incident response section of the BCP answers all of these questions in advance. It defines the Incident Response Team, their roles, their authority levels, and the criteria that trigger each escalation. It also designates backups for each key role, because the person normally responsible for a decision may be the one most directly involved in the incident.

What auditors look for A named Incident Response Team with documented roles and authority levels, clear escalation criteria, and designated backup personnel for every critical role in the response process.
6
Communication protocols
Stakeholder management, customers, staff, regulators, and media

If your email system is down during an incident, how does your team communicate? If a customer's data is involved, what do you say, how quickly, and through which channel? If a regulator needs to be notified, what are the timeframes and what information is required?

Communication protocols need to work when primary systems are unavailable. Most businesses have a primary communication tool (usually email or Slack) and no pre-configured alternative. A backup communication channel, whether that's a VoIP system, a pre-registered group chat in a separate platform, or a phone tree, needs to exist and be tested before it's needed. Regulated industries also have specific notification timeframes, HIPAA requires breach notification within 60 days, some financial regulations within 72 hours, and those deadlines do not pause because your email is down.

What auditors look for Pre-configured alternative communication channels, template notifications for customers and regulators, named spokespersons for external communication, and documented regulatory notification timeframes.
7
Third-party and vendor dependency mapping
Supply chain risk, the hidden single points of failure

Many businesses have continuity plans that look comprehensive internally and ignore everything outside their direct control. Your continuity plan is only as good as the weakest dependency it relies on. If your customer support platform goes down and that platform is hosted by a third party, your plan needs to cover what you do during that outage, not just assume the third party will fix it quickly.

Third-party dependency mapping involves identifying every critical external service your operations depend on, understanding the SLAs and notification processes each vendor has, and building contingency plans for the most critical ones. A key question the audit asks: if this vendor experienced an outage for 24 hours, 72 hours, or indefinitely, what would we do? For some vendors the answer is simple. For others it reveals a genuine single point of failure that the business had not previously identified.

What auditors look for A documented inventory of critical third-party dependencies, their SLAs and notification processes, and contingency plans for the most business-critical external services.
8
Testing evidence, quarterly, not annually
Validation, proof the plan actually works, not just that it exists

A continuity plan that exists in a document and has never been tested is a guess dressed up as preparation. The plan reflects how someone thought the recovery process would work, not necessarily how it actually works. The only way to know is to test it.

Annual testing used to be the standard. In 2026, with AI-assisted threats evolving monthly and organisational systems changing constantly, quarterly testing is the new baseline recommended by security frameworks and increasingly required by cyber-insurers. Testing takes two forms. Tabletop exercises walk the leadership team through a simulated incident scenario to identify decision-making gaps and clarify roles, without touching live systems. Technical restore tests actually execute a backup restore and time the process against the documented RTO target. Both types of testing produce documentation that serves as evidence for regulatory audits and insurance renewals.

What auditors look for Documented testing results from within the last quarter, covering both tabletop exercises and technical restore tests, with findings logged and tracked through to resolution.
Need IT managed services?

Find IT providers verified on business continuity delivery

TechRadiant verifies IT managed services providers on documented resilience outcomes. Find a provider with experience building and testing continuity plans for businesses at your scale and in your industry.

Browse verified IT providers → Share your IT brief

What changed in 2026 that older plans don't account for

Business continuity planning has existed for decades, and many organisations have plans that were written three to five years ago and updated only modestly since. In 2026, several specific changes have made those plans materially inadequate in ways that are worth understanding.

Ransomware now targets backups before launching the main attack
Modern ransomware operators spend time inside compromised networks before activating the encryption. They use that time to find and either corrupt or encrypt your backups. A plan built on the assumption that backups are untouchable is no longer valid. Immutable off-site backups with air-gapping are the only reliable defence. If your backup infrastructure hasn't been redesigned in the last two years, this is the first gap to address.
AI-powered threats mean attack timelines have compressed dramatically
AI-assisted attacks move faster than human-operated ones. The window between initial compromise and significant damage is shorter. This is why quarterly testing, not annual, is now standard, the threat environment your plan was designed for 12 months ago is not the same one you face today. Your incident response procedures need to account for fast-moving AI-assisted lateral movement where attacker dwell time is measured in hours rather than weeks.
Cyber-insurer requirements have become significantly more specific
Two years ago, many cyber-insurers accepted a general description of backup procedures and access controls. In 2026, they require documented evidence: tested restore reports, MFA confirmation across all email and cloud systems, immutable backup certificates, and in many cases a completed security assessment from a qualified third party. A plan that satisfies last year's insurance application may not satisfy this year's renewal.
Remote and hybrid work has created new continuity gaps
Plans written before 2022 typically assumed most staff worked from a central location with company-managed devices. If your team is now distributed, working from home, or using personal devices, your BCP needs to account for this. Communication procedures, device access during an incident, and the assumption that staff can access backup systems from personal equipment all need to be explicitly addressed.
AI tools inside your organisation have created new continuity variables
If your team is using AI tools that process business data, those tools and their dependencies are now part of your continuity picture. If an AI platform your sales team relies on for pipeline management goes down, that belongs in your dependency mapping. If your team has submitted sensitive data to public AI tools, data governance gaps may create compliance exposure during an incident response. The 2026 BCP needs to account for the AI tooling your team is actually using.

A business continuity plan is not a document you write once. It is a programme you maintain. The businesses that hold up best during incidents are not the ones with the most elaborate plans. They are the ones that test regularly, update after every significant change, and treat resilience as an operational practice rather than a compliance document filed somewhere and forgotten. For IT managed services providers verified on continuity planning and resilience outcomes, TechRadiant's verified IT managed services index covers teams evaluated on documented delivery.