By Compyl Research · Last reviewed September 2026
A business continuity plan sets out how an organization keeps its critical operations running through a disruption and restores them afterwards. In a cyber context it differs from traditional continuity planning in one decisive way: the disruption is adversarial. A flood does not encrypt your backups or wait for you to start recovering before triggering a second stage. Ransomware does both, which is why a continuity plan written for natural disasters usually fails the first time it is used against an attacker.
Key takeaways
- Continuity is about the business; recovery is about the systems. A business continuity plan keeps critical processes running by any means. A disaster recovery plan restores the technology. You need both, and they are not interchangeable.
- The business impact analysis is the plan. Everything downstream — recovery targets, backup architecture, spend — is decided by which processes you identify as critical and how long they can be down.
- Cyber changes the assumptions. Backups are a target, not a safe harbour; the environment may be evidence; restoring too fast can reinfect; and regulatory notification clocks run while you are still down.
- It is a framework requirement, not just good practice. HIPAA mandates a contingency plan with a data backup plan, a disaster recovery plan and an emergency mode operation plan. ISO 27001, SOC 2’s availability criteria and ISO 22301 all address it.
- An untested plan is a document, not a control. The value is in the exercise, and the most common finding is that the plan assumes people and systems that will not be available.
What is a business continuity plan?
A business continuity plan documents how an organization continues delivering its critical products and services at an acceptable level during and after a disruptive incident. It answers four questions: which activities must continue, how long they can be interrupted, what the organization will do to keep them going, and who decides.
The important word is business. A continuity plan is not a technical restore procedure. If your claims processing must continue and the system is down, the continuity plan covers the manual workaround, the staffing for it, the backlog reconciliation afterwards and the customer communication — as well as the restore.
What is the difference between business continuity and disaster recovery?
They are related and frequently conflated. Disaster recovery is a subset of business continuity concerned specifically with restoring technology.
| Business continuity | Disaster recovery | |
|---|---|---|
| Scope | The whole organization — people, processes, facilities, suppliers, communications, technology | IT systems, data, infrastructure and applications |
| Question it answers | How do we keep operating? | How do we get the systems back? |
| Owner | Business leadership, with a continuity lead | IT and infrastructure |
| Key measures | Maximum tolerable period of disruption; minimum service levels; workaround capacity | Recovery time objective; recovery point objective |
| Typical content | Critical process list, workarounds, roles, escalation, communications, supplier arrangements | Backup architecture, restore runbooks, failover procedures, system dependencies |
Which comes first? Business continuity, always. The business impact analysis determines which systems matter and how fast they must come back — and those answers are the requirements a disaster recovery plan is built to meet. Building DR first means designing recovery capability without knowing what it needs to achieve, which is how organizations end up with expensive replication for systems nobody would miss for a week and nightly backups for the one system that cannot lose an hour.
What plans make up a continuity program?
NIST’s contingency planning guidance (SP 800-34) distinguishes several plan types that are often collapsed into one document and should not be. Each has a different scope and a different audience.
| Plan | What it covers |
|---|---|
| Business continuity plan | Sustaining critical business processes during and after a disruption |
| Continuity of operations plan | Sustaining the organization’s essential functions, typically at an alternate site |
| Disaster recovery plan | Restoring IT systems and infrastructure, usually at an alternate location |
| Information system contingency plan | Recovery of a specific system, with its own dependencies and runbook |
| Cyber incident response plan | Detecting, containing, eradicating and recovering from a security incident |
| Crisis communications plan | Internal and external messaging, spokespeople, approval paths and holding statements |
| Occupant emergency plan | Life safety and evacuation for a facility |
The interface that matters most in practice is between the cyber incident response plan and the continuity plan. Incident response decides when it is safe to restore; continuity decides how the business operates until then. Organizations that merge them into a single document generally find that under pressure the technical containment work crowds out the business decisions entirely.
How do you run a business impact analysis?
The business impact analysis identifies critical activities, quantifies the effect of losing them over time, and sets the recovery targets. Four terms do most of the work:
| Term | What it means | How to set it |
|---|---|---|
| MTPD / MTD — maximum tolerable period of disruption | The longest an activity can be unavailable before the damage becomes unacceptable | A business judgment about contractual, financial, regulatory and reputational harm — not a technical one |
| RTO — recovery time objective | The target time to restore the activity or system after a disruption | Must be shorter than the MTPD, with margin |
| RPO — recovery point objective | The maximum data loss the organization can accept, expressed as time measured backwards from the incident | Determined by how much re-work or unrecoverable data the business can absorb; drives backup frequency and architecture |
| MBCO — minimum business continuity objective | The minimum level of service acceptable during a disruption | Often far below normal service, and stating it explicitly prevents over-engineering |
Run the analysis per business activity, not per system, then map activities to the systems, people, facilities, data and suppliers they depend on. The dependency mapping is where the surprises are: the process everyone assumed was resilient turns out to rely on one integration, one vendor or one person.
Set targets with the people who bear the consequences. Left to IT, RTOs tend to reflect what is achievable; left to the business alone, everything is critical and needs to be back in an hour. The useful conversation happens when the cost of each recovery tier is on the table.
What should a business continuity plan contain?
- Scope and objectives, including which locations, entities and activities are covered.
- Critical activities and their recovery targets, straight from the business impact analysis.
- Dependencies — systems, data, people, facilities, suppliers — for each critical activity.
- Roles and authority, including who can declare an incident, who can authorise spend, and named deputies for every role.
- Response and continuity procedures, including manual workarounds with their capacity limits and how long they can be sustained.
- Communications, covering employees, customers, regulators, insurers and the public, with pre-approved templates and an out-of-band channel that works when corporate systems do not.
- Recovery and return-to-normal, including how backlog is reconciled and how you decide the incident is over.
- Supplier and third-party arrangements, including what your critical vendors have committed to and what happens if they are the ones disrupted.
- Testing schedule and results, with owners for the actions that come out of each exercise.
What does a cyber disruption change?
This is where continuity plans written for physical disasters break down.
Your backups are a target. Attackers routinely locate and destroy or encrypt backups before triggering ransomware, because it is the difference between an inconvenience and a payment. The countermeasure is architectural: immutable or offline copies, separate credentials from the production domain, and restore testing that proves the copies are usable.
The environment may be evidence and may still be compromised. Restoring quickly into an environment where the attacker still has access reinfects it. Continuity and incident response have to be sequenced, which usually makes real recovery slower than the RTO assumed.
Identity is a single point of failure. If the directory or identity provider is compromised, the credentials your recovery runbooks rely on may be untrustworthy. Plans should include a way to operate and authenticate that does not depend on the compromised system.
Regulatory clocks run while you are down. Breach notification obligations do not pause because systems are unavailable — and the records you need to assess notification scope may be in the systems you cannot reach. Build the notification assessment into the continuity plan rather than treating it as a post-incident task.
The disruption can be silent and long-running. Data integrity attacks may not produce an outage at all. An RPO expressed in hours assumes you know when the incident started; if corruption was introduced weeks earlier, your recovery point is a research question.
What are business continuity best practices?
- Start from the business impact analysis, and refresh it. A BIA more than a year or two old describes an organization you no longer run.
- Assume the people named in the plan are unavailable. Name a deputy for every role and make sure the deputy has the access and authority, not just the title.
- Store the plan where you can reach it during the incident. A continuity plan available only on the file share that ransomware encrypted is a recurring, entirely avoidable failure.
- Design backups against an adversary. Immutable or offline copies, separate credentials, and periodic restore tests that actually restore rather than verifying that a job completed.
- Extend the plan to critical suppliers. Ask what their recovery targets are, get them into contracts, and know what you do if a critical vendor is the one that is down.
- Test at increasing difficulty. Tabletop, then functional test of one system, then a full exercise. Each level finds different failures.
- Treat exercise findings as corrective actions with owners and dates, not as observations in a report.
- Rehearse communications specifically. Who approves the customer message, in what timeframe, through which channel — this is the part most often improvised, and improvisation is visible to customers.
- Review after every real incident, including near misses and other organizations’ public incidents in your sector.
How do you test a business continuity plan?
- Plan review. A structured walkthrough to check the plan is current — names, systems, contacts, dependencies. Cheap, and catches a surprising amount.
- Tabletop exercise. Key participants talk through a scenario. Best for testing decision-making, authority and communications. Use a cyber scenario, not a fire.
- Functional test. Actually perform part of the recovery — restore a system from backup, fail over a service, run the manual workaround for an hour with real staff.
- Full simulation. Rare, expensive and the only exercise that tests whether the parts work together under time pressure.
Whatever the level, define success criteria before you start and measure against them. “The exercise went well” is not a result; “we restored the order system in 6 hours against a 4-hour RTO, because the restore credentials were in the encrypted vault” is.
Which frameworks require business continuity planning?
- HIPAA Security Rule, 45 CFR 164.308(a)(7). A contingency plan is required, with a data backup plan, a disaster recovery plan and an emergency mode operation plan as required implementation specifications, plus testing and revision procedures and an applications and data criticality analysis as addressable ones.
- ISO/IEC 27001. Annex A addresses information security continuity during disruption and ICT readiness for business continuity, with the management system requiring documented, tested arrangements.
- SOC 2. The availability criteria cover recovery capability, backup and environmental protections, and a Type II examination tests them across the period.
- ISO 22301. The dedicated business continuity management system standard, and the one to certify against if customers or regulators require independent assurance of continuity specifically.
- Sector rules. Financial services, healthcare and critical infrastructure regimes impose their own operational resilience obligations, often with prescribed testing and reporting.
How Compyl helps with business continuity
Continuity fails at the seams — a plan that is current but untested, a test whose findings were never closed, a critical supplier nobody reassessed, an RTO agreed two reorganizations ago. Compyl holds continuity plans, owners, recovery targets, test schedules and exercise findings as tracked controls with review cycles, maps them once across HIPAA, ISO 27001, SOC 2 and ISO 22301 rather than per audit, and keeps the evidence continuous so a Type II examination samples records that already exist.
Book a demo to see how Compyl supports continuity alongside the rest of your program.
Business continuity FAQs
What is a business continuity plan in cyber security?
A documented plan for keeping critical business operations running during and after a cyber incident, and restoring them afterwards. It differs from general continuity planning because the disruption is caused by an adversary who may target backups, remain in the environment during recovery and trigger regulatory notification obligations that run while systems are down.
What is the difference between business continuity and disaster recovery?
Business continuity covers the whole organization — people, processes, facilities, suppliers and communications — and asks how the business keeps operating. Disaster recovery is the technology subset: how systems, data and infrastructure are restored. Continuity planning comes first, because the business impact analysis sets the recovery targets that disaster recovery is built to meet.
What is the difference between RTO and RPO?
RTO, the recovery time objective, is how quickly an activity or system must be restored. RPO, the recovery point objective, is how much data you can afford to lose, measured backwards in time from the incident. RTO drives recovery capability and staffing; RPO drives backup frequency and architecture.
How often should a business continuity plan be tested?
At least annually as a baseline, with the type of test varying — a plan review and tabletop each year, functional tests of critical systems on a rotating schedule, and a fuller exercise less often. Test again after any material change to systems, suppliers or organizational structure, and after any real incident.
Does HIPAA require a business continuity plan?
It requires a contingency plan under 45 CFR 164.308(a)(7), which includes a data backup plan, a disaster recovery plan and an emergency mode operation plan as required implementation specifications, with testing and revision procedures and an applications and data criticality analysis as addressable specifications.
Who should own the business continuity plan?
Business leadership owns it, with a named continuity lead running the program and system owners responsible for their own recovery procedures. Ownership sitting entirely in IT is the most common structural weakness, because the decisions that matter most during a disruption — what to prioritize, what to tell customers, when to invoke workarounds — are business decisions.
What is a business impact analysis?
The exercise that identifies critical business activities, quantifies the effect of losing them over time, maps their dependencies on systems, people, facilities and suppliers, and sets the maximum tolerable disruption and the recovery targets. Every other part of the continuity program derives from it.
How do you protect backups from ransomware?
Keep immutable or offline copies that cannot be altered or deleted from the production environment, use credentials for the backup system that are separate from the production directory, monitor for mass deletion or encryption of backup data, and test restores regularly — verifying that a backup job completed is not the same as proving the data can be restored.
