NIS2 Business Continuity Audit Checklist: 31 Controls Under Art. 21(2)(c) — 6 With the Highest Failure Rate

An auditor reviewing your business continuity plan under NIS2 does not ask whether you have one. Almost everyone does by now. What they ask for is evidence: a dated log of the last time you restored a backup and measured how long it took, a signed record of a crisis-management tabletop exercise, a document showing which suppliers your recovery plan actually depends on. A plan with no evidence trail behind it is, from an audit perspective, indistinguishable from no plan at all.

Article 21(2)(c) of the NIS2 Directive compresses business continuity, backup management, disaster recovery, and crisis management into a single clause. Commission Implementing Regulation (EU) 2024/2690 expands that clause into a structured set of technical sub-requirements — and between the plan-content rules, the backup-management rules, and the crisis-management rules, they decompose into 31 discrete, individually auditable controls.

This checklist lists all 31, the evidence an auditor asks for on each one, and the six controls that fail most often in practice — based on convergent patterns from ISO 22301 and SOC 2 continuity audits, since NIS2 enforcement of Art. 21(2)(c) is still in its early cycles across most member states.

Does This Apply to You?

Article 21(2)(c) is one of ten mandatory risk-management measures under Article 21 — it applies to every essential and important entity, not just a specific sector.

Entity Type	Art. 21(2)(c) Applies?	Is CIR 2024/2690 Annex 4 Directly Binding?
Essential/important entities in Annex I & II sectors (energy, transport, health, manufacturing, etc.), 50+ staff or €10M+ turnover	Yes — directly, Art. 21(2)(c)	No — used as the audit benchmark, not a direct obligation
Digital infrastructure entities (cloud, DNS, CDN, MSP/MSSP, online marketplaces, search engines, social platforms, trust services)	Yes — directly, Art. 21(2)(c)	Yes — CIR 2024/2690 Art. 2 names these entity types explicitly
Micro and small enterprises outside the special-case criteria (sole provider, public-safety risk, nationally designated critical)	No	No

The distinction matters for how you argue your case at audit. If you are a digital infrastructure entity under CIR 2024/2690 Article 2, the Annex 4 controls below are directly enforceable against you. If you are any other essential or important entity — a manufacturer, a hospital, a logistics operator — Art. 21(2)(c) is your binding obligation, and CIR Annex 4 is the technical standard national competent authorities routinely use to judge whether your measures are “appropriate and proportionate.” Either way, the same 31 controls are what gets checked.

What Article 21(2)(c) Actually Requires

The directive text itself is one sentence. Entities must implement measures addressing “business continuity, such as backup management and disaster recovery, and crisis management.” The word “such as” signals those three elements illustrate the obligation rather than exhaust it — but in practice, CIR 2024/2690’s Annex, Point 4 (“Business continuity and crisis management”) is where those three words become 14 specific regulatory sub-clauses, organised into three clusters: a business continuity and disaster recovery plan (4.1), backup and redundancy management (4.2), and crisis management (4.3).

Germany’s BSI — the national competent authority responsible for NIS2 supervision there — frames the underlying intent plainly: business continuity management is “nicht nur um technische Lösungen, sondern um eine ganzheitliche organisatorische Resilienz” (not just about technical solutions, but about comprehensive organisational resilience) [4]. That framing explains why the 31 controls below split roughly evenly between technical requirements (backup integrity, redundancy, restoration procedures) and organisational ones (roles, communication channels, testing governance). An auditor who finds flawless backup infrastructure but no documented crisis-communication roles will still flag a gap.

The 31 Controls Auditors Check

Each row below maps to a specific CIR 2024/2690 Annex 4 sub-clause. “Evidence” is what an auditor asks to see — not what the policy says, but what proves the policy was executed.

#	Control	Evidence Auditors Ask For
Business Impact Analysis & Plan Foundation
1	Business impact analysis (BIA) completed	Dated BIA document, methodology, sign-off
2	Continuity requirements per system/process derived from BIA findings	Traceability from BIA output to stated RTO/RPO targets
3	Written BCP and DRP formally established and maintained	Current, version-controlled plan document
Plan Content (CIR 4.1.2)
4	Plan purpose, scope, and intended audience defined	Scope statement inside the plan
5	Roles and responsibilities for execution assigned	Named owners, not job titles alone
6	Internal and external contacts/communication channels documented	Current contact list, tested reachability
7	Plan activation and deactivation criteria defined	Written threshold conditions, not “management discretion”
8	Recovery sequence for operations documented	Prioritised restoration order across systems
9	Operation-specific recovery objectives (RTO/RPO) defined per system	Per-system targets, not one enterprise-wide figure
10	Required resources (backups, redundancies, facilities, staff) identified	Resource inventory referenced in the plan
11	Procedure for restoring from temporary/manual arrangements documented	Written manual-fallback steps
Plan Testing (CIR 4.1.4)
12	Plan tested, reviewed, and updated at planned intervals and after significant incidents/changes	Test log with dates and review trail
Backup Management (CIR 4.2.1–4.2.3)
13	Backup copies maintained with sufficient resources/redundancy	Backup architecture documentation
14	Backup plan specifies recovery timeframes per system	Documented recovery-time figures per backup set
15	Backup completeness/accuracy verified for configuration data	Config-backup verification records
16	Backup completeness/accuracy verified for cloud-stored data	Cloud backup verification records
17	Backup storage separated from source systems at sufficient distance	Storage-location documentation
18	Physical and logical access controls applied to backup copies	Access-control policy + access logs
19	Backup retention periods defined and enforced	Retention schedule, deletion logs
20	Backup restoration procedures documented	Step-by-step restore runbook
21	Regular integrity checks performed on backup copies	Integrity-check logs
Redundancy (CIR 4.2.4–4.2.5)
22	Partial redundancy maintained — systems, assets, personnel, communication channels	Redundancy architecture + cross-training records
23	Redundancy/backup resource levels monitored and adjusted as needs change	Capacity-review records
Recovery Testing (CIR 4.2.6)
24	Regular testing of backup/redundancy recovery under realistic conditions	Timed restoration-test record, RTO achieved vs. target
25	Test results documented and corrective actions tracked to closure	Gap log with owners and closure dates
Crisis Management (CIR 4.3.1–4.3.4)
26	Formal crisis management process established	Written crisis-management procedure
27	Crisis roles/responsibilities defined for personnel, suppliers, service providers	RACI covering internal staff and named suppliers
28	Communication channels with authorities defined for crisis situations	Named authority contacts, escalation path
29	Maintenance of network/information system security during crisis addressed	Crisis-mode security procedure
30	Process for receiving/acting on CSIRT-supplied threat/vulnerability information	Documented CSIRT-intake workflow
31	Crisis management plan tested, reviewed, updated regularly or post-incident	Crisis-exercise log

The 6 Controls With the Highest Audit-Failure Rate

Not all 31 controls fail at the same rate. Six show up disproportionately often as findings — and they share a pattern: each one is a control where the document is easy to produce but the evidence that the document reflects reality is hard to fake.

1. Test results documented and corrective actions tracked (#25). The most common failure isn’t a missing test — it’s a test record that says “no issues found” without stating what was measured against what target. A tabletop exercise that produces a one-line summary, with no scenario, no participant list, and no comparison against a declared recovery objective, does not meet the CIR 4.2.6 documentation bar. Auditors specifically look for a stated RTO, the RTO actually achieved, and a gap log — not a pass/fail checkbox.

2. Regular recovery testing under realistic conditions (#24). Closely related but distinct: many organisations run backups on schedule but have never timed an actual restore. A recovery objective that has never been tested against a live restoration is, from an audit standpoint, an assertion rather than a control. This is the single most frequently cited gap in ISO 22301 and SOC 2 continuity audits, and CIR 4.2.6’s requirement to test “in recovery conditions” is written specifically to close it.

3. Continuity requirements derived from BIA, scoped to include supplier dependencies (#2). Most BIAs map internal systems and internal recovery sequencing thoroughly, then stop at the organisation’s own boundary. They rarely document which named suppliers the recovery plan depends on, or whether those suppliers can demonstrate their own continuity capability. A BCP that assumes a critical supplier will simply be available during a regional incident — without contractual or tested evidence for that assumption — leaves the single largest blind spot auditors report.

4. Plan reviewed and updated after significant changes (#12). A BCP written two reorganisations ago, referencing systems that have since been replaced or contacts who have left the company, fails this control even if it was excellent when written. CIR 4.1.4 explicitly requires updates “following significant incidents or significant changes to operations or risks” — a trigger-based requirement, not a calendar-only one, and one that lapses quietly because no incident forces the review.

5. Crisis roles tested, not just assigned (#27, #31). A RACI chart naming who does what in a crisis is easy to write and easy to leave untested. The gap shows up as what practitioners call a “paper program”: staff can point to the plan but have never rehearsed activating it, so escalation and communication break down under real pressure. Testing this control means running the crisis-communication chain itself, not just the technical recovery.

6. CSIRT information-intake process (#30). This is the newest and least-implemented of the 31 — CIR 4.3.3 requires a defined process for receiving and acting on threat, vulnerability, and mitigation information from CSIRTs, and most organisations have no formal workflow for it at all. Because it doesn’t map to a pre-existing ISO 22301 or SOC 2 control, it’s frequently missing entirely rather than merely weak.

How CISOs and Compliance Officers Should Use This Checklist Differently

The same 31 controls, read by two different roles, point to two different first moves.

A CISO or IT security manager should start with controls #13–25 — the technical backup, redundancy, and recovery-testing cluster. These are the controls where the gap between “we have a backup policy” and “we can prove a timed restore against our stated RTO” is measured in engineering hours, not paperwork. Prioritise scheduling an actual restoration test before the next audit cycle; a test log dated last quarter closes more findings than a rewritten policy document.

A compliance officer or legal counsel should start with controls #1–3 and #26–31 — the BIA scope, plan-currency, and crisis-governance cluster. These are documentation and process gaps that don’t require new infrastructure, only a scoping exercise: does the BIA cover supplier dependencies, has the plan been reviewed since the last reorganisation, and is there a named process for CSIRT intake. Closing these is largely an exercise in producing and dating the right documents, not building new systems.

Where This Fits in Your Broader NIS2 Program

Business continuity does not sit in isolation from the rest of Article 21. The BIA that underlies these 31 controls should be built on the same risk assessment used for your broader NIS2 risk management program, and the crisis-management process should hand off cleanly into your Article 23 incident notification timeline the moment a continuity event becomes a reportable incident. If you haven’t yet built the underlying plan this checklist audits against, our step-by-step Article 21(2)(c) implementation guide covers BIA methodology, plan drafting, and testing cadence in sequence. For the exact document structure this checklist assumes — including why the BCP, DRP, and crisis management plan need to be three separate files — see our business continuity policy template guide. Manufacturers with OT-specific recovery timelines should also see our manufacturing business continuity guide, which covers SCADA and PLC recovery windows this general checklist doesn’t address.

Frequently Asked Questions

How many of the 31 controls do we need to pass to be compliant?

NIS2 does not publish a pass threshold, and Art. 21(1)’s proportionality principle means what counts as “appropriate” scales with your size and risk exposure. In practice, national competent authorities look for evidence across all three clusters (plan content, backup management, crisis management) rather than a numeric score — a business with strong backup testing but zero crisis-management documentation will still be flagged for the gap.

Is CIR 2024/2690 legally binding on our organisation if we’re not a digital infrastructure entity?

Not directly. CIR 2024/2690 Article 2 names specific entity types — cloud providers, DNS registries, CDN operators, managed service providers, online marketplaces, search engines, social platforms, and trust service providers — as the entities it formally binds. If you fall outside that list, your binding obligation is Art. 21(2)(c) itself; CIR Annex 4 functions as the technical benchmark competent authorities commonly reference when assessing whether your measures meet the “appropriate and proportionate” standard, not as a directly enforceable rule against you.

Does a cloud backup provider’s SLA satisfy the backup-testing requirement?

No. A vendor SLA describes what the provider commits to, not evidence that your organisation has verified recovery works for your specific data and configuration. CIR 4.2.6 requires the entity itself to test recovery of backup copies and document the results — that obligation cannot be fully delegated to a vendor’s uptime guarantee.

What’s the difference between this checklist and a business continuity plan template?

This checklist is the auditor’s evidence list — what gets checked and what proof is required for each control. A plan template is the document you build to generate that evidence in the first place. You need both: the template produces the plan, testing and documentation produce the evidence, and this checklist tells you which evidence an auditor will actually ask to see.

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] NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
[2] Directive (EU) 2022/2555 (NIS2) — EUR-Lex
[3] Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
[4] Business Continuity Management (BCM) under NIS-2 — Bundesamt für Sicherheit in der Informationstechnik (BSI), Germany
[5] CIR 2024/2690 Annex — Technical and Methodological Requirements — Advisera