Overview
NIS2 Article 21(2)(c) requires essential and important entities to implement measures for business continuity, backup management, disaster recovery, and crisis management. These measures must be proportionate to the entity’s risk exposure, size, and the likelihood and severity of potential incidents — including their societal and economic impact.
This skill produces a comprehensive Business Continuity Plan that satisfies Art. 21(2)(c) and the ICT readiness requirements from the implementing regulation (EU) 2024/2690. It validates existing documentation against every requirement area, checks that recovery objectives are measurable and aligned with backup frequency, and verifies that the crisis management framework covers team composition, escalation, communication, and exercises.
What It Covers
- Backup management policy — scope, frequency, retention, encryption, offsite/offline storage, and restoration testing aligned with the 3-2-1 rule
- Disaster recovery procedures — failover mechanisms, data restoration steps, and recovery procedures per critical service
- Crisis management framework — activation criteria, escalation matrix with severity levels, crisis team composition, and internal/external communication plans
- Recovery objective validation — RTO and RPO targets checked for measurability, with backup-frequency-to-RPO alignment analysis
- Business impact analysis — critical services identification, dependency mapping, and acceptable downtime thresholds
- Testing and exercise programme — backup restoration tests, DR drills, crisis tabletop exercises, and scheduled frequency
Example Conversation
You: We’re a regional healthcare provider with 600 employees and three hospitals. We’ve been classified as an essential entity under NIS2. We need to build a business continuity plan that satisfies Art. 21(2)(c). We have some existing documentation but it hasn’t been reviewed in two years.
Agent: I’ll help you build a NIS2-compliant BCP. Let me start by scanning what you already have in the workspace. Running
bcp_completeness_checker…Results — BCP Completeness Check:
Requirement Area Status Found Missing Backup Management Policy PARTIAL Backup scope, Backup frequency Retention policy, Encryption, Offsite/offline storage Disaster Recovery Procedures NOT COVERED — Recovery procedures, Failover mechanisms, Data restoration Crisis Management Plan PARTIAL Activation criteria, Escalation matrix Crisis team roles, Communication procedures Business Impact Analysis PARTIAL Critical services identified Dependencies mapped, Acceptable downtime Testing and Exercise Programme NOT COVERED — Backup restoration tests, DR drills, Crisis exercises, Test frequency You have significant gaps in disaster recovery and testing — both are critical for NIS2. Let me now check the recovery objectives you’ve defined for your critical services. Can you list your critical services with their current RTO and RPO targets?
You: Here are our main services:
- Electronic Health Records (EHR): RTO “as soon as possible”, RPO 1 hour, daily backups
- Laboratory Information System: RTO 4 hours, RPO “minimal data loss”, backups every 6 hours
- Pharmacy Dispensing: RTO 2 hours, RPO 30 minutes, hourly backups
Agent: Running
recovery_objective_validator…Results — RTO/RPO Analysis:
Service Check Status Detail Electronic Health Records RTO defined FAIL Vague: “as soon as possible”. Use measurable time. Electronic Health Records RPO defined PASS 1 hour Electronic Health Records Backup aligns with RPO FAIL Backup ~24h vs RPO ~1h. Electronic Health Records Restoration procedure FAIL Not documented. Laboratory Information System RTO defined PASS 4 hours Laboratory Information System RPO defined WARNING “minimal data loss” may lack measurable unit. Laboratory Information System Backup aligns with RPO WARNING Could not compare. Pharmacy Dispensing RTO defined PASS 2 hours Pharmacy Dispensing RPO defined PASS 30 minutes Pharmacy Dispensing Backup aligns with RPO PASS Backup ~1h vs RPO ~0.5h. Two critical issues for EHR: the RTO is vague and your daily backup cycle doesn’t match a 1-hour RPO — you’d lose up to 24 hours of patient records. For a healthcare essential entity, that’s a serious gap. The Lab system also needs a concrete RPO value. Let me now check your crisis management framework. Running
crisis_management_validator…Results — Crisis Management Framework:
Element Status Evidence Gaps Crisis Team Composition FOUND Crisis manager Technical lead, Communications lead, Legal representative Activation Criteria FOUND Crisis vs incident distinction Clear trigger conditions Escalation Procedures NOT FOUND — Severity levels, Escalation paths, Response timeframes Internal Communication Plan NOT FOUND — Notification tree, Communication channels, Message templates External Communication Plan NOT FOUND — Regulator notification, Media/public communication, Customer/partner notification Exercise Schedule NOT FOUND — Tabletop exercises, Simulation drills, Exercise frequency, Last exercise date Your crisis management framework is missing escalation procedures, communication plans, and — critically for NIS2 — an exercise schedule with documented results. As an essential entity you’re subject to stricter supervisory measures, so auditors will expect evidence of regular crisis exercises. Let me now draft the complete BCP starting with the backup management policy…
Sample Output Excerpt
Below is a representative excerpt from a generated NIS2 Business Continuity Plan showing the critical services table and backup policy section.
4. Critical Services and Recovery Objectives
| # | Critical Service | RTO | RPO | Backup Frequency | Dependencies | Last Restore Test |
|---|---|---|---|---|---|---|
| 1 | Electronic Health Records (EHR) | 1 hour | 15 minutes | Continuous replication + hourly snapshots | AD, Network core, SAN | 2026-02-14 |
| 2 | Laboratory Information System | 4 hours | 1 hour | Hourly incremental | EHR, Network core | 2026-01-28 |
| 3 | Pharmacy Dispensing System | 2 hours | 30 minutes | Hourly incremental | EHR, AD | 2026-03-05 |
| 4 | Medical Imaging (PACS) | 8 hours | 4 hours | Daily full + 4-hourly incremental | Network core, SAN | 2026-02-20 |
| 5 | Email and Communications | 12 hours | 24 hours | Daily full | AD, DNS | 2025-12-10 |
5. Backup Management Policy
5.1 Scope. All critical services listed in Section 4 and their supporting infrastructure components.
5.2 Strategy. Backups follow the 3-2-1 rule: three copies of data, on two different media types, with one copy stored offsite. Tier 1 services (RTO under 4 hours) additionally maintain an offline copy updated weekly.
5.3 Frequency and Retention.
| Tier | Backup Type | Frequency | Retention | Encryption |
|---|---|---|---|---|
| Tier 1 (EHR, Pharmacy) | Continuous replication | Real-time | 90 days | AES-256 at rest, TLS 1.3 in transit |
| Tier 1 (EHR, Pharmacy) | Snapshot | Hourly | 30 days | AES-256 at rest |
| Tier 2 (Lab, PACS) | Incremental | Hourly / 4-hourly | 60 days | AES-256 at rest, TLS 1.3 in transit |
| Tier 2 (Lab, PACS) | Full | Daily | 1 year | AES-256 at rest |
| Tier 3 (Email) | Full | Daily | 30 days | AES-256 at rest |
5.4 Offsite Storage. Offsite copies are transmitted to a geographically separated data centre (minimum 100 km) within the same EU jurisdiction. Transfer occurs over encrypted VPN tunnels. Physical media rotated weekly for offline copies.
5.5 Restoration Testing. Each Tier 1 service undergoes a full restoration test monthly. Tier 2 services are tested quarterly. Test results, including time-to-restore measurements, are logged and compared against the stated RTO.
Extension Tools
bcp_completeness_checker
Scans the workspace for BCP-related documentation and validates coverage against the five NIS2 Art. 21(2)(c) requirement areas. For each area, the tool checks multiple topics using keyword analysis and reports a status:
| Requirement Area | Topics Checked |
|---|---|
| Backup Management Policy | Backup scope, Backup frequency, Retention policy, Encryption, Offsite/offline storage |
| Disaster Recovery Procedures | Recovery procedures, Failover mechanisms, Data restoration |
| Crisis Management Plan | Activation criteria, Escalation matrix, Crisis team roles, Communication procedures |
| Business Impact Analysis | Critical services identified, Dependencies mapped, Acceptable downtime |
| Testing and Exercise Programme | Backup restoration tests, DR drills, Crisis exercises, Test frequency |
Each area receives a status of COVERED (all topics found), PARTIAL (some topics found), or NOT COVERED (no topics found). The summary counts how many areas fall into each category.
recovery_objective_validator
Validates recovery objective definitions for critical services. Accepts a text block with one section per service and runs six checks on each:
| Check | What It Validates |
|---|---|
| RTO defined | Recovery Time Objective uses a measurable time value — flags vague terms like “ASAP” or “best effort” |
| RPO defined | Recovery Point Objective uses a measurable unit or states “zero data loss” |
| Backup aligns with RPO | Backup frequency (in hours) is less than or equal to the RPO — catches mismatches like daily backups with a 1-hour RPO |
| Restoration procedure | A restoration or recovery procedure is referenced in the service description |
| Last test recorded | A date (YYYY-MM format or later) appears, indicating when the last restoration test occurred |
| Dependencies identified | Upstream or downstream service dependencies are mentioned |
Results are reported per service with PASS, FAIL, or WARNING status and a detail message explaining the finding.
crisis_management_validator
Scans the workspace for crisis management documentation and validates six framework elements, each with sub-topics:
| Element | Sub-topics Checked |
|---|---|
| Crisis Team Composition | Crisis manager, Technical lead, Communications lead, Legal representative |
| Activation Criteria | Crisis vs incident distinction, Clear trigger conditions |
| Escalation Procedures | Severity levels, Escalation paths, Response timeframes |
| Internal Communication Plan | Notification tree, Communication channels, Message templates |
| External Communication Plan | Regulator notification, Media/public communication, Customer/partner notification |
| Exercise Schedule | Tabletop exercises, Simulation drills, Exercise frequency, Last exercise date |
Each element is marked FOUND or NOT FOUND, with sub-topics split into evidence (found) and gaps (missing). The summary counts complete elements, elements with gaps, and elements not found.
Getting Started
Activate the NIS2 Business Continuity skill. If you have completed the NIS2 Entity Classification skill, load it — the agent uses your entity classification (essential or important) to calibrate the proportionality of measures.
Have this information ready:
- Critical services inventory — list the services and systems that must be recovered first, with their current RTO/RPO targets if defined
- Existing BCP documentation — any business continuity plans, disaster recovery runbooks, or backup policies, even if outdated
- Backup details — scope, frequency, retention periods, encryption method, and whether offsite/offline copies exist
- Crisis management contacts — who is on the crisis team, what escalation procedures exist, and when the last crisis exercise was held
- Test records — dates and results of the most recent backup restoration tests, DR drills, and tabletop exercises
The agent guides you through a 5-step workflow: gather context, assess BCP completeness, validate recovery objectives, assess the crisis management framework, and draft the final Business Continuity Plan. Each step produces actionable findings so you can address gaps before the final document is generated.