NIS2 Business Continuity: Requirements Under Article 21(2)(c)

Business continuity is the most commonly underdeveloped area in SME cybersecurity — and the one most likely to become a regulatory liability under NIS2. Fewer than one in five SMEs has a formal, documented business continuity plan. Directive (EU) 2022/2555 ends the grace period for that gap.

The requirement looks deceptively short. Article 21(2)(c) requires covered entities to implement measures covering “business continuity, such as backup management and disaster recovery, and crisis management.” Three components. One sentence. But the Commission Implementing Regulation (CIR) 2024/2690 translates that sentence into more than 20 specific technical requirements covering your BC plan’s mandatory content, your backup architecture, your recovery testing cadence, and your crisis team structure.

This guide maps each requirement to a practical step, explains what CIR Annex 4 demands at the technical level, and shows how the obligations scale proportionately for organisations of different sizes.

What Article 21(2)(c) Actually Requires

The exact text of Article 21(2)(c) of the NIS2 Directive requires essential and important entities to implement appropriate and proportionate technical, operational, and organisational measures covering:

“business continuity, such as backup management and disaster recovery, and crisis management”

Three components are explicitly named: backup management, disaster recovery, and crisis management. The phrase “such as” signals these are examples, not an exhaustive list. Your obligations extend to whatever continuity measures your risk profile demands.

The Commission Implementing Regulation (CIR) 2024/2690 provides the technical detail in Annex section 4, structured into three clusters:

• Annex 4.1 — Business continuity and disaster recovery plan (mandatory content, BIA, testing)
• Annex 4.2 — Backup and redundancy management (architecture, geographic separation, retention)
• Annex 4.3 — Recovery testing (restore verification, documented results, corrective action)

For entities directly covered by the CIR — DNS providers, TLD registries, cloud computing services, data centres, CDNs, managed service providers, online marketplaces, search engines, and trust services — these are binding technical requirements. For all other NIS2-covered entities, CIR Annex 4 is the authoritative interpretation of what “appropriate and proportionate” looks like under supervisory scrutiny. For a complete map of all ten Article 21 risk management measures, see our overview of NIS2 requirements.

Proportionality matters: A 50-person managed service provider and a large energy utility both face Article 21(2)(c). The scale, formality, and investment should differ accordingly. A smaller entity can satisfy the obligation with a well-tested 15-page plan. What it cannot do is have nothing at all.

Step 1 — Business Impact Analysis: The Foundation of Everything

CIR Annex 4.1.3 requires entities to “conduct a business impact analysis assessing potential disruption consequences, establishing continuity requirements for systems based on those results.” Recital 13 of the CIR reinforces this: entities are “encouraged to conduct thorough analysis establishing recovery time objectives, recovery point objectives, and service delivery objectives when performing the business impact analysis.”

These three metrics define the boundary conditions your entire BC programme must satisfy:

Metric	Definition	Example
RTO (Recovery Time Objective)	Maximum acceptable downtime — how long can this process be unavailable before the impact becomes unacceptable?	E-commerce order processing: 4 hours
RPO (Recovery Point Objective)	Maximum acceptable data loss — how far back can you afford to roll back to a backup?	Finance system: 1 hour
MTPD (Maximum Tolerable Period of Disruption)	Absolute outer limit before disruption causes irreversible harm — contracts broken, regulatory breaches, permanent customer loss.	Customer authentication: 24 hours

Work through the BIA in six steps:

1. Map critical processes — every process needed to deliver your core service, including manual alternatives and offline fallbacks, not just IT systems
2. Identify dependencies — for each process, document the systems, staff, suppliers, premises, and data it requires
3. Quantify the impact of disruption — revenue loss, contractual penalties, regulatory fines, and reputational damage per hour of downtime
4. Set RTO and RPO per process — your external payment gateway has a much tighter RTO than your internal HR portal
5. Flag single points of failure — dependencies that would simultaneously break multiple critical processes
6. Obtain management sign-off — the CIR requires BC documentation to be approved by management; the BIA is the starting document in that chain

A structured BIA output table gives you the inputs for every downstream decision — recovery strategy, backup frequency, and system recovery sequencing:

Business Process	Supporting Systems	Process Owner	RTO	RPO	MTPD
Order processing	ERP, payment gateway	COO	2 hours	30 minutes	8 hours
Customer authentication	Identity provider, Active Directory	CTO	1 hour	Real-time sync	4 hours
Incident logging	SIEM, ticketing system	CISO	4 hours	1 hour	24 hours
Financial reporting	Accounting platform, ERP	CFO	8 hours	1 hour	72 hours

Without a completed BIA, your backup frequency settings are guesses and your recovery sequence is arbitrary. For the risk methodology that feeds into your BIA, see our NIS2 risk assessment guide.

Step 2 — Developing a Business Continuity Strategy

The BIA tells you what you cannot afford to lose and for how long. The BC strategy tells you how you will prevent those losses. This is a high-level decision document — not operational procedures — recording the recovery approach selected for each critical process or process tier.

Four strategies cover most scenarios:

• Redundancy — duplicate systems with automatic failover (active-active or active-passive). The only viable option for RTOs under one hour, but the highest infrastructure cost
• Hot/warm/cold standby — pre-configured recovery environments at different states of readiness; trade recovery speed against infrastructure investment
• Manual fallback — documented procedures to perform functions without IT systems. Highly effective for lower-criticality processes with RTOs over eight hours, and systematically underused by organisations that treat BC as purely an IT problem
• Accepted downtime — for processes with loose RTOs, explicitly accept planned downtime within the agreed recovery window. Document this decision with management sign-off; it is a deliberate risk decision, not an oversight

Proportionality in practice: Apply your most expensive strategy only to your tightest-RTO processes. A manufacturing SME may need full redundancy for its production control system and a manual fallback for its HR system — not expensive infrastructure everywhere. The BC strategy document should also address supplier alternatives, alternative work locations, and cloud backup data sovereignty requirements.

Step 3 — The Business Continuity Plan

The BC plan is the operational document that staff activate during a disruption. CIR Annex 4.1.2 specifies eight categories of mandatory content:

• Purpose, scope, and intended audience — which scenarios does this plan address? Who is authorised to activate it?
• Roles and responsibilities — assigned by name or role title, with a named backup for every key position
• Contact information and communication channels — emergency numbers, out-of-band communication methods (in case email is compromised), and regulatory notification contacts
• Activation and deactivation conditions — specific, unambiguous criteria for activating and standing down; not a vague “when there is a significant incident”
• Recovery operation sequencing — the order in which systems and processes are restored; the sequence is rarely obvious and must be validated through testing
• Operation-specific recovery plans with objectives — each critical process gets its own procedure tied to the RTO and RPO from the BIA
• Required resources — backup media locations, recovery infrastructure, vendor emergency contacts, spare hardware lists
• Restoration procedures from temporary measures — how to transition back from manual workarounds to normal operations without introducing new errors or data inconsistencies

The practical test of any BC plan: hand it to someone who has never read it and ask them to follow it at 2am under pressure. If they cannot, the plan needs work. CIR Annex 4.1.4 requires the plan to be tested — the only question is whether that test happens in a controlled exercise or a live incident.

Step 4 — Crisis Management

Article 21(2)(c) names crisis management separately from business continuity for a reason. A BC plan tells you how to restore systems. Crisis management tells you how to make decisions and communicate when everything is failing at once. The two disciplines are complementary but distinct, and most organisations underinvest in the second.

A compliant crisis management framework requires a defined team with pre-assigned roles and pre-authorised decision rights documented in advance:

Role	Primary Responsibilities	Pre-Authorised Decisions
Executive Sponsor	Resource allocation, senior stakeholder communications, public statements above threshold severity	Spending above coordinator limit; board engagement
Crisis Coordinator	Overall incident management, team activation, progress tracking against recovery objectives	Invoke BC plan; engage external IR firm up to defined limit; authorise emergency overtime
Technical Lead	IT recovery direction, technical damage assessment, recovery sequencing decisions	Emergency system shutdowns; network segment isolation
Communications Lead	Internal notifications, customer communications, media management	Issue communications below executive-level threshold
Legal/Compliance Contact	Regulatory notification obligations, liability assessment, evidence preservation	Confirm Article 23 notification timing and content

Pre-authorised spending is not optional. In a ransomware incident, the decision to engage a forensic incident response firm may need to be made at 3am on a Sunday. A crisis coordinator who must wait for board approval before acting is a material operational risk. Document spending authorities explicitly in the crisis plan and test them during tabletop exercises — the exercise will reveal whether the limits are realistic.

Escalation criteria should define specific thresholds that trigger full crisis team activation:

• Any confirmed ransomware infection, destructive attack, or data breach
• Service disruption exceeding a defined number of hours affecting a defined user threshold
• Any incident meeting NIS2’s “significant incident” criteria under Article 23(3)
• Projected financial impact exceeding a defined threshold

Communication protocols must address three channels. Internal: who is notified first, by what method, in what order — note that email may be compromised in a cyber incident, so a backup out-of-band channel is essential. External regulatory: your national CSIRT or competent authority must receive notification under Article 23; the 24-hour early warning deadline applies from the moment you become aware of a significant incident. See our incident reporting guide for the full notification timeline. Customer communications: define what information is communicated at what severity threshold, and who approves the message before it goes out.

Step 5 — Backup and Recovery Requirements

CIR Annex 4.2 is the most technically specific section of the business continuity requirements.

CIR 4.2.1 requires entities to “maintain complete backup copies of data and provide sufficient available resources, including facilities, network and information systems and staff, to ensure an appropriate level of redundancy.”

CIR 4.2.2 requires backup procedures to specify: recovery timeframes aligned to BIA-defined RPOs; completeness and accuracy including configuration backups and cloud-stored data; geographically distant secure storage separate from primary sites; access controls matching asset classification levels; data restoration procedures; and retention periods aligned with business and regulatory requirements.

The 3-2-1-1-0 backup rule is the practical implementation framework that satisfies these requirements:

Rule Component	What It Means	CIR Requirement Satisfied
3 copies of data	Primary data plus two backup copies	CIR 4.2.1 — complete backup copies maintained
2 different storage types	Two distinct media (e.g., disk and cloud, or disk and tape)	Resilience against single-media failure
1 copy offsite	Geographically separated from primary infrastructure	CIR 4.2.2 — geographically distant secure storage
1 copy offline or immutable	Air-gapped or write-once storage that ransomware cannot encrypt	Resilience against ransomware scenarios; redundancy integrity
0 errors verified	Confirmed through documented restore testing, not assumed	CIR 4.3 — tested recovery of backup copies with documented results

Supervisory authorities and auditors will look for these common gaps:

Gap	Risk	Fix
No configuration backups	System rebuild takes weeks instead of hours	Add OS/application configs and golden images to backup scope
Backups on the same network segment as production	Ransomware encrypts backups alongside live data	Geographic separation plus an offline copy — both are mandatory
Restore procedure never tested	Backups may be corrupt or incomplete at the moment of crisis	Quarterly restore tests to an isolated environment, with documented results
SaaS and cloud data excluded from backup scope	Microsoft 365, CRM, and cloud-platform data is permanently lost	CIR 4.2.2 explicitly covers cloud-stored data — configure third-party backup for all SaaS platforms
Retention period not documented or insufficient	Cannot support regulatory investigation or legal hold requirements	Align retention to sector-specific legal obligations and document the rationale

The cloud data gap is particularly common and particularly risky. CIR 4.2.2 explicitly requires backup procedures to address “cloud-stored data.” Your Microsoft 365 email, SharePoint, and CRM data are not automatically backed up to your specifications by the vendor. Organisations that have moved fully to cloud-based infrastructure often discover they have no independent backup of their SaaS estate until a data loss event forces the discovery.

Step 6 — Testing, Exercising, and Continuous Improvement

CIR Annex 4.1.4 requires plans to be “tested, reviewed and, where appropriate, updated at planned intervals and following significant incidents or significant changes to operations or risks.” Entities must also “incorporate lessons learned from such tests” — creating a mandatory continuous improvement cycle, not a one-off compliance exercise.

ENISA’s Technical Implementation Guidance takes this further, recommending cyber-attack simulations and red team exercises that validate whether critical services can actually be restored under realistic attack conditions. The gap between a theoretical recovery strategy and an operational one often only becomes visible under adversarial pressure.

Three levels of testing address different risk dimensions:

Level	Method	Recommended Frequency	What It Tests
Tabletop exercise	Scenario-based walkthrough with key staff	Semi-annually	Decision-making under pressure, role clarity, escalation procedures, communication protocols
Functional test	Actual backup restoration to an isolated environment	Quarterly	That backups are complete, accurate, and restorable within the stated RPO
Full-scale exercise	Live activation of BC/DR procedures in a controlled scenario	Annually	End-to-end recovery timing, system interdependencies, RTO/RPO targets under pressure

Every test must produce documented output: date and participants, scenario used, issues identified with severity ratings, corrective actions with owner assignments and resolution deadlines, outcomes measured against stated RTO/RPO targets, and management sign-off. These records are your primary audit evidence for CIR Annex 4.1.4 compliance.

Post-incident review is a separate but equally important trigger. After any significant incident — even one managed without full BC activation — review the plan and update it. Near-misses reveal gaps before they become failures. The CIR 2024/2690 requirement for post-incident updates is explicit. For a full compliance tracking framework, see our NIS2 compliance checklist.

ISO 22301 and NIS2: Practical Alignment

ISO 22301:2019 is the international standard for Business Continuity Management Systems. It is not required by NIS2, but implementing it substantially satisfies the Article 21(2)(c) obligations and provides a structured path to evidenced compliance during supervisory inspections.

NIS2 / CIR Requirement	ISO 22301:2019 Clause
Business Impact Analysis (CIR 4.1.3)	Clause 8.2.2
BC Plan mandatory content (CIR 4.1.2)	Clauses 8.4–8.5
Backup and redundancy management (CIR 4.2)	Clause 8.7
Testing at planned intervals (CIR 4.1.4)	Clause 9.1
Lessons learned incorporated (CIR 4.1.4)	Clause 10.1
Management oversight and sign-off	Clause 5.1

For organisations already working toward ISO 27001, ISO 22301 is a natural companion — both standards use a Plan-Do-Check-Act structure and share documentation, review, and internal audit requirements. An ISO 22301 certificate signals to supervisory authorities that an independent third party has verified your BCMS against a recognised international standard, which is among the most efficient paths to evidenced compliance for entities subject to recurring supervisory scrutiny.

Certification is not required to satisfy NIS2. But the standard’s framework — particularly its BC plan structure and BIA methodology — provides a solid structural foundation even for organisations that do not pursue formal certification.

NIS2 Business Continuity Templates You Will Need

Implementing Article 21(2)(c) in full requires at minimum six documented outputs. Many SMEs coming to NIS2 compliance have none of these in a formal, tested state:

1. Business Impact Analysis Template — structured worksheet capturing critical processes, systems, owners, RTO, RPO, and MTPD per process (CIR 4.1.3)
2. BIA Questionnaire — data collection tool for department heads, standardising the input gathering process across business units
3. Business Continuity Strategy Document — records the strategic recovery approach selected for each critical process tier
4. Business Continuity Plan — the operational activation document covering all eight mandatory content categories in CIR 4.1.2
5. Crisis Management Plan — team structure, escalation criteria, communication protocols, and pre-authorised spending authorities
6. BC Testing Log and Report Template — captures each test with issues identified, corrective actions, and management sign-off (CIR 4.1.4)

Our NIS2 Business Continuity Pack includes ready-to-use versions of all six documents, each mapped directly to the CIR Annex section it satisfies. The templates are structured for organisations building compliant BC documentation from the ground up.

Frequently Asked Questions

Does NIS2 require a formal written Business Continuity Plan?

Yes. CIR Annex 4.1.1 explicitly requires entities to “establish and maintain a plan to apply when incidents occur.” This must be a documented plan, not informal arrangements or institutional knowledge. CIR Annex 4.1.2 then specifies eight categories of mandatory content the plan must address.

What is the difference between a BC plan and a disaster recovery plan under NIS2?

A Business Continuity Plan covers how the organisation maintains critical business processes during and after a disruption — including manual procedures, alternative work locations, communication, and staff arrangements. A Disaster Recovery Plan focuses specifically on restoring IT systems and data. Both are required under CIR Annex 4.1. They typically exist as separate documents, with the DR plan referenced from within the BC plan for system-specific recovery procedures. Many SMEs have elements of a DR plan (backup systems, restore procedures) but no formal BC plan covering the wider business response.

How often must we test our BC plan under NIS2?

CIR Annex 4.1.4 requires testing “at planned intervals and following significant incidents or significant changes.” Most implementations treat this as annual full-scale testing, quarterly functional backup restore tests, and semi-annual tabletop exercises. ENISA’s guidance recommends adding cyber-attack simulations. The core requirement is that testing is documented, lessons are incorporated, and the plan is updated after each exercise — demonstrating a continuous improvement cycle rather than a static document.

Does NIS2 require ISO 22301 certification?

No. NIS2 does not mandate ISO 22301 certification for business continuity. The regulatory obligation is to implement compliant processes and document them. ISO 22301 certification provides independent verification of your BCMS against a recognised standard, which simplifies demonstrating compliance to supervisory authorities, but it is not the only path. Organisations can satisfy NIS2 without certification by implementing and maintaining well-documented, tested BC processes that map to CIR Annex 4 requirements.

What backup retention period does NIS2 require?

The CIR does not mandate a specific retention period. CIR Annex 4.2.2 requires retention to be “aligned with business and regulatory requirements.” In practice, determine your retention periods based on: your sector’s applicable legal requirements, GDPR data minimisation obligations balanced against legal hold needs, your ability to support a regulatory investigation or forensic review, and contractual commitments to customers or partners. Document the retention decisions and the rationale — the reasoning is what auditors will examine, not just the numbers.

Sources

1. Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 (NIS2 Directive). EUR-Lex.
2. Commission Implementing Regulation (EU) 2024/2690, European Commission, 17 October 2024. EUR-Lex.
3. ENISA, Technical Implementation Guidance on Cybersecurity Risk Management Measures, Version 1.0, June 2025. ENISA.europa.eu.
4. ISO 22301:2019, Security and Resilience — Business Continuity Management Systems — Requirements. ISO.org.
5. 25 Business Continuity Statistics (2026), Invenioit. Invenioit.com.

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 or compliance professional for advice specific to your situation.