NIS2 Business Continuity Policy Template: Why Your BCP, DRP, and Crisis Plan Can’t Be One Document

Most NIS2 guidance tells you what a business continuity plan needs to cover. Almost none of it tells you what to actually put on the page — which fields an auditor expects to see, which ones are legally mandatory versus merely smart, and whether “business continuity plan,” “disaster recovery plan,” and “crisis management plan” are three names for one document or three separate ones. That last question alone causes more first-draft audit findings than any missing control, because a compliance officer who spends three weeks writing one comprehensive continuity policy often discovers, at review, that they’ve produced something no auditor recognises as any of the three documents they were expecting.

This is a documentation-structure guide, not a repeat of the general Article 21(2)(c) requirements walkthrough (see our NIS2 business continuity requirements guide for that). Here you’ll get the exact field list Commission Implementing Regulation (CIR) 2024/2690 uses for a compliant business continuity and disaster recovery plan, which of those fields are a binding “shall” and for whom, why the three plan types belong in separate files, and a section-by-section walkthrough you can use to build or restructure your own template.

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.

What Article 21(2)(c) Actually Obliges You to Put in Writing

Article 21(2)(c) of the NIS2 Directive (EU) 2022/2555 lists “business continuity, such as backup management and disaster recovery, and crisis management” as one of ten mandatory risk-management measures for essential and important entities [1]. Article 21(1) frames the whole list as risk-based: measures must be “appropriate and proportionate,” scaled to the entity’s size, its exposure to risk, and the likelihood and severity of incidents it might face [1]. That is the legally binding core — every essential and important entity, regardless of sector, must be able to show it.

The Directive itself doesn’t specify document formats or field lists. For that level of detail, the Commission adopted CIR 2024/2690, which translates Article 21(2)(c) into a concrete Annex structure — Section 4, “Business continuity and crisis management,” split into 4.1 (the business continuity and disaster recovery plan itself), 4.2 (backup and redundancy management), and 4.3 (crisis management) [1]. Section 4.1.2 is where the actual document fields live, and it’s the part almost every generic BCP guide skips.

The CIR Annex 4.1.2 Checklist — Which BCP Fields Are Mandatory, and for Whom

Here’s the part that trips people up: CIR 2024/2690’s Annex formally binds only the entity types named in the regulation’s own Article 1 — DNS service providers, TLD name registries, cloud computing providers, data centre providers, content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers [1]. If you’re a manufacturer, a hospital network, an energy operator, or almost anything outside that digital-infrastructure list, the CIR Annex is not your direct legal obligation — Article 21(2)(c)’s broader principle is. But treating the Annex as a throwaway technicality is a mistake in the other direction: it’s the Commission’s own detailed articulation of what “appropriate and proportionate” business continuity documentation looks like, and it’s the closest thing to an official answer key any auditor working under NIS2 will have seen.

Annex point 4.1.2 states that the plan “shall include, where appropriate, the following” — eight fields, verified directly against the regulation text [1]:

CIR 4.1.2 field	Mandatory for CIR-scoped entities?	Status for everyone else
(a) Purpose, scope and audience	Yes — “shall include”	Recommended — defines what the plan actually governs
(b) Roles and responsibilities	Yes	Recommended — auditors ask “who decides” first
(c) Key contacts and communication channels (internal + external)	Yes	Recommended — including out-of-band channels
(d) Conditions for plan activation and deactivation	Yes	Recommended — the single most commonly missing field, see below
(e) Order of recovery for operations	Yes	Recommended — sequencing, not just a task list
(f) Recovery plans per operation, including recovery objectives	Yes	Recommended — this is where RTO/RPO tables live
(g) Required resources, including backups and redundancies	Yes	Recommended — cross-references your backup policy
(h) Restoring and resuming activities from temporary measures	Yes	Recommended — the “return to normal” step most plans skip

Note the qualifier “where appropriate” in the regulation’s own wording — even for CIR-scoped entities, this isn’t a rigid checklist applied identically regardless of context; it’s scaled to what’s actually relevant to the entity’s operations [1]. For everyone outside CIR’s scope, treat all eight as a recommended structure rather than a citable legal requirement — it’s the difference between “the law says so” and “this is what a document built to survive an audit looks like.”

Why Auditors Expect Three Documents, Not One

A recurring first-draft mistake: writing one document called “Business Continuity Plan” and expecting it to cover disaster recovery and crisis management too. An analysis of Italy’s national cybersecurity agency (ACN) NIS2 baseline framework makes the separation explicit, concluding that “continuity, disaster recovery, and crisis management should be coherent but remain separately actionable” [4] — coherent, meaning cross-referenced and consistent, but not merged into a single artifact.

The practical reason is scope, not bureaucracy. A Business Continuity Plan governs the whole organisation’s strategies and procedures for keeping essential functions running during and after a disruption. A Disaster Recovery Plan is narrower by design — it exists specifically to recover IT infrastructure and systems after a disaster, not the business processes around them [5]. A Crisis Management Plan is narrower still: it governs the decision-making structure — who declares a crisis, who talks to the press, who talks to the competent authority — independent of which systems are actually down.

Document	Scope	Answers the question
Business Continuity Plan	Whole organisation, critical business processes	“How do we keep operating?”
Disaster Recovery Plan	IT systems, data, infrastructure	“How do we get the systems back?”
Crisis Management Plan	Governance, communication, escalation	“Who decides, and who do we tell?”

Three documents also means three separate audit trails, three separate review cycles, and three groups of owners who can each maintain their section without waiting on the other two. Merge them, and a system-level DR update means re-issuing the entire continuity plan for sign-off — a maintenance problem that compounds every time CIR 4.1.4’s mandatory periodic review comes around [1].

Picture the merged-document version being handed to an auditor: it opens with organisation-wide continuity strategy, drifts into IT failover procedures halfway down page four, and closes with a crisis communications tree that references neither. The auditor now has to extract three answers from one document that wasn’t structured to give any of them cleanly — and “extract, don’t find” is exactly the failure mode a documented, separated set of plans is designed to avoid.

Building the Template: Section-by-Section

Mapping CIR 4.1.2’s abstract fields onto an actual document, here’s what each section should contain.

Scope and applicability statement. Name the specific business processes, systems, sites, and subsidiaries the plan covers — and just as importantly, what it doesn’t cover. A plan that says “applies to the organisation” without naming a boundary is the first thing an auditor flags, because it can’t be tested against anything concrete.

BIA summary. The plan doesn’t need to repeat your full business impact analysis — CIR 4.1.3 requires the BIA as its own exercise, feeding the plan rather than living inside it [1]. What belongs in the plan is a summary table: critical process, maximum tolerable downtime, and dependency notes. Full methodology and worksheets belong in a separate BIA document (see our guide to conducting a NIS2 business impact analysis).

RTO/RPO table. CIR’s own language is “recovery objectives” [1] — the regulation never uses the acronyms RTO or RPO. Recovery Time Objective and Recovery Point Objective are the practitioner shorthand the industry has standardised on for expressing exactly that concept, and it’s the format auditors expect to see even though the regulation doesn’t mandate the acronym itself. A usable table looks like this:

Critical process	RTO (target restore time)	RPO (max data loss window)	Recovery tier
Customer order processing	4 hours	15 minutes	Tier 1
Internal HR systems	48 hours	24 hours	Tier 2
Archived reporting systems	5 business days	7 days	Tier 3

These are illustrative figures, not benchmarks — your actual RTO/RPO values come out of your BIA, not a template default. Manufacturing and OT environments in particular need a different tiering logic entirely; see our manufacturing-specific RTO/RPO framework if SCADA or PLC recovery is in scope.

Activation and escalation criteria. This is CIR field (d), and in practice the most commonly missing one. “Activation criteria” means a named person or role with authority to declare the plan active, an explicit threshold (a system outage past X minutes, a declared significant incident under Article 23, a confirmed data centre loss), and — just as necessary — deactivation criteria stating what “back to normal” looks like. Plans that only describe activation and never deactivation leave the organisation legally “in continuity mode” indefinitely, with no documented off-ramp.

Recovery procedures. Field (f) requires recovery plans “per operation,” not one generic procedure for the whole organisation [1]. Each critical process from your BIA summary needs its own numbered sequence: who acts, what resource or backup they invoke, and what “recovered” means for that specific process. Field (e)’s recovery order — which processes come back first — belongs here too, driven directly by the BIA’s maximum-tolerable-downtime figures.

The Documentation Gaps That Fail Audits

Across the fields above, three gaps show up repeatedly in first-pass audits: a BCP with no activation criteria (the plan describes what to do but never says when it starts); a DR plan with recovery objectives but no named resource owner for each system, so “who actually restores it” is undocumented; and a crisis management plan that never states who notifies the competent authority — a gap that becomes an operational problem the moment Article 23’s 24-hour early warning clock starts running, not a documentation problem you can fix later.

A minimum documentation checklist before you call any of the three plans audit-ready (see our 31-control audit checklist for the full evidence-by-evidence version):

• Named plan owner and a named deputy for every role in the roles-and-responsibilities section
• Explicit activation AND deactivation criteria, not just one or the other
• A recovery objective (RTO/RPO) for every process listed in the BIA summary — no gaps
• A cross-reference from the DR plan to the backup policy it depends on
• A dated record of the last test, review, or exercise, per CIR 4.1.4 [1]

Who Owns Each Section

NIS2 holds management personally accountable for these controls, which makes ownership a documentation requirement in its own right, not just an operational nicety.

Section	Primary owner	Reviews / approves
BIA summary + RTO/RPO table	Business unit owners (input) / CISO or IT lead (consolidation)	Management body
Activation and escalation criteria	Crisis team lead / CISO	Management body
Recovery procedures (per process)	Process/system owner	IT lead
Communication channels (internal/external)	Crisis management lead	Legal / compliance officer
Testing and review log	Compliance officer	Management body

Testing, Review, and Keeping the Document Current

CIR 4.1.4 requires the plan to be “tested, reviewed and, where appropriate, updated at planned intervals and following significant incidents or significant changes to operations or risks” [1]. Germany’s BSI — the national competent authority for BSIG-regulated entities — points implementers toward BSI-Standard 200-4 as a structured methodology for building this into a full business continuity management system rather than a one-off document, and explicitly calls out testing (“Erproben der Notfallpläne”) as a required, recurring activity, not a launch-day checkbox [3]. BSI also frames the underlying goal as identifying an organisation’s “zeitkritische Geschäftsprozesse” — time-critical business processes — which is the same output your BIA is meant to produce, showing how tightly the testing cycle and the BIA feed back into each other rather than running as separate, disconnected exercises [3].

A dated test log, kept inside or alongside the plan, is the single easiest way to demonstrate this requirement is actually being met rather than just written down. Log the date, what was tested (a tabletop exercise, a full failover, a communications drill), who participated, and — critically — what changed in the plan afterward. A test log with no resulting edits across multiple cycles is itself a signal to an auditor that the exercise wasn’t stress-testing anything real.

Frequently Asked Questions

Do all three NIS2 entities — banking, healthcare, manufacturing — have to follow CIR 2024/2690’s exact field list?
No. CIR 2024/2690’s Annex is formally binding only on the specific digital-infrastructure and digital-service entity types named in its own Article 1 [1]. Every other essential or important entity is bound by Article 21(2)(c) directly, which is principle-based rather than field-by-field. Using the CIR structure as a template is a strong practical choice, not a separate legal obligation.

Can I combine the BCP and DRP into one document to save time?
You can, but it works against you at review time: a system-level DR change then forces a full re-approval of the combined document, and auditors specifically look for the three-way separation described above [4][5]. Cross-reference the documents instead of merging them.

Where do RTO and RPO actually come from if the regulation doesn’t define them?
From your business impact analysis. The BIA identifies maximum tolerable downtime and acceptable data loss per critical process; RTO and RPO are simply how that finding gets expressed in the recovery-objectives field CIR 4.1.2(f) requires [1]. See our BIA guide for the underlying methodology.

How often does the plan need to be tested?
CIR 4.1.4 requires testing “at planned intervals and following significant incidents or significant changes” [1] without naming a fixed cadence — annual testing is the most commonly cited practice among national guidance, including Germany’s BSI-Standard 200-4 recommendations [3], but your own risk assessment should set the interval.

What’s the fastest way to check whether our current documentation would pass?
Run it against the five-item checklist above. If any process in your BIA is missing a recovery objective, or your BCP has activation criteria but no deactivation criteria, those are the two gaps that surface most often in first-pass reviews. Our NIS2 compliance checklist covers the full Article 21 picture if you’re auditing more than just continuity.

Does the backup policy count as part of the business continuity plan, or is it separate too?
Separate, by the same logic as the BCP/DRP/crisis-plan split. CIR 4.2 addresses backup and redundancy management as its own set of requirements — architecture, geographic separation, retention periods, and recovery testing — distinct from 4.1’s continuity plan itself [1]. The continuity plan’s field (g) should reference the backup policy as a required resource, not restate its contents.

Sources

1. European Commission. Commission Implementing Regulation (EU) 2024/2690 — Annex, Section 4 (Business continuity and crisis management). EUR-Lex
2. European Parliament and Council. Directive (EU) 2022/2555 (NIS2), Article 21 — Cybersecurity risk-management measures
3. Bundesamt für Sicherheit in der Informationstechnik (BSI). NIS-2: Business Continuity Management
4. Aegister. NIS2 Business Continuity Plan — ACN Baseline Framework Analysis
5. CertiKit. The Difference Between a Business Continuity Plan and a Disaster Recovery Plan