A NIS2 business continuity plan is one of the governance documents that must be approved by management bodies under the ACN baseline framework (Appendix C, reference ID.IM-04 point 1).
For implementation timing, the baseline adoption deadline for many organizational measures is October 2026, while incident notification obligations are already live as of January 2026. The continuity plan should therefore be drafted early and aligned with operational incident and recovery procedures.
Key takeaways
- The business continuity plan is not a generic policy memo: it is an operational governance artifact tied to ID.IM-04.
- Under Appendix C, this document requires formal approval by management/direction bodies.
- Continuity, disaster recovery, and crisis management should be coherent but remain separately actionable.
- Evidence quality matters: clear activation criteria, ownership, and verification records reduce audit friction.
Regulatory framing for continuity under NIS2
The ACN reading guide maps operational continuity, backup/disaster recovery, and crisis management to the baseline measure cluster including ID.IM-04. In practice, organizations need a documented continuity model that translates governance intent into executable response and service restoration steps.
A frequent failure pattern is treating continuity as a one-page declaration. The expected maturity is procedural: scope, critical services, dependencies, activation logic, and restoration priorities must be explicit and traceable.
What an approvable continuity plan should include
| Section | Why it matters for ID.IM-04 execution |
|---|---|
| Scope of critical services and processes | Defines where continuity controls apply and avoids ambiguous perimeters |
| Activation triggers and thresholds | Clarifies when the plan must be activated and by whom |
| Roles and decision authority | Prevents delays during disruption and escalation |
| Operational continuity procedures | Describes fallback workflows and minimum service operation mode |
| Dependencies and supplier assumptions | Connects continuity to external service and supply-chain risk |
| Restoration priorities and sequencing | Supports coordinated recovery and business impact reduction |
| Evidence and governance reporting | Demonstrates implementation and supports management oversight |
Practical structure from the Aegister template approach
1. Objective, scope, and normative references
Define the continuity objective, business perimeter, and baseline references used to design controls.
2. Critical process and service mapping
Link critical services to systems, data flows, and operational owners.
3. Governance roles and emergency decision model
Document who activates the plan, who approves exceptional actions, and how escalation is handled.
4. Continuity execution playbooks
Describe operational workarounds, temporary modes, and minimum acceptable service levels.
5. Dependency and supplier resilience assumptions
Include key third-party dependencies and fallback assumptions to avoid hidden single points of failure.
6. Restoration sequence and coordination with DR/crisis plans
Align continuity execution with disaster recovery and crisis management interfaces.
7. Evidence register and review cadence
Track exercises, events, lessons learned, and management reporting outputs.
Common quality gaps to avoid
- Continuity scope not aligned with actual critical services.
- Missing activation criteria, causing late response.
- No clear ownership matrix for technical and business decisions.
- DR and crisis plans referenced but not operationally connected.
- No evidence trail proving that procedures are actually usable.
20-day hardening checklist
| Week | Priority actions |
|---|---|
| Week 1 | Confirm critical services, dependencies, and approved scope |
| Week 2 | Define triggers, roles, escalation paths, and continuity playbooks |
| Week 3 | Align with DR/crisis documents and produce evidence register |
FAQ
Is the business continuity plan formally subject to board/management approval?
Yes. Appendix C includes the continuity plan among documents requiring approval by management and directive bodies (ID.IM-04 point 1).
Can continuity, disaster recovery, and crisis management be merged into one file?
Documentation architecture can be adapted to organizational context, but each required content set must remain complete, clear, and auditable.
What is the minimum practical output expected from this plan?
A usable operating model with defined triggers, accountable owners, and traceable evidence of implementation.
Conclusion and next steps
For NIS2, the continuity plan is a governance-controlled operational document, not just a compliance artifact. Teams that define activation logic, ownership, and evidence flows early are better positioned to meet regulatory expectations by October 2026 and to support live incident obligations already in force.
Related reading
- NIS2 mandatory documents master guide: what must be approved by the board and what to prepare now
- NIS2 disaster recovery plan: practical guide for an approvable ID.IM-04 document
- NIS2 crisis management plan: practical guide for an approvable ID.IM-04 document
- Aegister NIS2 Compliance Service
