Skip to main content
NIS2Certify
Back to overview

NIS2 Article 21(2)(c): What Backup and Business Continuity Actually Require

By NIS2Certify
nis2business-continuitybackupdisaster-recoveryarticle-21cir-2024-2690
NIS2 Article 21(2)(c): What Backup and Business Continuity Actually Require

A ransomware crew encrypts a client's production estate on a Friday night. By Monday the client wants to know two things: when will we be back, and can we prove to the regulator we did everything right? If your business continuity plan lives in a SharePoint folder nobody has opened since 2023, you already have your answer to both.

Article 21(2)(c) of NIS2 is the measure most organisations think they've handled and most auditors find they haven't. "Business continuity, such as backup management and disaster recovery, and crisis management" sounds like a box you tick with an existing DR runbook. It isn't. Commission Implementing Regulation (EU) 2024/2690 turned that one sub-clause into more than twenty specific, evidenced requirements — and from the June 2026 audit cycle onward, that regulation is the yardstick auditors reach for first.

This is what your clients actually have to produce, and where the gaps usually are.

The implementing regulation is the standard auditors will measure against

NIS2 itself is deliberately vague. It lists ten measures in Article 21(2) and leaves the detail to member states and to the Commission. For a defined set of entity types — DNS providers, TLD registries, cloud and data centre providers, managed service providers, and other digital infrastructure — the Commission filled in that detail directly with CIR 2024/2690, which applied from 18 October 2024.

For everyone else, the regulation is not legally binding. But it is the most concrete reading of Article 21 that exists, national authorities are aligning their audit checklists to it, and ENISA published technical implementation guidance built on the same structure. Treat it as the de facto benchmark. If a client meets CIR 2024/2690 on business continuity, no auditor in the EU is going to argue they fell short of Article 21(2)(c).

The regulation breaks the measure into three things that have to exist independently: a business continuity and disaster recovery plan, backup management, and crisis management. Most organisations have one of the three and assume it covers the others. It doesn't.

Article 21 — 10 NIS2 Cybersecurity Measures
Article 21
10 Cybersecurity Measures
Governance & Strategy
1Risk analysis & information security policies
6Effectiveness assessment of security measures
Incident & Continuity
2Incident handling & notification
3Business continuity & disaster recovery
Supply Chain & Systems
4Supply chain security
5Security in network & information systems development
Technical Controls
8Cryptography & encryption
10Multi-factor authentication & secure communications
People & Assets
7Cyber hygiene & training
9HR security & access control

A business continuity plan without a business impact analysis is a guess

The first requirement is a documented BC and DR plan — but the plan has to be derived from a business impact analysis, not from the IT team's intuition about what matters.

The BIA is where you identify critical services and the systems behind them, then assign each one a maximum tolerable downtime. From that you set a Recovery Time Objective (how fast you restore) and a Recovery Point Objective (how much data you can afford to lose). These two numbers drive every downstream decision: how often you back up, where you store backups, how you architect failover.

Here is the gap auditors find constantly. The client has RTO and RPO values written down — four hours, fifteen minutes, whatever — but the backup schedule and DR design don't actually deliver them. An RPO of fifteen minutes with nightly backups is not a target, it's a fiction. The regulation expects the objectives and the architecture to match, and expects you to prove the match with a test result, not an assertion.

For consultants, the BIA is also the highest-leverage piece of work you can sell. It's framework-agnostic, it feeds ISO 27001 and DORA at the same time, and almost no SME client has done one properly.

Backups have to be isolated, immutable, and proven to restore

Backup management under CIR 2024/2690 is where ransomware reality meets compliance. Three things are non-negotiable.

Backups must be separated from production. A backup that sits on the same domain, reachable with the same credentials, gets encrypted alongside everything else. The regulation expects logical and ideally physical separation.

Backups must be protected against alteration — immutability or equivalent controls, so an attacker with admin rights can't delete or overwrite recovery points. This is the single biggest architecture change most clients still need to make.

And backups must be tested by actually restoring them. A backup job that reports "success" every night tells you the write worked. It tells you nothing about whether the data restores into a working system inside your RTO. Annex 4.3 of the regulation specifically requires recovery testing with documented results and corrective actions.

The CTA here writes itself for any MSP: your clients' backup posture is the fastest part of NIS2 to assess and the easiest to demonstrably improve. Our free NIS2 quick scan gives you a defensible starting baseline for exactly this conversation.

Crisis management is a named team and a rehearsed decision chain, not a phone tree

The third pillar is the one organisations forget until they need it. Crisis management under NIS2 means a defined leadership structure with clear roles, decision-making authority, and communication procedures that function under pressure.

In practice that means a named crisis team, documented escalation thresholds, pre-drafted communication templates (including for regulators and customers), and an understanding of who can authorise what when systems are down and the usual approvers are unreachable. The regulation treats crisis communication templates as a specific evidence item — auditors will ask to see them.

This connects directly to NIS2's incident reporting clock. The crisis plan is what gets the right people in a room fast enough to hit the 24-hour early warning and 72-hour notification deadlines under Article 23. A backup that restores in four hours is worthless if nobody decided to declare an incident for the first three days.

NIS2 Incident Reporting Timeline
24h
Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
72h
Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
1mo
Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.

What "evidence" means in a 2026 audit

The shift that catches organisations off guard in this audit cycle is evidentiary. Auditors are no longer satisfied that a plan exists. They want to see it was tested, that the test found problems, and that the problems were fixed.

For every recovery test, the regulation expects a documented output: the date and who took part, the scenario used, issues found with severity ratings, corrective actions with named owners and deadlines, results measured against your stated RTO and RPO, and management sign-off. A plan with no test record is treated as a plan that doesn't work.

Build the evidence trail as you go, not the week before the audit. The organisations that struggle in June 2026 are the ones treating documentation as an afterthought rather than a byproduct of actually running the process.

NIS2 Penalty Escalation — Beyond the Fine
!
Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose
▼
Non-Monetary Penalties
1
Compliance orders with binding deadlines
2
Mandatory security audits at your expense
3
Public disclosure of violations
4
Binding instructions on specific security measures
Escalates to
▼
Operational & Personal Consequences
1
Suspension of certifications or operating licences
2
Temporary ban on management functions for individuals
3
Public naming of responsible natural persons
Trigger
Non-monetary
Operational / personal

The penalty exposure makes the case on its own. Essential entities face fines up to €10 million or 2% of global annual turnover, and a business continuity failure that turns a recoverable incident into a prolonged outage is exactly the kind of negligence regulators are signalling they'll pursue. But the stronger argument with clients is operational, not regulatory: an organisation that can prove it restores critical services inside a defined window is simply a better-run business.

Where to start with a client this quarter

Run the business impact analysis first — without it, every other decision is guesswork. Then check three things in order: are backups isolated and immutable, has a real restore test happened in the last twelve months, and does a named crisis team exist with templates ready to send. Those three checks separate the clients who are genuinely ready from the ones who have a document.

For a fast read on where any organisation stands across all ten Article 21 measures, the NIS2 quick scan turns a vague "are we compliant?" into a concrete gap list you can act on.

Article 21(2)(c) rewards the boring work: tested backups, written-down decisions, rehearsed responses. That's also the work that means a Friday-night ransomware hit is a bad weekend instead of a business-ending event.

    NIS2 Article 21(2)(c): What Backup and Business Continuity Actually Require — NIS2Certify