How Often Must You Test a NIS2 Business Continuity Plan? 4 CIR Annex 4 Test Duties and ENISA’s Weekly-to-Annual Benchmarks
Short answer: no EU text sets a single interval for testing a NIS2 business continuity plan. The Implementing Regulation that details Article 21(2)(c) contains four separate test duties: backup integrity checks, restore tests, business continuity and disaster recovery plan tests, and crisis management plan tests. Each uses different timing words, and none names a number. The numbers come from guidance: ENISA suggests testing continuity plans and the crisis process at least once a year, and checking backups of high-criticality data weekly. Belgium’s CyberFundamentals and Germany’s BSI-Standard 200-4 add their own figures.
So “how often?” has four answers. A calendar that treats them as one yearly event leaves at least one duty untested.
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.
Which Text Sets Your Test Clock?
The NIS2 Directive’s Article 21(2)(c) asks for “business continuity, such as backup management and disaster recovery, and crisis management”. It says nothing about testing. The test duties come from Commission Implementing Regulation (EU) 2024/2690 (the CIR), and Article 1 of the CIR applies it to only eleven types of provider. Which text you work from depends on where you sit.
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
| Your organisation | Binding text on BC testing | Where the numbers come from |
|---|---|---|
| DNS, TLD registry, cloud, data centre, CDN, MSP, MSSP, online marketplace, search engine, social network, trust service provider | CIR 2024/2690 Annex points 4.1.4, 4.2.3, 4.2.6, 4.3.4 (directly applicable) | Your own risk-based schedule. ENISA guidance is the main reference. |
| Any other essential or important entity in Belgium | Belgian NIS2 law, which transposes Art. 21(2)(c) | CyberFundamentals (CyFun), one of the two reference frameworks for conformity assessment |
| Any other essential or important entity in Germany | BSIG risk-management duties (“Aufrechterhaltung des Betriebs … und Krisenmanagement”) | BSI-Standard 200-4, which the BSI recommends for building a BCMS |
| Other member states, non-CIR sectors | National transposition of Art. 21(2)(c) | Check national guidance. Some authorities, such as the BSI, use the CIR as a reference point. |
If you are outside the CIR’s eleven categories, the four duties below are not binding on you. They are still the most detailed EU-level description of what “tested” means, and the BSI’s NIS2 business continuity page uses the Regulation in its own mapping table, while noting that it covers only part of the NIS2 population.
The Four Test Duties in CIR Annex 4, Side by Side
The four clauses sit close together in the official text of Implementing Regulation 2024/2690, but they are written differently. The table quotes the timing wording from each one.
| Duty | Annex point | Timing words (verbatim) | Event trigger | Written output the clause demands |
|---|---|---|---|---|
| Backup integrity checks | 4.2.3 | “regular integrity checks” | None stated | None stated |
| Recovery tests of backups and redundancies | 4.2.6 | “regular testing of the recovery” | None stated | “document the results of the tests and, where needed, take corrective action” |
| BC plan and DR plan tests | 4.1.4 | “at planned intervals” | “and following significant incidents or significant changes to operations or risks” | Plans must “incorporate lessons learnt from such tests” |
| Crisis management plan tests | 4.3.4 | “on a regular basis” | “or following significant incidents or significant changes to operations or risks” | None beyond review and, where appropriate, update |
Three differences are worth noticing.
- “Planned intervals” means you have to write the interval down. Point 4.1.4 assumes there is a plan with dates in it. “Regular” in 4.2.3, 4.2.6 and 4.3.4 requires a repeating pattern but doesn’t name one. Expect an auditor to ask for the schedule for all four.
- “And” versus “or”. Point 4.1.4 adds event-driven tests on top of the planned cycle. Point 4.3.4 links the two with “or”. A cautious reading treats both the same way: if a significant incident happens, retest the crisis plan as well, even when a scheduled exercise is coming up.
- Only the restore duty says “document”. Point 4.2.6 is the one clause that explicitly requires written results and corrective action. Records for the other three are still how you prove they happened.
One more clause matters. Points 4.1.4 and 4.3.4 make updates conditional on “where appropriate”, and Article 2(2) of the CIR says that if you judge an update not appropriate, you “shall in a comprehensible manner document its reasoning”. When a test finds nothing to change, write a short note saying why.
Duty 1: Backup Integrity Checks (4.2.3)
In plain terms: confirm that the backup copy matches what was backed up. This is not the same as proving you can restore it.
An integrity check catches corruption, truncation and tampering in the stored copy. It can’t show that a 4 TB database restores within your recovery time, or that anyone remembers the restore steps. That is why the CIR handles restoring in a separate point. ENISA’s June 2025 Technical Implementation Guidance suggests checksums or hashing and “automated scripts to run these checks regularly, reducing the risk of human error”. It gives no interval under 4.2.3.
Practical cadence (our recommendation, not a legal rule): run the check automatically on every backup job, so the interval is the same as your backup interval. Once the check is a script, extra runs cost almost nothing, and a corrupt copy found a month late can leave a month of data with no good backup.
Duty 2: Recovery Tests (4.2.6)
In plain terms: actually restore data and fail over redundant systems, then record what happened.
This is the only test duty for which ENISA suggests an interval shorter than a year, and the figures sit under 4.2.6, not 4.2.3. ENISA says to “tailor the frequency of the backup checks to the data criticality based on the risk assessment”. Its examples are that data with high criticality “might be checked on a weekly basis”, moderate- and low-criticality data monthly, and “significant changes should be checked immediately after the change”. These are examples, not floors, but they come from the EU cybersecurity agency and are much tighter than the quarterly restore tests often quoted in compliance articles.
Recovery has to “cover the copies, processes and knowledge to perform an effective recovery”. A restore that works only because one senior administrator runs it from memory meets the copies test and fails the knowledge test. When we read this clause next to 4.2.4(c), which requires partial redundancy of “personnel with the necessary responsibility, authority and competence”, the conclusion was clear: rotate who performs the restore, and use the runbook rather than the expert.
For evidence, ENISA lists reports “showing the execution of the plans, including evidence that recovery times were met”. So every restore record needs the recovery time you achieved, alongside the target from your business impact analysis. Our guide to NIS2 backup and recovery requirements covers the rest of point 4.2.
Duty 3: Business Continuity and Disaster Recovery Plan Tests (4.1.4)
In plain terms: test whether the plans work, at least once a year according to ENISA, and again after any significant incident or change.
ENISA’s guidance under 4.1.4 says to “test, review and, if necessary, update the business continuity and disaster recovery plans at least annually”. It lists methods you can “choose and combine”: alternative locations for staff, hot sites, digital twins, simulations and tabletop exercises. Where appropriate, it adds a disaster recovery test at an alternate processing site and failover tests of data centre infrastructure, including power. Test design should reflect change logs, past incidents and earlier results, so repeating last year’s scenario after a major migration misses the point.
The binding part is the feedback loop. The plans must “incorporate lessons learnt from such tests”. If last year’s findings still appear unchanged in this year’s plan, that is the most visible gap an auditor can find. Our business continuity audit checklist lists the evidence reviewers ask for. The disaster recovery plan guide explains what the DR half should contain.
Duty 4: Crisis Management Plan Tests (4.3.4)
In plain terms: exercise the people who make decisions, not the systems, once a year according to ENISA.
ENISA’s guidance is short: “Test the crisis management process annually”, through “an exercise or simulation”. It asks you to compare results with your recovery objectives, meaning the RTOs, RPOs and service delivery objectives from point 4.1.2(f). Its suggested evidence includes the scenarios tested, the participants and after-action reports.
The crisis plan covers who decides, who talks to the authorities, and how security is maintained during a crisis (4.3.2). A technical failover test doesn’t exercise any of that, which is why this is a separate duty from 4.1.4. Our tabletop exercise guide includes three scenarios and a scoring rubric, and the crisis management plan guide covers what the plan itself must contain.
How National Frameworks Put Numbers on the Four Clocks
Belgium and Germany have both published continuity frameworks with specific intervals, and they don’t all agree. The table compares them with ENISA.
| Duty | ENISA guidance (June 2025) | CyFun 2025, Belgium (Important / Essential) | BSI-Standard 200-4, Germany (example values) |
|---|---|---|---|
| Backup integrity and restore | Weekly for high-criticality data, monthly for moderate and low, immediately after significant change | PR.DS-11.2: verify and test “regularly”; guidance: “at least annually, or more frequently on a sample basis”, covering all types of data source | No separate backup interval in the exercise chapter; restoring resources falls under functional tests in the next row (our reading) |
| BC/DR plan tests | At least annually | ID.IM-04.1: plans “tested, validated, and improved”; reviewed “at least annually or after major changes or incidents” | Functional test at least annually for processes and resources with RTO under 24 hours; at least every 3 years for RTO under 5 days; plan walkthrough promptly after a plan is created or significantly changed |
| Crisis management tests | Annually | Covered by ID.IM-04.1: a crisis management team “trained to act during crises”, plans tested “regularly”; no fixed interval | Crisis staff exercise (Stabsübung) at least annually, including all deputies |
Three points when reading these figures:
- CyFun’s annual backup test is a minimum for the whole backup estate, while ENISA’s weekly figure applies only to your most critical data. They answer different questions, and an entity using CyFun can meet both.
- BSI 200-4 makes the exercise plan mandatory and the frequencies illustrative. Section 13.3 of BSI-Standard 200-4 states that the organisation “must” produce an annual exercise plan, which should cover at least twelve months. Table 37, which contains the RTO-based intervals, is labelled as an example. The standard’s sample metrics aim for full coverage of time-critical resources, recovery plans and business continuation plans over three years.
- The Belgian Royal Decree names CyFun or ISO/IEC 27001 as the frameworks for regular conformity assessment, which is mandatory for essential entities and voluntary for others, according to the Centre for Cybersecurity Belgium. Belgian entities can find wider context in our Belgium NIS2 guide.
Two common figures appear in none of these sources as continuity test intervals: quarterly restore tests and twice-yearly tabletop exercises. They are reasonable practitioner habits, but if you adopt them, record that they are your own risk-based choices, not regulatory intervals.
A Defensible Test Calendar
The calendar below is our recommended internal practice. It combines the strictest relevant benchmark for each duty and then scales by criticality, which is the proportionality basis in Article 21(1) of the Directive. Change the intervals to match your own business impact analysis, and record why.
| Test | Annex point | Suggested interval | Benchmark it rests on |
|---|---|---|---|
| Automated integrity check | 4.2.3 | Every backup job; failures reviewed weekly | ENISA (automate); interval is our practice |
| Sample restore, high-criticality data | 4.2.6 | Weekly | ENISA example |
| Sample restore, moderate and low criticality | 4.2.6 | Monthly | ENISA example |
| Full restore covering every data source type, including failover of redundant systems | 4.2.6 | At least annually | CyFun PR.DS-11.2 guidance |
| BC/DR functional test, RTO under 24 hours | 4.1.4 | At least annually | ENISA; BSI 200-4 example |
| BC/DR functional test, longer RTOs | 4.1.4 | Rotating, every process covered within 3 years; tabletop walkthrough every year | BSI 200-4 example; ENISA annual review |
| Crisis management exercise | 4.3.4 | Annually | ENISA; BSI 200-4 Stabsübung |
| Event-driven retest | 4.1.4, 4.3.4, 4.2.6 | After significant incidents or significant changes to operations or risks | CIR text; ENISA “immediately after the change” |
Who owns what:
| Role | What to own |
|---|---|
| CISO / IT security manager | Automating the 4.2.3 checks, the weekly and monthly 4.2.6 restores, and rotating who performs them so the “knowledge” part is also tested |
| Compliance officer | A single test register with all four duties, the trigger log for significant incidents and changes, and the Art. 2(2) notes where an update was judged not appropriate |
| Board / management body | Taking part in the annual crisis exercise, since the crisis plan assigns their roles, and approving the calendar as part of the risk-management measures |
| SME owner | Start with three items: automated integrity checks, a monthly sample restore and one yearly tabletop that walks through the BC, DR and crisis plans together. Add separate tests as the risk assessment requires. |
For the full Article 21(2)(c) framework behind these tests, see our NIS2 business continuity requirements guide.
Frequently Asked Questions
Does NIS2 require an annual business continuity test?
Not in binding EU text. The Directive sets no testing interval. The Implementing Regulation requires testing “at planned intervals” (4.1.4) and “on a regular basis” (4.3.4) without naming a number. The annual figure comes from ENISA’s non-binding guidance, and from national frameworks such as CyFun and BSI-Standard 200-4.
Is a yearly tabletop exercise enough?
Usually not for entities covered by the CIR. A tabletop exercise can test the crisis plan (4.3.4) and parts of the BC/DR plans (4.1.4). It doesn’t restore any data, so it can’t meet the recovery-testing duty in 4.2.6 or the integrity checks in 4.2.3.
How often should backups be restore-tested under NIS2?
The CIR says “regular”. ENISA gives examples of weekly checks for high-criticality data and monthly checks for moderate- and low-criticality data. Belgium’s CyFun guidance sets at least an annual test across all data source types, with more frequent sample tests.
How This Guide Was Verified
We checked the four Annex 4 clauses word for word against the official English EUR-Lex text of Implementing Regulation 2024/2690. “Tabletop” and “exercise”, in the sense of a drill, appear nowhere in it. ENISA’s guidance, the CyFun 2025 Important and Essential booklets (version 2025-10-01) and chapter 13 of BSI-Standard 200-4 were read in the original on 11 October 2026; the German translations are ours.
Sources
- Commission Implementing Regulation (EU) 2024/2690, Articles 1–2 and Annex points 4.1.2, 4.1.4, 4.2.3, 4.2.4, 4.2.6, 4.3.2 and 4.3.4 (EUR-Lex)
- Directive (EU) 2022/2555 (NIS2), Article 21 (EUR-Lex)
- NIS2 Directive, Article 21, verbatim text (nis-2-directive.com)
- ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025 (points 4.1.4, 4.2.3, 4.2.6, 4.3.4)
- Centre for Cybersecurity Belgium, CyberFundamentals Framework 2025, Important and Essential booklets, version 2025-10-01 (controls ID.IM-04.1, PR.DS-11.2, PR.DS-11.4), cyfun.eu
- Centre for Cybersecurity Belgium, “Adoption of the NIS2 Royal Decree”, 25 June 2024, updated 14 March 2025, ccb.belgium.be
- BSI, BSI-Standard 200-4 Business Continuity Management, version 1.0, 2023 (chapter 13, Tables 34, 37 and 42)
- BSI, #nis2know: BCM (Business Continuity Management) (bsi.bund.de)
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
