Framework

ISO 22301
Business continuity management systems (BCMS)

ISO 22301 (Security and resilience, Business continuity management systems, Requirements) is the international certifiable standard that defines what a business continuity management system (BCMS) is, what it produces, and how it is audited. ISO 22301:2019 sits alongside ISO 22313 (guidance), ISO 22317 (BIA guidelines), and ISO/IEC 27031 (ICT readiness) as the wider continuity standards family. This page covers the standard scope, the eight load-bearing principles, the PDCA operating model, the business impact analysis discipline, the continuity strategies and solutions, the evidence pack, the failure modes, and the cross-walks to ISO/IEC 27031, ISO/IEC 27001 Annex A 5.29 and 5.30, ISO/IEC 27035, NIST SP 800-61, NIST CSF 2.0 Recover and Respond, DORA Articles 11 to 14, NIS2 Article 21(2)(c), SOC 2 A1.1 to A1.3, and PCI DSS 12.10.

Get Started Free

No credit card required. Free plan available forever.

ISO 22301 explained for enterprise teams

ISO 22301 (Security and resilience, Business continuity management systems, Requirements) is the international certifiable standard that defines what a business continuity management system (BCMS) is, what it produces, and how it is audited. The current edition (ISO 22301:2019) sits alongside ISO 22313 (guidance), ISO 22317 (BIA guidelines), and ISO/IEC 27031 (ICT readiness for business continuity) in the wider continuity standards family. Programmes operate ISO 22301 as the management system anchor and read the adjacent guidance standards as the operating depth.

For internal security teams, GRC and compliance teams, security operations leaders, business continuity owners, risk management teams, IT continuity owners, activity owners accountable for service availability, AppSec leads where availability is a security property, cloud security teams managing region and provider exposure, and CISOs and security directors carrying the audit-committee read against the wider operational resilience posture, ISO 22301 is the certifiable BCMS standard the continuity evidence reads against. The standard is dense; the value is the management system discipline that turns business continuity from a folder of static documents into a continuous operating record that survives audits, regulators, and material disruptions.

This page covers the standard scope, the eight load-bearing principles, the PDCA operating model, the business impact analysis discipline, the continuity strategies and solutions, the evidence pack, the failure modes, and where ISO 22301 sits alongside ISO/IEC 27031 ICT readiness for business continuity, ISO/IEC 27001 Annex A 5.29 and 5.30, DORA Articles 11, 12, and 14, NIS2 Article 21(2)(c), NIST CSF 2.0 Recover and Respond functions, and SOC 2 Availability criteria. Programmes that adopt ISO 22301 as the certifiable BCMS standard read cleanly into every adjacent regime without rebuilding the management system per audit.

Eight load-bearing principles of the BCMS

ISO 22301 is structured around the standard ISO management system requirements (context, leadership, planning, support, operation, performance evaluation, improvement) and the continuity-specific operating discipline (BIA, risk assessment, strategy and solution, plans and procedures, exercising and testing). The eight principles below are the load-bearing orientations the rest of the standard reads against. Programmes that adopt them as the operating posture produce evidence that survives certification, regulator review, and material disruption; programmes that treat them as text in a policy document produce a BCMS that ages out within the first cycle.

Leadership and commitment

ISO 22301 expects top management to take accountability for the business continuity management system (BCMS) rather than delegating to a documentation function. The standard names the leadership requirements in Clause 5: establishing the policy, ensuring the BCMS is integrated with other business processes, ensuring resources are available, communicating the importance, and reviewing the system. Programmes that operate the BCMS as a compliance artefact without executive sponsorship produce a documented system that does not survive the first material disruption.

Risk-based approach

BCMS commitments are finite. ISO 22301 expects continuity investment to be sized against the business impact analysis (BIA) outputs and the risk assessment outputs rather than applied uniformly across every activity. Programmes that set blanket recovery commitments without BIA inheritance over-invest in commodity processes and under-invest in critical ones. The risk-based approach is the structural commitment that ties recovery posture to organisational impact.

Process-based operating model

ISO 22301 organises the BCMS as a process: identify activities and dependencies, set continuity commitments, design strategies and solutions, implement plans and procedures, exercise, evaluate, and improve. Each process step produces durable artefacts the auditor reads against. Programmes that operate the BCMS as a folder of static documents rather than as a continuous process lose the cycle dimension the standard depends on.

Plan-Do-Check-Act lifecycle

ISO 22301 is structured around the Plan-Do-Check-Act (PDCA) cycle aligned with ISO management system standards. Plan covers context, leadership, planning, and support (Clauses 4 to 7). Do covers operation (Clause 8). Check covers performance evaluation (Clause 9). Act covers improvement (Clause 10). The lifecycle is continuous; each cycle feeds the next. Programmes that treat ISO 22301 as a one-off documentation project miss the structural commitment that makes the BCMS durable.

Continual improvement

Every PDCA cycle is expected to feed the next: the exercise after-action records surface gaps, the incident post-mortems surface root causes, the management review documents the disposition, and the corrective action follow-up closes the loop. Continual improvement is the operating discipline that turns the BCMS from a snapshot of capability into a programme that improves over time. Programmes that exercise without after-action review or document without revision lose this dimension within the first cycle.

Scope and context discipline

ISO 22301 Clause 4 expects the organisation to define the BCMS scope (which activities, services, products, locations, and dependencies are in scope) and the context (internal and external issues, interested parties, legal and regulatory requirements). Scope is the structural anchor that distinguishes a focused BCMS from a programme that drifts every cycle. Programmes that operate without a documented scope statement produce continuity commitments nobody can audit against.

Defined roles and responsibilities

The BCMS names the roles the operating record reads against: the BCMS owner (typically a senior executive or board sponsor), the BCMS coordinator (the day-to-day operating lead), the BIA owner per activity, the recovery owner per critical activity, the exercise lead, the crisis decision authority, the regulator notification owner, and the management review authority. Programmes that operate the BCMS without a named owner per artefact produce shared accountability that becomes no accountability at the moment of need.

Demonstrable competence

The personnel operating the BCMS are expected to be competent for the roles they hold (Clause 7.2). The standard does not name specific certifications; it expects the competence to be documented and refreshed (training records, qualification mapping, mentoring under named senior operators). Programmes that depend on the institutional memory of one BCMS lead carry single-person continuity risk that contradicts the management system the personnel are operating.

The PDCA operating model

ISO 22301 is structured around the Plan-Do-Check-Act cycle aligned with the wider ISO management system family. The cycle is continuous: each Act closure feeds the next Plan refresh, and the operating record reads against the same evidence pack across years. Programmes that operate the BCMS as a one-time documentation project lose the cycle dimension; the standard expects the lifecycle to be the structural commitment the rest of the principles read against.

  1. 1

    Plan (Clauses 4 to 7)

    Establish the BCMS context (internal and external issues, interested parties, legal and regulatory requirements, BCMS scope), leadership (policy, roles, responsibilities, authorities), planning (continuity objectives, risks and opportunities, change management), and support (resources, competence, awareness, communication, documented information). The Plan phase is the cheapest phase to invest in and the most expensive to skip. Programmes that under-invest in Plan rebuild the BCMS at every audit and every regulator change.

  2. 2

    Do (Clause 8 Operation)

    Operate the BCMS through the operational planning and control discipline: the business impact analysis (Clause 8.2.2), the risk assessment (Clause 8.2.3), the business continuity strategies and solutions (Clause 8.3), the business continuity plans and procedures (Clause 8.4), and the exercise programme (Clause 8.5). The Do phase is the longest visible phase and the one auditors read against most directly. The artefacts the Do phase produces (BIA outputs, strategy decisions, plans, exercise records) are the load-bearing evidence the rest of the BCMS reads against.

  3. 3

    Check (Clause 9 Performance evaluation)

    Evaluate the BCMS through monitoring, measurement, analysis, and evaluation (Clause 9.1), internal audit (Clause 9.2), and management review (Clause 9.3). The Check phase is where the difference between a documented system and an operating system becomes visible. Performance evaluation reads the BIA outputs against the achieved exercise metrics, the documented plans against the executed responses, and the policy against the operating reality. Programmes that operate the Do phase without Check lose the evidence the audit committee and the regulator read.

  4. 4

    Act (Clause 10 Improvement)

    Improve the BCMS through nonconformity and corrective action (Clause 10.1) and continual improvement (Clause 10.2). The Act phase converts the gaps surfaced in Check into closed corrective actions feeding the next Plan cycle. Programmes that surface findings without closing them lose the cycle that makes the BCMS durable. The maintain-and-improve phase is the closing artefact that completes one PDCA cycle and opens the next.

The business impact analysis discipline

ISO 22301 Clause 8.2.2 names business impact analysis as the load-bearing input the rest of the operating discipline reads against. The BIA is the structured analysis of activity criticality, impact over time, MTPD, MBCO, RTO, RPO, and dependency footprint that produces the per-activity recovery commitments. ISO 22317 supplies the BIA-specific guidance the standard reads alongside. Programmes that operate the BCMS without a current BIA produce per-activity commitments that float free of organisational impact; the BIA is the structural artefact that ties recovery posture to business reality.

  • Activity identification. The structured list of business activities (processes, services, products) the BCMS scope covers. Each activity carries an owner, a description, the inputs and outputs, the dependencies (people, technology, suppliers, facilities, information), and the criticality tier. Activity identification is the foundation the rest of the BIA reads against; programmes that skip this step produce continuity commitments that float without an organisational anchor.
  • Impact analysis. The structured analysis of the impact disruption would have on each in-scope activity, across the impact dimensions the standard names (financial, regulatory, reputational, operational, contractual, statutory, customer commitments). Impact is assessed over time so the impact at one hour, four hours, twenty-four hours, three days, one week, and longer windows is visible. The over-time impact profile drives the recovery commitments downstream.
  • Maximum tolerable period of disruption (MTPD). The point at which disruption of an activity becomes unacceptable to the organisation. MTPD is the outer boundary the recovery time objective (RTO) must sit comfortably inside. Programmes that set RTO without MTPD lose the structural anchor that makes the per-activity commitment accountable to the business impact rather than to the technical capability of the recovery design.
  • Minimum business continuity objective (MBCO). The minimum level of service or product output the organisation will accept during a disruption, before the activity is restored to full capability. MBCO sits between full operation and complete outage and is the working commitment that absorbs the recovery interval. Programmes that operate without a documented MBCO discover that the recovery design assumes full capability when partial would have absorbed the disruption.
  • Recovery time objective (RTO). The target time within which an activity, a product, or a service must be resumed at the MBCO level after a disruption begins. RTO is set by the activity owner against the business impact, agreed by the supporting functions against the technical and operational feasibility, and evidenced through exercise. Per-activity RTOs typically tier by criticality (Tier 1 critical, Tier 2 important, Tier 3 standard, Tier 4 deferred).
  • Recovery point objective (RPO). The target maximum age of data, information, or work-in-progress that can be lost when an activity is resumed. RPO is set against the data-loss tolerance of the affected process and evidenced through restoration testing. Per-activity RPOs typically tier by data sensitivity and process criticality (continuous replication for Tier 1, near-real-time for Tier 2, hourly for Tier 3, daily for Tier 4).
  • Dependency mapping. The structured map of internal dependencies (which activity depends on which other activity), people dependencies (key personnel, competence requirements), technology dependencies (the ICT services that support the activity, naturally read with the ISO/IEC 27031 IRBC programme), supplier dependencies (which third party provides which service component), and facility dependencies (which site, which workspace, which physical infrastructure). Dependency mapping is the artefact the recovery sequence reads against.
  • BIA refresh cycle. The BIA outputs date quickly: services enter and leave the activity catalogue, dependencies change, business models evolve, regulator obligations shift. The standard expects the BIA to be refreshed on a documented cadence (annual minimum), on event (post-incident, post-exercise, post-major-change), and on change (new activity in scope, decommissioned activity out of scope, supplier change, regulatory change). The BIA refresh cycle is the operational discipline that prevents the per-activity commitments from drifting.

Continuity strategies and solutions

ISO 22301 Clauses 8.3 (strategies and solutions) and 8.4 (plans and procedures) name the artefacts that translate the BIA outputs into operational capability. Strategies are the chosen approaches; solutions are the technical, operational, and procedural arrangements that implement them; plans are the documents the operators read at the moment of disruption. The three artefact layers read together as one continuity posture rather than as three separate disciplines.

  • Continuity strategies. The set of approaches the organisation will use to ensure continuity of the in-scope activities, including resource requirements (people, premises, technology, information, suppliers), the timing required for each strategy to be effective, and the cost and risk profile of each strategy. Strategies are selected against the BIA outputs, the risk assessment outputs, and the appetite the policy names. The standard expects strategies to be documented, reviewed, and refreshed on the same cycle as the BIA.
  • Continuity solutions. The specific technical, operational, and procedural arrangements that implement the chosen strategies: resilience design (redundancy, fault tolerance, geographic diversity), recovery design (backup, restoration, failover, manual workaround, alternative supplier, alternative site), incident response design (detection, escalation, containment, communication), and crisis management design (decision authority, stakeholder communication, regulator notification, media handling). Solutions read against strategies; strategies read against the BIA.
  • Resource requirements per solution. Each solution names the resources required to operate it (people with named competence, premises and physical infrastructure, technology with named ICT services, information including the records and data needed, suppliers including the supplier-side continuity expectations the contracts read against). The resource requirements are the artefact procurement, IT, HR, and facility planning read alongside the continuity discipline.
  • Timing commitments. Each solution carries a timing commitment the activity can be resumed by (read against the RTO), the data position the activity is resumed at (read against the RPO), the minimum service level the activity operates at during recovery (read against the MBCO), and the projected duration of the disruption the strategy is sized for. The timing commitments are the operating commitments the exercise programme tests and the auditor reads.
  • Plans and procedures. The documented business continuity plans the named operators read at the moment of disruption, with named owners, executable steps, decision points, escalation triggers, communication requirements, and verification steps. The plans cover the activity-level continuity, the function-level continuity, and the enterprise-level crisis management. Plans are the artefact the responder uses; the BCMS audit reads them against the exercise evidence.
  • Communication plan. The plan that covers internal communication (executive, technical, customer-facing, regulator-facing), supplier communication (cloud provider, managed service provider, key supplier), customer communication (notification, status page, support), regulator communication (sectoral regulator, data protection authority, CSIRT), and public communication (media, market disclosures for listed entities). The communication plan integrates with the wider crisis management discipline.

The BCMS evidence pack

The minimum durable evidence pack the certification auditor, the internal auditor, the regulator, the audit committee, and the executive sponsor each read against the BCMS is grouped below by artefact type. Each artefact carries a named owner, a refresh cadence, and a version history so reconstruction at audit time is replaced with a continuous operating trail. ISO 22301 does not invent these artefacts; it names what the BCMS operating record needs to contain to satisfy the management system discipline the standard reads against.

  • The BCMS policy (Clause 5.2). The signed policy that names the BCMS scope, the BCMS governance, the continuity commitments, the regulator notification commitments, the management review cycle, and the executive sponsor. The policy is the load-bearing document the rest of the management system reads against and the artefact the management review minutes are signed against.
  • The BCMS scope statement (Clause 4.3). The structured statement of which activities, services, products, locations, business units, and dependencies are in scope. Activities explicitly out of scope are named with the rationale. The scope statement is refreshed on cycle and on change so an activity entering the operating estate is also entering the BCMS scope.
  • Context and interested parties (Clause 4.1 and 4.2). The documented analysis of the internal and external issues the BCMS reads against, the interested parties (customers, regulators, suppliers, shareholders, employees, partners), and the requirements each interested party places on the BCMS. Context is the artefact that distinguishes a BCMS that exists in isolation from one that integrates with the wider organisation.
  • The BIA outputs. The dated outputs of the business impact analysis, with the per-activity RTO, RPO, MTPD, MBCO; the dependency map per activity; the impact-over-time profile; and the named activity owner. The BIA outputs are the load-bearing inputs the strategies, solutions, and plans read against.
  • The risk assessment outputs (Clause 8.2.3). The dated outputs of the BCMS risk assessment, with the threats considered, the vulnerabilities surfaced, the likelihood and impact analysis, the residual risk position, and the management decision per risk. The risk assessment outputs read alongside the BIA outputs as the analytical inputs to the strategy and solution decisions.
  • The continuity strategy document. The strategy that names the chosen approach per activity, the resource requirements, the timing commitments, the supplier-side expectations, the regulator-side commitments, and the residual risk position. The strategy is the architectural commitment the per-activity solutions read against.
  • The business continuity plans. The documented plans the named operators read at the moment of disruption, with version history, named owners, refresh dates, and exercise records. Plans cover activity-level continuity, function-level continuity, and enterprise-level crisis management. The plans are the artefact the responder reads at 3 AM during a real disruption.
  • The exercise programme and exercise records (Clause 8.5). The exercise calendar covering the next twelve months, the exercise records from the prior twelve months, the after-action records, the achieved metrics versus target, and the corrective action follow-up. The exercise evidence is the most-read artefact during a BCMS audit and one of the most-read during a regulator review.
  • Performance evaluation records (Clause 9.1). The monitoring and measurement records that evidence the BCMS performance against the continuity objectives, including the achieved RTO and RPO per exercise, the incident metrics, the BCMS audit findings, and the management review outputs.
  • Internal audit programme and records (Clause 9.2). The internal audit plan, the audit programme covering each BCMS element on a cycle, the audit records per audit performed, the findings per audit, and the corrective action follow-up. Internal audit is the discipline that surfaces the BCMS gaps before the certification audit does.
  • Management review minutes (Clause 9.3). The minutes of the periodic management review of the BCMS, with the per-activity performance, the exercise outcomes, the incident learnings, the audit results, the residual risk position, the resource requests, and the management decisions. The minutes are the artefact the BCMS audit reads to evidence the top-management commitment.
  • Nonconformity and corrective action records (Clause 10.1). Every nonconformity (a BCMS element that does not meet the standard or the policy) and the corrective action plan, the closure evidence, and the disposition. The nonconformity record is the artefact that turns BCMS findings into closed actions rather than open trails.

Failure modes the standard is designed to surface

ISO 22301 is forgiving on the choice of tooling, the recovery architecture, and the depth of exercise per activity. It is unforgiving about a small number of patterns that turn the BCMS cosmetic rather than operational. The patterns below recur across BCMS programmes and are the ones that erode the year-over-year continuity audits, regulators, and audit committees increasingly read against.

  • Documenting without testing. The most common BCMS failure mode. The policy reads well, the plans are documented, the BIA is current, and nothing has been exercised. The first material disruption is the first test. ISO 22301 Clause 8.5 expects exercising and testing as an operational discipline rather than as an annual compliance event; programmes that file the BCMS plan as a one-time artefact and never execute against it produce a paper readiness that does not survive contact with a real event.
  • Setting RTO and RPO without business owner agreement. The recovery commitments are set by IT or operations in isolation against the technical capability of the design rather than against the business impact of the disruption. The plan looks coherent until a real incident exceeds the RTO and the activity owner discovers the commitment is not what they would have asked for. The standard expects the BIA-driven owner agreement rather than the unilateral target.
  • Treating the BCMS as a static documentation artefact. The plans are written once, signed, filed, and not refreshed when the operating estate changes. Activities enter and leave scope, suppliers change, regulator obligations evolve, organisational ownership shifts, and the plans no longer match the system they describe. The Act phase is the discipline that prevents this drift; programmes that skip Act lose the cycle dimension within the first iteration.
  • Operating the BCMS in isolation from the ICT readiness programme. The BCMS plan names the activity-level recovery commitments but the ICT-side recovery discipline (ISO/IEC 27031) operates as a separate programme with separate evidence, separate cadence, and separate ownership. The holistic principle expects the two disciplines to read as one integrated continuity programme rather than as parallel tracks.
  • Ignoring the supplier-side continuity posture. The acquirer-side BCMS assumes the supplier-side recovery posture without verifying it. The supplier-side incident affects the acquirer-side activity and the acquirer discovers the supplier RTO is longer than the acquirer commitment to its own customers. The standard pairs with ISO/IEC 27036 supplier-relationship discipline so the supplier-side BCDR evidence reads into the acquirer-side BCMS.
  • Skipping the after-action review. The exercise is executed, the achieved metrics are recorded, and no after-action review is produced. The exercise becomes a compliance artefact instead of a learning artefact, the gaps do not become corrective actions, and the next cycle repeats the same exercise without improvement. Clause 8.5.4 expects the exercise outcomes to feed the BCMS improvement cycle.
  • Operating with a stale BIA. The BIA was performed once, signed, and not refreshed when activities, dependencies, or the operating estate changed. The per-activity RTO and RPO targets no longer match the activity criticality. Programmes that operate the BCMS against a stale BIA produce recovery commitments that look coherent on paper and float free of organisational reality.
  • Letting plans fall behind the activities they describe. The activity moves from a manual process to an automated platform, the supplier changes, the regulatory regime evolves, the dependency footprint shifts, and the plan still references the prior design. Change management discipline is the operational control that prevents the plan from aging out between exercises.
  • Counting management review as a quarterly status update. The management review cycle is expected to read the BCMS performance, the exercise outcomes, the incident learnings, the audit results, the residual risk position, the resource requests, and the management decisions against a documented agenda. Reviews that compress this into a status update lose the dimension that distinguishes a managed system from a maintained document.
  • Confusing the BCMS with a disaster recovery plan. Disaster recovery planning is one input into the BCMS, but the BCMS is the broader management system covering policy, leadership, planning, support, operation, performance evaluation, and improvement across activities, not just ICT services. Programmes that treat the BCMS as a DR plan rename lose the structural breadth the standard depends on.

How ISO 22301 relates to adjacent regimes

ISO 22301 sits in a busy continuity, regulatory, and standards neighbourhood. The relationships below are the ones programmes encounter most often when they read the standard against the rest of the resilience regime. Programmes operating across regions and sectors use ISO 22301 as the BCMS spine and read ISO/IEC 27031, ISO/IEC 27001 Annex A 5.29 and 5.30, NIST SP 800-34, NIST CSF 2.0 Recover and Respond, DORA, NIS2, SOC 2 A1, and PCI DSS 12.10 as the framework-specific reads alongside.

ISO 22301 vs ISO/IEC 27031

ISO 22301 is the certifiable BCMS standard that covers the broader organisation: business impact analysis, business continuity strategy, business continuity plans and procedures, exercising and testing, performance evaluation, and continual improvement. ISO/IEC 27031 is the ICT-readiness companion that operates beneath ISO 22301 clauses 8.2 to 8.5 for the ICT scope. Programmes certifying against ISO 22301 typically operate IRBC under ISO/IEC 27031 so the BCMS auditor reads the ICT-side evidence against an international ICT-readiness standard rather than against a programme-specific plan.

ISO 22301 vs ISO/IEC 27001

ISO/IEC 27001 is the certifiable information security management system standard. The two management systems are designed to be integrated: ISO 22301 expects business continuity, and ISO/IEC 27001 Annex A 5.29 (information security during disruption) and 5.30 (ICT readiness for business continuity) are the certifiable controls in the ISMS that read directly against ISO 22301 and ISO/IEC 27031. Programmes operating both standards typically run an integrated management system where one operating record produces evidence for both audit cycles.

ISO 22301 vs NIST SP 800-34

NIST SP 800-34r1 (Contingency Planning Guide for Federal Information Systems) is the US federal contingency planning guide that covers business impact analysis, contingency strategy, plan documentation, testing, training, plan maintenance, and the relationships between the various continuity disciplines (BCP, DRP, COOP, ISCP, OEP, CRP). ISO 22301 is the international BCMS standard. The two are complementary rather than competing: 800-34r1 supplies the federal-grade contingency planning vocabulary and the integration model across the continuity-plan family; ISO 22301 supplies the international BCMS standard. Programmes operating across both regimes use 800-34r1 as the integration spine and ISO 22301 as the certifiable BCMS reference.

ISO 22301 vs NIST CSF 2.0

NIST CSF 2.0 Recover function (RC.RP recovery planning, RC.CO communications, RC.IM improvement) and Respond function (RS.MA management, RS.AN analysis, RS.MI mitigation, RS.CO communications, RS.RP reporting) cover the framework-level outcome statements for response and recovery. ISO 22301 reads beneath the Recover and Respond functions as the operating standard the outcome statements are evidenced through. Programmes operating against the CSF 2.0 outcome model use ISO 22301 as the implementation companion that supplies the management system depth the framework-level outcomes are achieved through.

ISO 22301 vs DORA Articles 11, 12, and 14

DORA Article 11 (ICT business continuity policy), Article 12 (backup, restoration, and recovery procedures), and Article 14 (communication) impose detailed ICT continuity obligations on EU financial entities. ISO 22301 reads as the wider BCMS the DORA-specific ICT continuity obligations sit inside. Financial entities subject to DORA build the BCMS evidence pack against ISO 22301 so the DORA-specific ICT continuity policy, recovery procedures, testing programme, and communication discipline read as the financial-services-specific implementation of the wider BCMS.

ISO 22301 vs NIS2 Article 21(2)(c)

NIS2 Article 21(2)(c) requires essential and important entities to manage business continuity, including backup management, disaster recovery, and crisis management. ISO 22301 is the recognised international BCMS standard programmes operating across the NIS2 sectors typically adopt to demonstrate the management measures the directive expects. The directive does not name a specific standard; ISO 22301 reads as the natural BCMS reference for the management measures evidence.

ISO 22301 vs SOC 2 Availability criteria

SOC 2 Trust Services Criteria A1.1 (capacity), A1.2 (environmental protections and recovery infrastructure), and A1.3 (recovery plan testing) cover availability commitments service organisations evidence to user entities and auditors. ISO 22301 reads beneath the A1 criteria as the BCMS standard the recovery infrastructure, the recovery procedures, and the testing record read against. Service organisations operating against SOC 2 use the BCMS discipline to produce the A1 evidence pack continuously rather than reconstructing it at examination time.

ISO 22301 vs PCI DSS 12.10

PCI DSS Requirement 12.10 covers incident response planning, testing, and personnel responsibilities for entities handling cardholder data. Requirement 12.10.1 (incident response plan) and 12.10.2 (testing and review) read against the BCMS exercising and incident response discipline. Programmes operating ISO 22301 alongside PCI DSS use the BCMS as the management system that produces the 12.10 evidence as a documented byproduct of the BCMS cycle rather than as a separate compliance exercise.

Where ISO 22301 sits next to other framework pages

ISO 22301 is the certifiable BCMS standard; the adjacent framework pages cover the regimes the BCMS reads alongside. The pages below are the ones BCMS programmes most often read together when producing the integrated evidence pack.

  • The ISO/IEC 27031 framework page covers the ICT readiness for business continuity standard. ISO/IEC 27031 sits beneath ISO 22301 clauses 8.2 to 8.5 as the ICT-specific operating companion the BCMS auditor reads for the ICT scope.
  • The ISO/IEC 27001 framework page covers the certifiable ISMS standard. Annex A 5.29 (information security during disruption) and A 5.30 (ICT readiness for business continuity) are the certifiable controls in the ISMS that read directly against ISO 22301 and ISO/IEC 27031. Programmes operating both standards typically run an integrated management system.
  • The ISO/IEC 27035 framework page covers the incident management standard. The handoff from operational incident response to the BCMS recovery declaration is the integration the holistic discipline expects.
  • The NIST SP 800-61 framework page covers the US federal incident handling guide. The integration between operational incident handling (where 800-61 lives) and BCMS recovery declaration (where ISO 22301 lives) is the same handoff named from the federal direction.
  • The DORA framework page covers the EU Digital Operational Resilience Act for financial entities. Articles 11 (ICT business continuity policy), 12 (backup, restoration, and recovery procedures), and 14 (communication) read against ISO 22301 as the wider BCMS the financial-services ICT continuity obligations sit inside.
  • The NIS2 framework page covers the EU directive on cybersecurity for essential and important entities. Article 21(2)(c) requires business continuity management for which ISO 22301 is the natural BCMS reference. Article 23 incident reporting reads alongside ISO/IEC 27035 and ISO 22301 communication discipline.
  • The NIST CSF 2.0 framework page covers the framework-level outcome model. The Recover function (RC.RP, RC.CO, RC.IM) and the Respond function (RS.MA, RS.AN, RS.MI, RS.CO, RS.RP) read against ISO 22301 as the implementation companion that supplies the management system depth the outcome statements are achieved through.
  • The SOC 2 framework page covers the AICPA Trust Services Criteria. A1.1 (capacity), A1.2 (environmental protections and recovery infrastructure), and A1.3 (recovery plan testing) read against the same BCMS discipline ISO 22301 expects.
  • The PCI DSS framework page covers the payment card industry data security standard. Requirement 12.10 incident response planning reads against the BCMS exercising and incident response discipline.
  • The ISO/IEC 27036 framework page covers the supplier-relationship security standard. The supplier-side BCDR clauses read alongside ISO 22301 so the acquirer-side recovery posture does not assume supplier-side readiness without evidence.

Where SecPortal fits in an ISO 22301 programme

SecPortal is the operating layer for the BCMS programme record, not a replacement for the standard itself, not a business continuity software suite, not a disaster recovery automation platform, not an IT service management platform, and not a backup and recovery infrastructure controller. The platform handles the workstreams that produce the ISO 22301 evidence (engagement structure for the per-cycle BCMS work, finding intake from after-action reviews and audits and incident post-mortems, severity scoring under CVSS 3.1 where availability is the impact axis, retest evidence paired to the corrective action follow-up, exception register with named owner and expiry, document management for the policy and procedures and exercise records, the activity log certification bodies and regulators read against). The same workspace that hosts the BCMS record hosts the technical assessment evidence the recovery design depends on, so the line from policy to evidence stays traceable.

  • Engagement management dedicated to the BCMS operating cycle, with per-cycle engagements for the BIA refresh, the risk assessment refresh, the strategy review, the plan refresh, the exercise programme, the management review, the internal audit, and the corrective action follow-up so the PDCA cadence reads as scheduled work rather than as reactive triage
  • Findings management with CVSS 3.1 scoring, CWE tags, and structured fields so the gaps surfaced by exercises, after-action reviews, internal audits, certification audits, and incident post-mortems read as the same finding record the rest of the security and continuity programmes use, and the corrective action follow-up does not bifurcate into a BCMS-only track and a security-only track
  • Bulk finding import that converts the after-action records, the internal audit findings, the certification audit observations, the regulator review observations, and the third-party assessment outputs (cloud-provider compliance reports, supplier BCDR attestations, sector-regulator findings) into structured findings on the workspace, so the BCMS evidence pack reads against the same finding ledger the operational security and continuity programmes use
  • Document management for the BCMS policy, the BCMS scope statement, the context analysis, the BIA outputs, the risk assessment outputs, the continuity strategy, the per-activity plans, the exercise calendar, the after-action records, the incident response playbooks, the crisis management plan, the dependency map, the training records, and the management review minutes, with version history per artefact and named custodian per file
  • Activity log with CSV export that captures every state change to a BCMS engagement, an exercise record, a plan update, a BIA refresh, a finding from after-action review, a corrective action, a change-impact assessment, or a management review outcome, so an internal auditor, a certification body, a regulator, or an audit committee can reconstruct the BCMS operating record without a multi-team excavation
  • Compliance tracking that reads the same BCMS evidence pack across ISO 22301, ISO/IEC 27031, ISO/IEC 27001 Annex A 5.29 and 5.30, NIST SP 800-34, NIST CSF 2.0 Recover and Respond functions, DORA Article 11 to 14, NIS2 Article 21(2)(c), SOC 2 A1.1 to A1.3, PCI DSS 12.10, and the sector-regulator reads (FFIEC, EBA, MAS TRM, APRA CPS 234, RBI, HKMA)
  • Continuous monitoring schedules (daily, weekly, biweekly, monthly) that run the external-scan and authenticated-scan baselines against the in-scope services and activities on cadence, so the operational exposure surface reads alongside the BCMS evidence pack rather than as a separate track
  • Retesting workflows that pair each exercise after-action finding to a verification step so the corrective action is evidenced as closed against the same record the exercise produced, and the follow-up cycle is not lost between PDCA iterations
  • AI report generation that turns the operating BCMS record into an audit-committee narrative, a certification audit pack (BCMS scope, leadership review summary, BIA outputs digest, exercise programme summary), a regulator pack (DORA ICT continuity summary, NIS2 management measures evidence, SOC 2 A1 evidence summary), and an executive sponsor briefing without rewriting the underlying record
  • Team management with role-based access (owner, admin, member, viewer, billing) that keeps the BCMS owner, the BCMS coordinator, the activity owners, the business owners, the recovery operators, the crisis decision authority, GRC and compliance, internal audit, the external certification body liaison, and the executive sponsor on the same workspace with appropriate scoping per activity tier and per business line
  • Multi-factor authentication enforcement at workspace level for the BCMS operating records, so the identity assurance the standard expects for the operating record applies at access time as well as evidence time
  • Finding overrides with the eight-field decision chain (rationale, scope, named approver, expiry, compensating control, residual risk acceptance, refresh trigger, audit annotation) for the residual gaps that cannot be closed within one PDCA cycle, so the deferral is evidenced rather than silent and the residual risk position reads through to the management review minutes
  • Notifications and alerts that drive the BCMS cadence (BIA refresh due dates, exercise execution dates, management review meetings, internal audit cycle, certification audit windows, supplier BCDR attestation expiry, regulator notification clocks) so the cycle does not depend on tribal memory of when the next obligation is due

What SecPortal does not do

ISO 22301 is a management system standard that depends on the organisation operating business continuity, ICT readiness, incident management, and crisis management as coordinated functions. SecPortal is the operating record for the BCMS slice, not the business continuity software suite, not the IT service management platform, not the backup and recovery infrastructure, and not the third-party certification body. The honest scope below reads against the ISO 22301 boundary so the platform commitment is unambiguous.

  • SecPortal is not a business continuity software suite. The platform does not run a workshop facilitation environment, an automated BIA questionnaire engine, a dependency-mapping platform with discovery agents, or a simulation engine for scenario exercises. The BCMS workshops are facilitated where the wider continuity programme runs them; SecPortal carries the operating record the workshops produce.
  • SecPortal is not a disaster recovery automation platform. The platform does not execute failover, restoration, replication, or runbook automation. The recovery actions are executed by the responsible operators against the documented procedures on the platforms the activity actually runs on. SecPortal carries the procedures, the exercise records, the after-action reviews, the corrective action follow-up, and the evidence the BCMS audit reads against.
  • SecPortal is not an IT service management platform. The change management, incident management, and problem management workflows that ITSM platforms (ServiceNow, Jira Service Management, BMC Helix, ManageEngine ServiceDesk Plus, Cherwell, Freshservice) run for the wider ICT operation continue to live there. SecPortal carries the BCMS-side operating record alongside the ITSM record rather than replacing it.
  • SecPortal does not connect to AWS Resilience Hub, Azure Site Recovery, Google Cloud Disaster Recovery, VMware Site Recovery Manager, Veeam, Commvault, Rubrik, Cohesity, Zerto, or any other backup and recovery infrastructure. The infrastructure controls the technical recovery; SecPortal carries the BCMS programme record the infrastructure operates against.
  • SecPortal does not issue or verify ISO 22301, ISO/IEC 27031, ISO/IEC 27001, SOC 2, or any other certifications. Certification is performed by an accredited certification body or CPA firm. SecPortal carries the operating record the auditors and the regulators read against, with the artefact pack the audit fieldwork reads continuously rather than reconstructed at examination time.
  • SecPortal does not replace the named BCMS owner, the BCMS coordinator, the BIA owner per activity, the recovery owner per activity, the crisis decision authority, the regulator notification owner, or the management review authority. The platform carries the operating record so the programme is durable rather than tribal; the named owner runs the programme, the coordinator operates the cadence, the recovery owner exercises the procedure, the crisis authority decides, and the regulator owner notifies.
  • SecPortal does not ship packaged Jira, ServiceNow, Slack, Microsoft Teams, PagerDuty, SIEM, SOAR, GRC, CMDB, ERP, or HRIS push connectors for BCMS workflow automation. The BCMS reads alongside those systems where they exist; SecPortal is the operating record rather than the integration hub.
  • SecPortal does not enforce enterprise SSO, SCIM, SAML, or directory federation. The workspace authentication uses Supabase Auth with MFA TOTP enforcement; programmes that require enterprise identity federation do so through their identity provider against the wider IAM estate.

The operational workstreams the BCMS reads against already exist as named use cases on SecPortal. The security leadership reporting workflow covers the executive and audit-committee read against the BCMS performance posture. The audit fieldwork evidence request fulfillment workflow covers the certification audit liaison the BCMS evidence pack reads against. The cross-framework control mapping workflow reads the same BCMS evidence pack across ISO 22301, ISO/IEC 27031, ISO/IEC 27001 Annex A 5.29 and 5.30, DORA Articles 11 to 14, NIS2 Article 21(2)(c), NIST CSF 2.0 Recover and Respond, SOC 2 A1.1 to A1.3, and PCI DSS 12.10 so the cross-regime read is reconcilable rather than reconciled per audit. The control gap remediation workflow carries the corrective action follow-up the exercise after-action records, the internal audit findings, and the management review nonconformities feed. The breach notification and regulator readiness workflow covers the regulator-clock dimension the crisis management plan operates against. The incident response workflow covers the operational incident handling that hands off into the BCMS recovery declaration. The cyber insurance security evidence workflow bundles the BCMS evidence pack into the underwriter and broker read at renewal so the continuity posture is visible alongside the security posture.

For GRC and compliance teams running the BCMS alongside the wider information security and operational resilience programmes, the GRC and compliance teams workspace bundles the platform with the engagement structure the BCMS audit cadence reads against. For security operations leaders carrying the operational continuity posture into the management review, the security operations leaders workspace covers the per-cycle exercise programme, the after-action review, and the incident- driven improvement loop. For CISOs and security leaders carrying the audit-committee read against the operational resilience posture, the CISOs and security leaders workspace covers the board-side reporting model that sits on top of the BCMS operating record.

For deeper reading on the disciplines this standard reads against, the DORA ICT third-party risk management implementation guide covers the financial-services-specific ICT continuity expectations DORA Articles 11 and 12 read against. The incident response plan guide covers the incident-response discipline that hands off into the BCMS recovery declaration. The ransomware readiness program guide covers the ransomware-specific scenario the BCMS backup and recovery posture is most often tested against. The incident response tabletop exercise guide covers the desk-based exercise format the BCMS walkthrough cadence uses. The enterprise incident response at scale guide covers the multi-team operating model the BCMS crisis discipline reads alongside. The continuous control monitoring cadence research covers the cadence economics the BCMS exercise programme inherits from when balancing test cost against capability assurance.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Scope: the international BCMS standard

ISO 22301 is the certifiable management system standard for business continuity. It applies to organisations of any size, sector, and geography that want to plan, establish, implement, operate, monitor, review, maintain, and continually improve a BCMS. The 2019 edition aligns with the Annex SL high-level structure used by ISO/IEC 27001 and ISO 9001 so an organisation can integrate the BCMS with the wider management system estate rather than operating it as a parallel programme.

Eight load-bearing principles

The standard expects leadership and commitment, a risk-based approach, a process-based operating model, the PDCA lifecycle, continual improvement, a documented scope and context, defined roles and responsibilities, and demonstrable competence. The eight principles together distinguish a managed BCMS from a folder of static documents and are the orientation the rest of the requirements read against.

The PDCA operating model

ISO 22301 is structured around the Plan-Do-Check-Act cycle aligned with the wider ISO management system family. Plan covers context, leadership, planning, and support (Clauses 4 to 7). Do covers operation (Clause 8: BIA, risk assessment, strategy, plans, exercises). Check covers performance evaluation (Clause 9: monitoring, internal audit, management review). Act covers improvement (Clause 10: nonconformity and corrective action, continual improvement).

Business impact analysis (BIA) discipline

Clause 8.2.2 names business impact analysis as the load-bearing input the rest of the operating discipline reads against. The BIA covers activity identification, impact analysis over time, MTPD (maximum tolerable period of disruption), MBCO (minimum business continuity objective), RTO (recovery time objective), RPO (recovery point objective), and dependency mapping. ISO 22317 supplies the BIA-specific guidance the standard reads alongside.

Strategies, solutions, and plans

Clauses 8.3 and 8.4 name the artefacts that translate BIA outputs into operational capability. Strategies are the chosen approaches. Solutions are the technical, operational, and procedural arrangements that implement them. Plans are the documents the operators read at the moment of disruption. The three artefact layers read together as one continuity posture rather than as three separate disciplines.

Exercising and testing

Clause 8.5 expects the BCMS to be exercised on a documented programme covering desk-based walkthroughs, simulations, partial tests, and full tests on a cadence proportionate to the activity criticality. Each exercise produces an after-action record. The exercise programme is the discipline that converts a documented BCMS into a tested capability rather than a paper readiness.

Performance evaluation and management review

Clause 9 expects monitoring and measurement, internal audit on a programme cycle, and a periodic management review with documented inputs (BCMS performance, exercise outcomes, incident learnings, audit results, residual risk, resource requests) and documented outputs (decisions, actions, resource allocations). Performance evaluation is the discipline that surfaces the BCMS gaps before the certification audit does.

Cross-walk to ISO/IEC 27031

ISO/IEC 27031 (Guidelines for information and communication technology readiness for business continuity) is the ICT-readiness companion that sits beneath ISO 22301 clauses 8.2 to 8.5 for the ICT scope. Programmes certifying against ISO 22301 typically operate IRBC under ISO/IEC 27031 so the BCMS auditor reads the ICT-side evidence against an international ICT-readiness standard rather than against a programme-specific plan.

Cross-walk to ISO/IEC 27001 Annex A 5.29 and 5.30

ISO/IEC 27001:2022 Annex A 5.29 (information security during disruption) and A 5.30 (ICT readiness for business continuity) are the certifiable ISMS controls that read directly against ISO 22301 and ISO/IEC 27031. Programmes operating both standards typically run an integrated management system where one operating record produces evidence for both audit cycles.

Cross-walk to DORA Articles 11, 12, and 14

DORA Article 11 (ICT business continuity policy), Article 12 (backup, restoration, and recovery procedures), and Article 14 (communication) impose detailed ICT continuity obligations on EU financial entities. ISO 22301 reads as the wider BCMS the DORA-specific ICT continuity obligations sit inside. Financial entities subject to DORA build the BCMS evidence pack against ISO 22301 with DORA-specific ICT continuity policy, recovery procedures, testing programme, and communication discipline read as the financial-services implementation of the wider BCMS.

Cross-walk to NIS2 Article 21(2)(c)

NIS2 Article 21(2)(c) requires essential and important entities to manage business continuity, including backup management, disaster recovery, and crisis management. ISO 22301 is the recognised international BCMS standard programmes operating across the NIS2 sectors typically adopt to demonstrate the management measures the directive expects. The directive does not name a specific standard; ISO 22301 reads as the natural BCMS reference for the management measures evidence.

Cross-walk to SOC 2 A1.1, A1.2, and A1.3

SOC 2 Trust Services Criteria A1.1 (capacity), A1.2 (environmental protections and recovery infrastructure), and A1.3 (recovery plan testing) cover availability commitments service organisations evidence to user entities and auditors. ISO 22301 reads beneath the A1 criteria as the BCMS standard the recovery infrastructure, the recovery procedures, and the testing record read against. Service organisations operating against SOC 2 use the BCMS discipline to produce the A1 evidence pack continuously rather than reconstructing it at examination time.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Document management for every security engagement

Every action recorded across the workspace

Compliance tracking without a full GRC platform

AI-powered reports in seconds, not days

Collaborate across your entire team

Multi-factor authentication on every workspace

Monitor continuously catch regressions early

Verify fixes and track reopens on the same finding record

Finding overrides that survive every scan cycle

Bulk finding import bring your scanner data with you

Notifications and alerts for the people who carry the work

Run the BCMS programme on one operating workspace

Hold the BCMS policy, the scope and context analysis, the BIA outputs, the risk assessment outputs, the continuity strategy, the per-activity plans, the exercise programme and after-action records, the internal audit programme, the management review minutes, and the corrective action follow-up on one workspace. Carry the same record into ISO/IEC 27031, ISO/IEC 27001 Annex A 5.29 and 5.30, DORA Articles 11 to 14, NIS2 Article 21(2)(c), NIST CSF 2.0 Recover and Respond, SOC 2 A1.1 to A1.3, and PCI DSS 12.10 without rebuilding the evidence pack per audit. Start free.

Get Started Free

No credit card required. Free plan available forever.