# NIS2 Business Continuity

> Document business continuity and crisis management measures per NIS2 Art. 21(2)(c). Covers backup management policies, disaster recovery procedures, crisis management activation and escalation, and ICT readiness for business continuity. Validates BCP completeness against NIS2 requirements and checks RTO/RPO target definitions.



Tags: NIS2, Business Continuity, Disaster Recovery, Crisis Management, BCP, GRC


## Example Prompts

- Create a NIS2-compliant business continuity plan
- Assess our BCP against NIS2 Art. 21(2)(c) requirements
- Document our disaster recovery procedures for NIS2
- Review our crisis management framework for NIS2 compliance

URL: https://rakenne.app/skills/nis2-business-continuity/index.md

Try this skill: https://rakenne.app/a/?skill=nis2-business-continuity



## 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.

<!-- /excerpt -->

## 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.



---

Back to [Skill Library](https://rakenne.app/skills/index.md)