The 6 NIS2 Business Continuity Mistakes Auditors Flag Most Often (CIR Annex 4)

A business continuity plan that lives as one working document — a bit of policy, a recovery sequence, a call tree, a paragraph about backups — looks complete until an auditor from your national competent authority asks one specific question: where’s the test record proving your last restore actually worked? That single question exposes the most common failure pattern in NIS2 business continuity documentation. It’s rarely the absence of a BCP. It’s a BCP that was never built to survive being pulled apart clause by clause.

Article 21(2)(c) of Directive (EU) 2022/2555 requires “business continuity, such as backup management and disaster recovery, and crisis management” [1] — a dozen words that Commission Implementing Regulation (EU) 2024/2690 expands into more than a dozen specific sub-requirements across Annex IV [2]. Most organisations meet the spirit of that obligation. Fewer meet the letter of it, because the gaps aren’t usually in intent — they’re in documentation structure, evidence, and scope.

This isn’t a scope-determination article — if you’re still confirming whether NIS2 applies to your organisation at all, start with our NIS2 scope guide. Everything below assumes Article 21(2)(c) already applies to you and focuses on making existing business continuity documentation audit-ready. Here are the six mistakes we see most often, what CIR Annex IV requires instead, and how much effort each fix takes.

Mistake #1: Treating the BCP as One Document That Covers Everything

The “business continuity plan” most organisations produce is a single file that somebody updates when they remember to. CIR Annex IV doesn’t describe one deliverable — it describes three distinct clusters of obligation, each with its own content requirements. Section 4.1 covers the business continuity and disaster recovery plan itself, including the business impact analysis (BIA) that has to justify it. Section 4.2 covers backup and redundancy management as a separate discipline. Section 4.3 covers crisis management as a distinct process with its own roles and communication requirements [2].

In practice, that maps to four artefacts, not one: a business impact analysis, a business continuity and disaster recovery plan, a backup and redundancy management plan, and a crisis management plan. CIR 2024/2690 doesn’t legally require them as separate files — but Germany’s BSI, the country’s NIS2 competent authority, takes the same structural view in its own BCM guidance, treating the impact analysis and the continuity plan it feeds as distinct stages of a maturity model rather than one document [3]. Splitting them isn’t a paperwork exercise. Each artefact has a different owner, a different review cycle, and a different piece of evidence an auditor will ask for by name — and a single combined document rarely survives a question about just one of them.

Mistake #2: Setting an RTO Nobody Has Actually Tested

CIR 4.1.3 requires the recovery objectives in your plan to come from a business impact analysis, not from a planning meeting’s gut feel [2]. In practice, that means a recovery time objective is only defensible if you can point to the BIA line item that produced it — “four hours,” written down without that evidence, is exactly the kind of number an auditor will ask you to justify on the spot.

The harder requirement sits one clause later. CIR 4.2.6 requires regular testing of backup and redundancy recovery specifically to confirm those resources “can be relied upon” under real recovery conditions [2]. Practitioner guidance on NIS2 backup compliance is blunt about the sequence this implies: identify critical processes and define acceptable recovery time objectives before designing the backup architecture around them, then prove the target with an actual restore, not a completed backup job [4]. An RTO that has never been tested against your real infrastructure isn’t a target — it’s a guess with a number attached, and CIR Annex IV asks you to show it’s more than that.

Mistake #3: A Backup Policy With No Restore Test on File

This is the mistake auditors find fastest, because it’s the easiest to check: ask for the last documented restoration test, and the file either exists or it doesn’t. CIR 4.2.3 requires regular integrity verification of backup copies; CIR 4.2.6 goes further, requiring the results of recovery testing to be documented, with corrective action recorded where a test reveals a gap [2]. A backup job that completes every night satisfies neither requirement on its own — it confirms data was copied, not that it can be restored inside the timeframe your plan promises. ISO 22301 auditors expect the same evidence trail for exercise records, which is one reason so many organisations map their NIS2 testing cadence to that standard’s cycle — see our NIS2 vs ISO 22301 comparison for how the two overlap.

The fix is less about technology than about a habit most IT teams haven’t built: automate the restore drill, and keep the output — system tested, backup age, time to restore, pass or fail against the RTO — as a dated record, not a message in a chat thread [4]. Whoever reviews the file later, whether that’s an internal compliance officer or an external auditor, needs to see a trail of tests, not a policy describing what testing should look like.

Mistake #4: A Crisis Management Plan With No Activation Trigger

CIR 4.1.2 is explicit about what a business continuity and disaster recovery plan must contain, and “activation and deactivation conditions” is one of the named items, alongside roles, contacts, recovery sequencing, and restoration procedures [2]. Most crisis management plans we see get the roles right — who’s on the crisis team, who has authority to spend — and get the trigger wrong, or skip it entirely. There’s no written threshold for when the plan actually switches on.

That gap matters at the exact moment it’s most expensive to discover it. Without a defined activation condition, the first hour of a real incident is spent debating whether this qualifies as a crisis, while the people who should already be executing the plan wait for someone senior enough to say so out loud. A significant incident that reaches this threshold will very likely also trigger the 24-hour early warning and 72-hour notification obligations under Article 23 — your crisis plan should assign responsibility for both at once, not treat them as sequential (see our Article 23 notification guide for the exact deadlines). The fix is a short, specific severity threshold tied to systems affected, duration, or customer impact, plus a named decision-maker and an equally explicit deactivation condition, so the plan knows how to end as clearly as it knows how to start.

Mistake #5: Redundancy Planning That Stops at the Server Room

CIR 4.2.4 requires redundancy across systems, assets, personnel, and communication channels [2] — four categories, not one. Most business continuity plans we review only address the first: a failover server, a secondary data centre, a cloud region. Personnel and communication redundancy rarely get the same documented treatment, even though both fail just as often as hardware does, and the budget to fix either usually needs board sign-off rather than an IT-team decision alone.

Key-person risk is the obvious gap: a plan that names one person as the sole holder of a critical skill or credential has no redundancy at all, no matter how solid the server failover is. The less obvious gap is communication-channel redundancy — if your primary crisis communication tool runs on the same infrastructure the incident just took down, the crisis management plan from Mistake #4 has no way to reach the people it names. A continuity plan that only maps IT redundancy has covered one of the four categories CIR 4.2.4 actually requires.

Mistake #6: A Continuity Scope That Assumes Your Suppliers Never Fail

The business impact analysis behind CIR 4.1.3 is scoped to “severe disruptions to business operations” [2] — not to internal system failures specifically. A continuity plan that only models incidents your organisation causes to itself, a server crash, a ransomware infection, and never models a critical supplier going down, leaves half the BIA’s actual scope untested.

This is where business continuity and Article 21(2)(d) supply chain security overlap in practice, even though they’re written as separate obligations. If your organisation depends on a single cloud provider, a single logistics partner, or a single managed-service vendor for a process your BIA marked as critical, that dependency belongs in your continuity plan’s scope, with its own recovery assumption, not a silent one. Vendor concentration risk of this kind is also a question the board should be asked directly, since it’s a strategic exposure, not just an operational one. Our supply chain security guide covers how to classify those dependencies; the point for business continuity specifically is that “critical supplier fails” has to be one of the scenarios your plan is built to answer, not an edge case nobody wrote down.

Who Owns Each Fix

These six mistakes don’t all belong to the same desk. Mistakes #2 and #5 — RTO evidence and redundancy scope — sit with the CISO or IT lead, since they’re technical testing and architecture gaps. Mistake #3, the test-record trail, sits with the compliance officer, whose job is proving the technical work happened, not doing it. Mistakes #4 and #6 — activation authority and vendor concentration risk — need board-level sign-off, because both involve a call only someone with organisational authority can make before an incident, not during one.

Quick Diagnostic: Which of the Six Are You Missing?

Use this table as a gap check against your current documentation before an auditor runs the same exercise for you.

Mistake	What CIR Annex IV Requires Instead	Fix Effort
One BCP document covering everything	Four artefacts: BIA (4.1.3), BC/DR plan (4.1), backup & redundancy plan (4.2), crisis management plan (4.3)	Medium — mostly reorganising existing content
RTO with no test evidence	RTO derived from BIA and confirmed by recovery testing (4.1.3, 4.2.6)	Medium — requires one real restore test
Backup policy, no test records	Documented restore test results plus corrective action (4.2.3, 4.2.6)	Low — a logging habit, not new technology
Crisis plan with no activation trigger	Explicit activation/deactivation conditions (4.1.2)	Low — one paragraph, one named owner
Redundancy limited to IT systems	Redundancy across systems, assets, personnel, and communications (4.2.4)	Medium — needs a key-person and comms-channel review
BC scope ignores supplier failure	BIA scoped broadly to “severe disruptions to business operations” (4.1.3)	High — requires supplier dependency mapping

Frequently Asked Questions

Does CIR Annex IV require the BIA, BC/DR plan, backup plan, and crisis plan to be physically separate files?

No. CIR 2024/2690 doesn’t mandate file boundaries, only that the required content — the BIA, the BC/DR plan, the backup and redundancy plan, and the crisis management plan — all exists and can be reviewed [2]. Splitting them into separate documents is a practical recommendation, not a legal requirement. But combining everything into one file makes each piece harder to update, test, and hand to an auditor individually, which is why reviews tend to treat them as if they were separate regardless.

How often does CIR 2024/2690 require backup and BCP testing?

The regulation requires “regular” testing and review without specifying an exact frequency, leaving the interval to be justified by your own risk assessment [2]. In practice, a defensible cadence combines a tabletop discussion at least twice a year, a functional restore test at least quarterly, and a full-scale exercise annually.

Who decides when to activate the crisis management plan?

CIR Annex IV requires the plan to name this explicitly [2]. It should be a specific person or role, not “the crisis team” collectively, with the authority to declare activation against a documented severity threshold, and equally clear authority to declare it over.

Does business continuity planning under NIS2 overlap with Article 23 incident notification?

Yes. A significant incident severe enough to trigger your business continuity plan will very likely also trigger the 24-hour early warning and 72-hour notification obligations under Article 23. Your crisis management plan should assign responsibility for both processes at once.

Is a small or medium-sized entity held to the same six requirements?

The proportionality principle in Article 21(1) lets smaller entities scale the size and formality of their documentation, but it doesn’t remove any of the six underlying requirements [1][2]. A smaller organisation’s BIA can be two pages instead of twenty, but it still has to exist, and its RTO still has to be tested.

For the full requirements behind Article 21(2)(c), see our NIS2 business continuity requirements guide. If you want a full evidence-per-control audit checklist rather than a diagnostic of the six biggest gaps, see our 31-control NIS2 business continuity audit checklist. If your risk assessment process feeds these BIA inputs, our NIS2 risk assessment guide covers that foundation, and our NIS2 compliance checklist covers how business continuity fits into the broader Article 21 obligation set.

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

[1] Article 21, Cybersecurity risk-management measures — Directive (EU) 2022/2555, nis2resources.eu
[2] Commission Implementing Regulation (EU) 2024/2690, Annex IV — EUR-Lex
[3] #nis2know: Business Continuity Management — Bundesamt für Sicherheit in der Informationstechnik (BSI), Germany’s NIS2 competent authority
[4] NIS2 Compliance Requirements — N2WS