Business Continuity Plan (BCP/DRP): ISO 22301 Guide

A business continuity plan (BCP) is the documented set of procedures that lets an organization keep delivering its critical services, or restore them within a tolerable window, after a serious disruption: ransomware, a data center outage, a fire, the loss of a cloud provider or a health crisis. It is not a shelf document or an appendix to your insurance policy. It is a management system that you design, test and improve continuously. This guide explains what a business continuity plan is, how it differs from a disaster recovery plan (DRP), how it is built from a business impact analysis (BIA), how recovery objectives RTO and RPO are set, and how the ISO 22301 standard orders the whole cycle and connects with ISO 27001, NIS2 and DORA.

What Is a Business Continuity Plan (BCP)

The BCP answers an uncomfortable question: if we lose something essential tomorrow, how do we keep operating? Its goal is not to prevent the incident (that is the job of preventive controls) but to make sure the organization survives it with a bounded impact. A mature BCP covers people, processes, technology, facilities and suppliers, and it defines roles, activation thresholds, communication channels and recovery strategies for each critical service.

Business continuity rests on three capabilities that are worth keeping distinct:

• Resilience: the ability to absorb impact without going down (redundancy, high availability, supplier diversity).
• Continuity: the ability to keep operating with alternative resources while the disruption lasts.
• Recovery: the ability to return to the normal state once the incident is under control.

BCP vs DRP: How They Differ

This is where most organizations get it wrong. The DRP (disaster recovery plan) is a technical subset of the BCP focused on restoring IT infrastructure: servers, networks, databases and backups. The BCP is broader and operates at the business level.

Rule of thumb: the DRP answers "how do I recover the system"; the BCP answers "how does the business keep working while the system is down". An excellent DRP with a non-existent BCP leaves the organization with restored servers but no idea who does what during the critical hours.

BIA: Business Impact Analysis

The BIA (business impact analysis) is the foundation on which the entire plan is built. It is the exercise that identifies business functions, prioritizes them by the damage their disruption would cause, and determines their recovery objectives. Without a BIA, RTO and RPO are set by guesswork and almost always wrong.

A rigorous BIA produces, for each function or service:

1. Impact over time: how the damage grows (financial, legal, reputational, safety of people) as the hours of downtime pass.
2. MTPD (maximum tolerable period of disruption): the longest the function can be down before the damage becomes unacceptable.
3. RTO and RPO derived from that threshold (the RTO must always be shorter than the MTPD).
4. MBCO (minimum business continuity objective): the minimum acceptable level of service during the contingency, for example processing 40% of orders manually.
5. Dependencies: applications, data, suppliers, key people and facilities the function relies on.

The BIA draws on interviews with each area owner and is cross-checked against hard data: revenue per hour, contractual penalties, regulatory obligations and service level commitments to customers.

How to Set RTO and RPO per Critical Service

RTO and RPO are the two metrics that govern the technical design of recovery:

• RTO (recovery time objective): the maximum acceptable time between the disruption and the service being restored. It answers "how long can we be without this?".
• RPO (recovery point objective): the maximum tolerable data loss, measured in time. It answers "how much work can we afford to lose?". A 15-minute RPO demands near-continuous replication; a 24-hour RPO is covered by a daily backup.

The tighter the objectives, the more expensive the design (synchronous replication, active-active sites, duplicated systems). That is why they are calibrated with the BIA: you invest in recovery speed only where the business justifies it, not everywhere equally.

ISO 22301: PDCA Cycle, Requirements and Certification

ISO 22301:2019 (Security and resilience, Business continuity management systems, Requirements) is the international certifiable standard for a business continuity management system (BCMS). It shares the high-level structure (Annex SL) with ISO 27001, which makes integrating the two into a single system straightforward.

Standard Requirements (Clauses 4 to 10)

• 4. Context: interested parties and BCMS scope.
• 5. Leadership: management commitment, continuity policy and roles.
• 6. Planning: continuity objectives and risk treatment.
• 7. Support: resources, competence, awareness, communication and documented information.
• 8. Operation: this is where the core lives, the BIA, the risk assessment, continuity strategies, plans and the exercise program.
• 9. Performance evaluation: monitoring, measurement, internal audit and management review.
• 10. Improvement: nonconformities, corrective actions and continual improvement.

PDCA Cycle

ISO 22301 applies the PDCA (Plan, Do, Check, Act) cycle: plan (context, policy, BIA, strategy), do (implement plans and controls), check (exercises, audits and metrics) and act (correct and improve). Continuity is not a project with an end date, it is a cycle that repeats.

How It Connects with ISO 27001

ISO 27001 includes continuity within Annex A, in controls A.5.29 (information security during disruption) and A.5.30 (ICT readiness for business continuity) of the 2022 version. ISO 22301 develops that requirement in depth. Many organizations certify ISO 27001 and use ISO 22301 as the detailed framework for their BCMS. You can read more in what ISO 27001 certification is and the complementarity between ISO 27001 and NIS2.

Certification is performed by an accredited body (such as UKAS or an equivalent national accreditation body) through a two-stage audit, with annual surveillance audits and recertification every three years.

Backups as the Basis of Recovery: 3-2-1 Rule and Immutability

There is no recovery without copies that can actually be restored. The 3-2-1 rule is the minimum bar: 3 copies of the data, on 2 different media types, with 1 offsite. Against modern ransomware, which hunts and encrypts reachable backups before it detonates, the rule extends to 3-2-1-1-0: 1 offline or immutable copy (air-gap, WORM, S3 Object Lock, locked retention) and 0 errors after a verified restore.

Immutability is decisive: a backup the attacker can delete or encrypt offers no protection against ransomware. You have the full detail in what a backup is and the 3-2-1 rule. And it is worth repeating the golden rule: a backup that has never been restored in a clean environment does not count as a backup, it counts as hope.

Crisis Management and Tabletop Exercises

An untested plan is a hypothesis. The exercise program proves the BCP works before you need it. These are the types, from least to most realistic:

• Tabletop: the committee walks through a scenario on paper. It is cheap and works as the essential annual minimum.
• Walkthrough or simulation: real steps are executed in a controlled environment.
• Parallel test: the alternate site is brought up without shutting down production to confirm it responds.
• Full interruption: production is cut and operations run from recovery. Maximum realism and maximum risk, reserved for mature organizations.

Crisis management adds the human layer: a crisis committee, a call tree, spokespeople, and communication with customers, regulators (with the notification deadlines of NIS2 and DORA) and the media. An annual tabletop exercise as a minimum is the recommended practice, and several standards require it explicitly.

Contingency Plan Template and Checklist

An operational BCP should contain, at a minimum:

• Scope, objectives and a continuity policy approved by management
• BIA with critical functions, MTPD, RTO and RPO
• Continuity and recovery strategies per service
• Technical DRP with detailed restore procedures
• Dependency inventory (applications, data, suppliers, people)
• A 3-2-1-1-0 backup strategy with immutable copies
• Crisis committee roles and an up-to-date call tree
• Communication plan (internal, customers, regulators, media)
• Activation thresholds and escalation procedure
• Alternate sites and contingency resources
• Testing calendar (annual tabletop as a minimum)
• Lessons-learned log and continual improvement

Regulatory Landscape: NIS2, DORA and ENS

Continuity is no longer optional for many sectors:

• NIS2: Article 21.2(d) requires measures for business continuity, such as backup management and disaster recovery, and crisis management. Details in how to comply with NIS2 in Spain.
• DORA: it requires an ICT continuity policy, disaster recovery plans and RTO/RPO per critical function in the financial sector. More in the DORA compliance guide.
• ENS: the continuity dimension (impact analysis, continuity plan, periodic testing and alternative means) imposes continuity on the Spanish public sector. See ENS certification guide.

Continuity is, ultimately, the end goal of any cyber resilience assessment.

Frequently Asked Questions

What Is the Difference Between BCP and DRP?

The BCP (business continuity plan) covers the whole organization and aims to keep critical business functions running during a disruption. The DRP (disaster recovery plan) is a technical subset focused on restoring IT infrastructure and data. The DRP is a component inside the BCP, not a substitute for it.

What Is the Difference Between RTO and RPO?

The RTO is the maximum acceptable time to restore a service after an outage. The RPO is the maximum amount of data, measured in time, that the organization can afford to lose. The RTO looks forward (when am I operational again); the RPO looks back (to which point in the data can I recover).

Does ISO 22301 Replace ISO 27001?

No. ISO 27001 manages information security and ISO 22301 manages business continuity. They are complementary and share the same high-level structure, so many organizations integrate them into a single management system.

How Often Should the Continuity Plan Be Tested?

The recommended practice, and what standards like the ENS require and NIS2 and DORA expect, is at least one annual tabletop exercise plus periodic technical restore tests. Any significant change in systems or processes should trigger an additional test.

Is a Business Continuity Plan Mandatory?

It depends on the sector. For essential and important entities under NIS2, financial entities under DORA and public sector bodies subject to the ENS, business continuity is a legal obligation. For everyone else it is a good practice that dramatically reduces the impact of a serious incident.

Design Your Business Continuity with Secra

At Secra we help build and test continuity plans aligned with ISO 22301, NIS2, DORA and the ENS: BIA, RTO and RPO definition per service, an immutable backup strategy and facilitated tabletop exercises.

→ Explore our GRC Consulting

→ Request an initial no-commitment conversation