Already ISO 22301 Certified? Here’s Exactly What NIS2 Requires on Top
You have already invested the time and resource that most NIS2-covered organisations have not: your Business Impact Analysis is documented to ISO 22301 standard, your BC plans are tested annually, and your management team formally reviews the BCMS. That rigour puts you in a genuinely strong position for NIS2 compliance — better than most entities scrambling to meet October 2024 transposition deadlines.
But ISO 22301 certification and NIS2 Article 21(2)(c) compliance are not the same thing. Your certification satisfies several NIS2 business continuity requirements directly. Three specific requirements fall entirely outside the standard’s scope.
This guide maps the clause-by-clause alignment between ISO 22301 and NIS2 Article 21(2)(c), identifies the three gaps that remain after certification, and provides a structured checklist of the minimal additions needed to close them. It assumes you know both frameworks — there is no introduction to either standard here. For a broader overview of all ten NIS2 Article 21 domains, see our complete guide to NIS2 requirements. For the parallel ISO 27001 comparison, see NIS2 vs ISO 27001.
What NIS2 Article 21(2)(c) Actually Requires
NIS2 Article 21(1) requires essential and important entities to implement “appropriate and proportionate technical, operational and organisational measures” to manage risks to network and information systems. Article 21(2)(c) specifies: “business continuity, such as backup management and disaster recovery, and crisis management.”
Three mandatory domains flow from that text.
Backup management requires protecting data through copies and recovery procedures that survive the same threat affecting production systems. A ransomware attack that encrypts both production data and directly connected backup storage is not backup management — it is a single point of failure stored in two locations. NIS2 expects backups to be isolated, verified, and recoverable within defined time windows under realistic threat conditions, not only under the assumption of clean physical failures.
Disaster recovery requires restoring operations after significant disruptions, with documented recovery sequences that prioritise critical services and define acceptable timeframes. Critically, NIS2 applies this requirement to cyber incidents — not only the physical disaster scenarios that traditional DR plans were designed for. A plan that restores operations after a flood but has no procedure for restoring operations after a ransomware encryption event does not satisfy this requirement.
Crisis management requires coordinated human response protocols covering internal escalation and regulatory notification. Under NIS2 Article 23, significant incidents require a 24-hour early warning to the national competent authority or CSIRT, a full notification within 72 hours including an initial impact assessment and indicators of compromise, and a final report within one month. These timelines are binding obligations — they must be built into your crisis management procedures as hard deadlines with named responsibilities.
The Commission Implementing Regulation (EU) 2024/2690, published in October 2024, translates Article 21 into binding technical requirements. For business continuity, the CIR adds an explicit testing obligation: BC and DR plans must be exercised periodically, not merely documented. ENISA’s June 2025 Technical Implementation Guidance recommends going further, with cyber-attack simulations and red team exercises that validate recovery under realistic attack conditions.
What ISO 22301 Already Delivers — The Alignment Zones
For ISO 22301-certified organisations, the following clause mapping identifies where your certification satisfies NIS2 and what audit evidence you already hold.
| ISO 22301 Clause | NIS2 Art. 21(2)(c) Requirement Satisfied | Audit Evidence You Already Hold |
|---|---|---|
| 8.2 Business Impact Analysis | Impact-based recovery prioritisation; backup frequency (RPO) | BIA documentation with MTPD, RTO, RPO per critical function |
| 8.3 Continuity Strategies | Disaster recovery planning; resilience architecture choices | Strategy documents mapping recovery options to RTO thresholds and budget |
| 8.4 Business Continuity Plans | Crisis management framework; escalation and communication | Documented plans with named ownership, escalation chains, communication protocols |
| 8.5 Testing and Exercising | Plan testing obligation (CIR 2024/2690, Annex 4) | Exercise records, debrief reports, corrective action logs |
| 9.3 Management Review | Governance accountability (NIS2 Art. 20) | Minutes showing leadership confirmation of BCMS fitness and adequacy |
| 10.2 Continual Improvement | Continuous improvement obligation | Non-conformity records and corrective action tracking |
BIA methodology is your strongest alignment point. ISO 22301 Clause 8.2 requires you to identify critical functions, map their dependencies, and establish MTPD, RTO, and RPO per process through documented interviews with process owners. NIS2 auditors looking for evidence of impact-based recovery prioritisation will find exactly that structure in a compliant BIA. The methodology is equivalent — the difference, as explained below, lies in what the RTO values must reflect.
BC plan structure under Clause 8.4 satisfies NIS2’s crisis management requirement in substance. Clear ownership, documented escalation paths, internal and external communication protocols, and accessible documentation are structurally equivalent requirements. Plans that pass ISO 22301 surveillance audits satisfy the structural expectations NIS2 supervisors will look for.
Testing is where Clause 8.5 delivers the most direct alignment. The CIR 2024/2690 requires periodic testing of BC and DR plans. Regular tabletop exercises and scenario-based drills documented under Clause 8.5 meet the base regulatory requirement. ENISA recommends cyber-specific exercises on top of this — addressed in the gap section below.
Management accountability aligns through Clause 9.3. NIS2 Article 20 holds management bodies personally accountable for approving and overseeing cybersecurity risk management measures, including business continuity. Your existing management review process demonstrates that governance engagement. To strengthen the alignment, ensure review minutes explicitly reference cybersecurity risks, not only operational continuity themes — a distinction that matters when a supervisor reviews the record.
Where NIS2 Goes Beyond ISO 22301 — The Three Gaps
ISO 22301 certification does not satisfy NIS2 in full. Three requirements fall outside the standard’s scope and require specific additions.
Gap 1: Cyber-Specific Recovery Objectives for Essential Service Functions
ISO 22301 Clause 8.2 provides a rigorous BIA methodology but leaves the actual RTO and RPO values entirely to organisational judgement. Your BIA assigns a 48-hour RTO to a given system because that is the point at which internal operational damage becomes unacceptable to your business. That is correct ISO 22301 practice.
Under NIS2, recovery objectives for functions that deliver essential services must reflect their impact on wider society and on sectors that depend on them — not only internal operational tolerance. A water utility that assigns a 48-hour RTO to its distribution control network because that is its internal operational threshold fails NIS2 if that system is what maintains water pressure to hospitals and emergency services. The standard of “unacceptable harm” changes when you are an essential entity under the directive.
The CIR 2024/2690 requires entities to assess criticality at the societal and cross-sector level. Your BIA rationale — the documented reasoning behind each RTO and RPO — must show that you considered your essential service designation and the dependency relationships that flow from it, not only internal business pain thresholds. This is an annotation to your existing BIA methodology, not a rebuild of the framework.
What to add: For each function within your NIS2 entity designation scope, add a societal impact dimension to your BIA rationale. Document explicitly why each assigned RTO is acceptable given your sector’s dependency relationships and your designation as an essential or important entity.
Gap 2: Operational Technology (OT) Continuity
ISO 22301 is deliberately technology-agnostic. In practice, most BCMS implementations focus on IT systems and operational processes, and BC plans rarely address the recovery challenges specific to industrial control systems. For NIS2-covered sectors where OT is critical — energy, water and wastewater, manufacturing, digital infrastructure — three OT-specific gaps typically appear in an ISO 22301-based BCMS.
Firmware and configuration backup: Most IT backup solutions cannot restore PLC firmware, RTU configurations, or legacy industrial operating systems. The WannaCry ransomware demonstrated this gap directly: organisations whose IT disaster recovery was functional still found OT networks unrecoverable because no procedure existed for OT device restoration. If your BC plan references “system backup” without distinguishing IT data from OT device configuration, your OT recovery capability is undocumented and almost certainly untested.
Control loop timing validation: DR procedures that introduce timing jitter in process control environments can trigger safety incidents even after a technically successful recovery. A restored SCADA system that fails process timing acceptance tests must not return to production automatically. Your OT recovery procedures need explicit acceptance criteria — including timing validation and process parameter verification — before reconnection to live operations.
Network segmentation during recovery: Recovery time pressure creates incentives to connect OT networks to IT infrastructure temporarily to accelerate data transfer. This recreates the attack vector that caused the incident in the first place. BC plans must explicitly govern OT/IT connections during recovery, with named approval authority for any exception and a log requirement.
What to add: If OT assets fall within your NIS2 scope, draft OT-specific BC annexes covering firmware backup schedules, network segmentation rules during recovery, and acceptance testing criteria before restored systems return to service. These annexes attach to your existing BC plan structure — they do not replace it.
Gap 3: Supply Chain Resilience Beyond Tier-1 Suppliers
ISO 22301 Clause 8.2 requires mapping external dependencies in your BIA, including suppliers whose failure would affect your recovery. Most BCMSs identify which suppliers matter to organisational resilience and build workarounds. NIS2 Article 21(2)(d) — a separate mandatory domain from Article 21(2)(c) — extends supply chain obligations in three specific ways that an ISO 22301 BCMS does not typically address.
Supplier BC capability verification: NIS2 requires formal evidence that critical ICT suppliers have tested BC plans for the specific services they provide to you — not just that they hold a certification. A supplier’s ISO 22301 certificate covers their organisation globally. It does not confirm that the specific service your operations depend on is covered by a tested and current BC plan. Verification must be service-scoped and documented.
Supplier incident notification timelines: If your cloud provider or managed security service detects a service-affecting incident on day one and notifies you on day four, your own 72-hour CSIRT notification window has already expired by the time you learn the cause. Suppliers of critical ICT services must contractually commit to notifying you of significant incidents within your regulatory window — 24 hours for early warning, consistent with Article 23 requirements.
Tier-2 dependency mapping: NIS2’s supply chain risk scope extends beyond your direct suppliers. ENISA guidance requires visibility into the critical dependencies of Tier-1 ICT suppliers — specifically whether their own key components are sourced from concentrated Tier-2 markets that represent systemic risk to essential service continuity. Single-source dependencies in your suppliers’ supply chains become your risk under NIS2.
What to add: Extend your supplier management process to include BC capability verification for critical ICT vendors. Add incident notification clauses to critical vendor contracts. Conduct Tier-2 dependency mapping for your most essential ICT supply chains.
The Minimal Addition Framework for ISO 22301-Certified Organisations
The following checklist organises the gap closure work by implementation effort. None of these additions require rebuilding your BCMS — they extend a structure that ISO 22301 already provides.
Priority 1 — Documentation extensions (low effort, 1–5 days each):
- Add societal impact rationale to BIA entries for essential service functions. Document why each RTO is acceptable from a cross-sector dependency perspective, not only internal operational thresholds.
- Integrate the NIS2 Article 23 notification timeline (24h early warning / 72h full notification / 1-month final report) into crisis management procedures as a parallel regulatory track alongside internal escalation chains.
- Add national competent authority and CSIRT contact details to BC plan communication protocols, with named individuals responsible for each notification step.
- Update management review agenda items to explicitly reference NIS2 Article 20 obligations. Review minutes should record management’s affirmative engagement with cybersecurity risks, not only operational continuity themes.
- Produce a one-page compliance mapping document showing which ISO 22301 clauses satisfy which NIS2 Article 21(2)(c) sub-requirements. This becomes your primary audit artefact for demonstrating dual compliance to supervisory authorities.
Priority 2 — Plan extensions (medium effort, 1–4 weeks total):
- Draft OT-specific BC annexes if OT assets are in scope: firmware backup schedules, network segmentation protocols during recovery, acceptance criteria for timing validation before reconnection.
- Add cyber-attack scenarios (ransomware, credential compromise, supply chain incident) to your annual BC exercise programme. ENISA’s Technical Implementation Guidance specifically recommends cyber-attack simulations that validate recovery under realistic attack conditions.
- Extend supplier BIA to include BC capability verification for critical ICT vendors: a questionnaire confirming service-scoped BC plan coverage, a certificate scope review, or a contractual audit right.
Priority 3 — Structural additions (one-time effort, 4–8 weeks total):
- Add incident notification clauses to critical ICT vendor contracts specifying 24-hour notification for significant service-affecting incidents, with escalation contacts and a log requirement.
- Conduct a Tier-2 supply chain dependency mapping exercise for essential service functions. Identify concentration risks in your Tier-1 suppliers’ own supply chains.
- Run a structured tabletop exercise that validates all three gap areas simultaneously: OT recovery procedures, regulatory notification flow, and supplier notification chain response.
Who Needs to Act — Role Priorities
NIS2 Article 20 makes management bodies personally accountable for approving the organisation’s cybersecurity risk management approach. For NIS2 business continuity obligations, this means the board must affirmatively engage with BC governance — not merely delegate it to operations. The table below maps gap closure responsibilities by role.
| Role | Priority 1 Actions | Priority 2–3 Actions |
|---|---|---|
| BC Manager | BIA societal impact annotation; CSIRT contacts in crisis plans; compliance mapping document; management review agenda update | Cyber scenario design for exercises; OT annex coordination; supplier BIA extension |
| CISO | OT BC plan review; RTO validation rationale for essential service functions | Cyber exercise design; Tier-2 supply chain risk input; red team exercise scoping |
| Legal / Compliance | Management review Article 20 language; evidence of executive accountability | Supplier contract notification clauses; compliance mapping review and sign-off |
| Board / C-Suite | Management review participation; Article 20 awareness briefing | Approval of OT and supply chain investment requirements; liability exposure review |
Frequently Asked Questions
Does ISO 22301 certification mean we are NIS2 compliant for business continuity?
Not automatically. ISO 22301 satisfies the structural and methodological requirements of NIS2 Article 21(2)(c) — BIA methodology, BC plan format, testing cadence, and management governance. The three gaps above — cyber-specific recovery objectives for essential service functions, OT continuity procedures, and supply chain resilience — require specific additions regardless of certification status. ENISA’s Technical Implementation Guidance identifies ISO 22301 as an accepted framework, meaning certification is strong positive evidence, not automatic compliance.
Will a NIS2 supervisor accept ISO 22301 as audit evidence?
For the areas the standard covers, yes. ENISA maps ISO 22301 as an accepted good practice for business continuity obligations under NIS2. Your certification demonstrates documented, independently audited BC processes — significant positive evidence in a supervisory review. Supervisors will, however, look for evidence that the three gaps are addressed: societal impact rationale in BIA documentation, OT-specific procedures if OT is in scope, and supplier BC verification records.
How does this compare to what ISO 27001-certified organisations need to add?
ISO 27001 provides substantially less BC coverage than ISO 22301. ISO 27001 Annex A includes business continuity controls but does not require a full BCMS with documented BIA, tested plans, or management review. If you hold ISO 22301, your starting position for NIS2 Article 21(2)(c) compliance is considerably stronger than an ISO 27001-certified organisation — the gap is narrower and the evidence base is richer. For the full comparison, see our guide to NIS2 vs ISO 27001.
Does ISO 22301:2019 need to be updated for cyber requirements?
ISO 22301 was amended in 2024 (Amendment 1: Climate action changes), but the core BCMS requirements remain technology-agnostic. The cyber-specific additions NIS2 requires are extensions to your existing BCMS — OT annexes, cyber exercise scenarios, supplier notification clauses — not revisions to the ISO 22301 standard itself.
This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.
Sources
- NIS2 Directive Article 21 — Cybersecurity Risk-Management Measures (EU 2022/2555)
- ENISA Technical Implementation Guidance on Cybersecurity Risk Management Measures, June 2025
- ISO 22301 Clause 8: Operations — BIA, Strategies, Plans and Testing — ISMS.online
- How to Implement ISO 22301: BCMS Guide [BIA, BCP, Testing] — AdaptiveGRC
- NIS2 Requirements for Operational Continuity and Resilience — DRI France, April 2025
- Redesigning Business Continuity: NIS2 Calls for a New Approach — Xebia
- ISO 22301: Business Continuity Management Guide [NIS2, DORA] — AdaptiveGRC
