NIS2 Art.21(2)(c): Business Continuity, Backup Management and Disaster Recovery for SaaS Developers (2026)

Ransomware encrypts your primary database at 03:00 on a Tuesday. Your on-call engineer wakes to alerts. The question is not whether you will lose data — the question is how much, for how long, and whether you can prove to a national competent authority (NCA) that your organisation had documented, tested, and operational procedures to handle exactly this scenario.

NIS2 Art.21(2)(c) requires essential and important entities to implement "business continuity, such as backup management and disaster recovery, and crisis management." This is the third of ten mandatory cybersecurity measures — and the one that determines survivability when the other nine fail.

NCA audits starting June 2026 will scrutinise whether entities can demonstrate tested recovery capabilities, not just policies on paper. This guide builds Art.21(2)(c) compliance from scratch for SaaS development teams.

1. Art.21(2)(c) in the Full NIS2 Context

NIS2 Art.21(2) mandates ten cybersecurity risk-management measures. Art.21(2)(c) is the resilience foundation — the capability that activates when preventive controls fail.

The Ten Mandatory Measures

Art.21(2)(c) is the last-resort capability. Art.21(2)(b) incident handling activates first. When an incident exceeds containment capacity — ransomware spreading across clusters, catastrophic infrastructure failure, sustained DDoS — Art.21(2)(c) BCM and DR take over.

The Exact Regulatory Text

Art.21(2)(c) requires:

"business continuity, such as backup management and disaster recovery, and crisis management"

The Recitals clarify: entities must ensure service continuity during and after security incidents, covering both technical recovery (backup/DR) and organisational response (crisis management).

2. Three Sub-Obligations Under Art.21(2)(c)

Art.21(2)(c) bundles three distinct but interrelated obligations:

2.1 Business Continuity Management (BCM)

BCM is the strategic layer — the documented plan ensuring critical business functions can continue at reduced capacity during a disruption. For SaaS entities, this means:

• Business Impact Analysis (BIA): Identify which services are critical, what maximum tolerable downtime (MTD) is for each, and what the financial/reputational impact of each outage is.
• Recovery Time Objective (RTO): The maximum acceptable time to restore a service after a failure. A payment processing SaaS might have RTO ≤ 4 hours; a development tool might accept RTO ≤ 24 hours.
• Recovery Point Objective (RPO): The maximum acceptable data loss measured in time. Financial data: RPO ≤ 1 hour. User content: RPO ≤ 4 hours.
• BCM Policy: A board-approved document defining scope, objectives, roles, and testing requirements. NCAs expect management body sign-off (Art.20 NIS2).

2.2 Backup Management and Disaster Recovery (DR)

DR is the technical layer — the actual capability to restore systems from backups within the stated RTO/RPO. NCA auditors look for:

• Backup policy: What is backed up, how often, where stored, how long retained, and how encrypted.
• Backup testing: Documented evidence of successful restore tests. Policy alone is insufficient.
• DR runbooks: Step-by-step instructions for recovering each critical service. Must be version-controlled and tested.
• DR environment: A tested secondary environment (hot/warm/cold standby) capable of accepting traffic within RTO.

2.3 Crisis Management

Crisis management is the governance layer — the organisational structures and communication protocols that activate during a major incident. This includes:

• Crisis Management Team (CMT): Defined roles, contact chains, decision authority.
• Crisis communication plan: Internal (employees, board) and external (customers, regulators, media) communication templates.
• Escalation thresholds: Criteria for escalating from Art.21(2)(b) incident response to full BCM/crisis activation.
• NCA notification interface: Crisis management and Art.23 reporting must be explicitly connected.

3. Business Impact Analysis — The BIA Template

A BIA is the foundation of Art.21(2)(c) compliance. Without it, your RTO/RPO targets are guesses, not risk-based decisions.

Step 1: Asset Inventory (Service Layer)

List every service that external customers or internal operations depend on:

Critical Services (Tier 1 — MTD ≤ 4h):
├── Authentication service (login, session tokens)
├── Core API (primary product functionality)
├── Payment processing integration
└── Customer data storage (primary DB)

Important Services (Tier 2 — MTD ≤ 24h):
├── Email notification service
├── Admin dashboard
├── Analytics pipeline
└── Audit logging

Non-Critical Services (Tier 3 — MTD ≤ 72h):
├── Marketing site
├── Documentation portal
└── Internal reporting

Step 2: Impact Assessment per Service

For each Tier 1 service, document:

The impact column does not need precise figures for small entities — a qualitative scale (Low/Medium/High/Critical) is acceptable, provided it is documented and reviewed annually.

Step 3: Recovery Targets

From the BIA, derive:

# bcm-targets.yml
services:
  auth_service:
    tier: 1
    rto_hours: 1
    rpo_minutes: 15
    backup_frequency: "every 15 minutes (WAL streaming)"
    dr_strategy: "hot standby in separate AZ"
    
  core_api:
    tier: 1
    rto_hours: 2
    rpo_hours: 1
    backup_frequency: "hourly snapshots"
    dr_strategy: "warm standby, < 15min failover"
    
  primary_db:
    tier: 1
    rto_hours: 4
    rpo_hours: 1
    backup_frequency: "continuous WAL + daily full backup"
    dr_strategy: "replica in separate region"

4. Backup Policy — The 3-2-1-1-0 Rule for NIS2

The classic 3-2-1 backup rule (3 copies, 2 different media, 1 offsite) is the minimum baseline. For NIS2 compliance with ransomware threat models, extend to 3-2-1-1-0:

• 3 total copies of data
• 2 different storage media/services
• 1 offsite copy (different geographic region or provider)
• 1 offline or air-gapped copy (immutable backup unreachable from production credentials)
• 0 backup restore errors at last test

Backup Encryption Requirements

Under NIS2 Art.21(2)(c) read together with Art.21(2)(h) (cryptography), backups must be encrypted:

# backup-policy.py
# Pseudocode for backup encryption compliance

BACKUP_ENCRYPTION_REQUIREMENTS = {
    "algorithm": "AES-256-GCM",
    "key_management": "separate_kms",  # Keys NOT stored alongside backup data
    "key_rotation": "annual_minimum",
    "tier_1_data": "encrypt_at_rest_AND_in_transit",
    "backup_access_control": "separate_service_account_mfa_required",
    "immutable_backup": "object_lock_worm_30_days_minimum",
}

# NCA audit evidence: encryption configuration export
# Must show: algorithm, key location, access logs, rotation schedule

Critical NIS2 requirement: Backup encryption keys must be stored separately from the backup data itself. An attacker who compromises your S3 bucket should not automatically gain access to your KMS keys.

Backup Retention Schedule

Daily backups:     Retain 30 days
Weekly backups:    Retain 90 days  
Monthly backups:   Retain 12 months
Yearly backups:    Retain 7 years (GDPR Art.5(1)(e) storage limitation applies)

For GDPR alignment: retain backups only as long as the underlying data's legal basis permits. After GDPR deletion requests, verify backup data is also removed within the retention window.

5. Disaster Recovery Runbooks

An NCA auditor at a June 2026 audit will ask for your DR runbook and evidence that you tested it in the past 12 months. A DR runbook must be:

1. Step-by-step executable — no ambiguity, runnable by the on-call engineer at 03:00 without prior context
2. Version-controlled — stored in git, not a Google Doc (wiki documents go stale)
3. Tested and timestamped — test records showing last execution date, duration, result, and any delta from RTO target

DR Runbook Structure (Minimal)

# DR-001: Primary Database Failover to Read Replica

## Trigger Conditions
- Primary DB unreachable for > 5 minutes
- Primary DB master process crashed and auto-recovery failed
- Storage corruption detected by pg_checksums

## Pre-Requisites
- Access to AWS RDS console (MFA required — Art.21(2)(j))
- Access to application config secrets (Vault / SSM Parameter Store)
- Slack #incident channel open

## Step 1: Confirm primary failure (2 minutes)
```bash
# Verify primary endpoint is unreachable
psql -h primary.db.internal -U app -c "SELECT 1;" 
# Expected: connection refused / timeout

Step 2: Promote read replica (5 minutes)

# AWS CLI: promote replica to standalone primary
aws rds promote-read-replica \
  --db-instance-identifier myapp-replica-eu-west-1 \
  --region eu-west-1

Step 3: Update application config (3 minutes)

# Update DB_HOST to new primary endpoint
aws ssm put-parameter \
  --name "/prod/DB_HOST" \
  --value "myapp-replica-eu-west-1.xxxxx.eu-west-1.rds.amazonaws.com" \
  --overwrite

Step 4: Rolling restart application pods (5 minutes)

kubectl rollout restart deployment/myapp-api -n production
kubectl rollout status deployment/myapp-api -n production

Step 5: Verify recovery

# Smoke test
curl -H "Authorization: Bearer $TEST_TOKEN" \
  https://api.myapp.io/health/db
# Expected: {"db": "ok", "latency_ms": < 50}

RTO Target: 15 minutes

Last Tested: [DATE] — Result: [PASS/FAIL] — Actual Duration: [X minutes]

---

## 6. Crisis Management Framework

When an incident escalates beyond technical recovery — ransomware affecting multiple systems, breach affecting >10,000 users, sustained 24h+ outage — crisis management activates.

### Escalation Thresholds

| Condition | Response Level | Activates |
|---|---|---|
| Single service down, RTO < 4h | Incident (P1) | Art.21(2)(b) IR only |
| Multiple Tier 1 services down | Crisis (L1) | BCM + CMT partial |
| Complete service outage > 2h | Crisis (L2) | Full BCM + CMT + NCA assessment |
| Data breach > 1,000 users | Crisis (L2) | BCM + GDPR Art.33 + NIS2 Art.23 |
| Ransomware / destructive attack | Crisis (L3) | Full BCM + NCA notification + board |

### Crisis Management Team (CMT) Roles

Crisis Management Team: ├── Crisis Commander (CEO / CTO): Overall decision authority, external comms sign-off ├── Technical Lead (CTO / Head of Engineering): Technical recovery decisions ├── Communications Lead (Head of Marketing / PR): Customer + press communication ├── Legal/Compliance (DPO / Legal): Regulatory notifications (NCA, supervisory authorities) └── Operations Lead (Head of Ops / SRE): Infrastructure recovery coordination

### Communication Templates

NCA auditors expect pre-approved templates — you should not be drafting crisis communications from scratch during an active incident.

**Customer Communication — Service Disruption (L1 Template):**

Subject: [Service Status] Investigating elevated error rates — [DATE]

We are currently investigating an issue affecting [SERVICE]. Our team is actively working on a resolution.

Current status: [Investigating / Identified / Monitoring / Resolved] Impact: [Describe scope] Next update: [TIME]

We apologise for the inconvenience. Updates at status.yourapp.io.

**Regulatory Notification Trigger (Art.23 Assessment):**
When a crisis reaches L2, the Legal/Compliance CMT member must assess within 24 hours whether the incident meets NIS2 Art.23 significant incident threshold (Early Warning → 24h, Full Notification → 72h).

---

## 7. Python NIS2BCMAssessor

Use this tool to assess your current Art.21(2)(c) compliance posture before an NCA audit:

```python
#!/usr/bin/env python3
"""
NIS2BCMAssessor — Art.21(2)(c) Business Continuity Compliance Gap Analyser
Assesses BCM, backup management, DR, and crisis management maturity.
"""

from dataclasses import dataclass, field
from typing import Optional
from datetime import datetime, timedelta

@dataclass
class BCMControl:
    control_id: str
    description: str
    article_ref: str
    implemented: bool = False
    evidence: Optional[str] = None
    last_tested: Optional[datetime] = None
    test_frequency_days: int = 365

    @property
    def test_overdue(self) -> bool:
        if not self.last_tested:
            return True
        return datetime.now() - self.last_tested > timedelta(days=self.test_frequency_days)

@dataclass
class NIS2BCMAssessor:
    org_name: str
    audit_date: datetime = field(default_factory=datetime.now)
    controls: list[BCMControl] = field(default_factory=list)
    
    def add_control(self, **kwargs):
        self.controls.append(BCMControl(**kwargs))
    
    def load_standard_controls(self):
        standard = [
            ("BCM-01", "Board-approved BCM policy with scope and objectives", "Art.21(2)(c) + Art.20", 365),
            ("BCM-02", "Business Impact Analysis (BIA) completed and reviewed", "Art.21(2)(c)", 365),
            ("BCM-03", "RTO/RPO targets defined per service tier", "Art.21(2)(c)", 365),
            ("BCM-04", "Crisis Management Team (CMT) defined with roles", "Art.21(2)(c)", 180),
            ("BCM-05", "Crisis communication templates pre-approved", "Art.21(2)(c)", 180),
            ("BCM-06", "Escalation thresholds documented (P1→L1→L2→L3)", "Art.21(2)(c)", 180),
            ("BKP-01", "Backup policy documented covering all Tier 1 data", "Art.21(2)(c)", 365),
            ("BKP-02", "3-2-1-1-0 backup rule implemented for Tier 1 services", "Art.21(2)(c)", 90),
            ("BKP-03", "Backup encryption enabled (AES-256, separate key storage)", "Art.21(2)(c+h)", 90),
            ("BKP-04", "Immutable/offline backup copy exists (object lock / air-gap)", "Art.21(2)(c)", 90),
            ("BKP-05", "Backup restore test completed and documented", "Art.21(2)(c)", 90),
            ("BKP-06", "Backup retention schedule defined (daily/weekly/monthly)", "Art.21(2)(c)", 365),
            ("BKP-07", "GDPR deletion requests propagated to backup schedule", "Art.21(2)(c) + GDPR Art.17", 90),
            ("BKP-08", "Backup access logs reviewed quarterly", "Art.21(2)(c)", 90),
            ("DR-01",  "DR runbooks written for all Tier 1 services", "Art.21(2)(c)", 365),
            ("DR-02",  "DR runbooks stored in version control (git)", "Art.21(2)(c)", 90),
            ("DR-03",  "DR runbook tested for each Tier 1 service (tabletop or live)", "Art.21(2)(c)", 180),
            ("DR-04",  "Actual RTO measured and compared to target in last test", "Art.21(2)(c)", 180),
            ("DR-05",  "DR environment provisioned and accessible (hot/warm/cold)", "Art.21(2)(c)", 90),
            ("DR-06",  "DR failover tested under simulated production load", "Art.21(2)(c)", 365),
            ("DR-07",  "Post-DR review (PDR) process documented", "Art.21(2)(c)", 365),
            ("CMT-01", "Crisis Commander and backup defined with contact details", "Art.21(2)(c)", 180),
            ("CMT-02", "Art.23 NCA notification trigger integrated into CMT process", "Art.21(2)(c) + Art.23", 180),
            ("CMT-03", "Annual BCM exercise (tabletop or full drill) completed", "Art.21(2)(c)", 365),
            ("CMT-04", "BCM lessons learned fed back into policy updates", "Art.21(2)(c)", 365),
        ]
        for control_id, desc, ref, freq in standard:
            self.add_control(
                control_id=control_id, description=desc,
                article_ref=ref, test_frequency_days=freq
            )
    
    def assess(self) -> dict:
        total = len(self.controls)
        implemented = sum(1 for c in self.controls if c.implemented)
        overdue = sum(1 for c in self.controls if c.implemented and c.test_overdue)
        not_implemented = [c for c in self.controls if not c.implemented]
        
        score = (implemented / total) * 100 if total > 0 else 0
        
        categories = {
            "BCM Policy": [c for c in not_implemented if c.control_id.startswith("BCM")],
            "Backup Management": [c for c in not_implemented if c.control_id.startswith("BKP")],
            "Disaster Recovery": [c for c in not_implemented if c.control_id.startswith("DR")],
            "Crisis Management": [c for c in not_implemented if c.control_id.startswith("CMT")],
        }
        
        return {
            "org": self.org_name,
            "assessment_date": self.audit_date.isoformat(),
            "total_controls": total,
            "implemented": implemented,
            "compliance_score_pct": round(score, 1),
            "test_overdue": overdue,
            "gaps_by_category": {k: [c.control_id for c in v] for k, v in categories.items()},
            "critical_gaps": [
                c.control_id for c in not_implemented
                if c.control_id in ["BKP-05", "DR-03", "BKP-03", "CMT-02"]  # Highest NCA scrutiny
            ],
        }
    
    def print_report(self):
        result = self.assess()
        print(f"\n{'='*60}")
        print(f"NIS2 Art.21(2)(c) BCM Assessment: {result['org']}")
        print(f"{'='*60}")
        print(f"Compliance Score: {result['compliance_score_pct']}%")
        print(f"Implemented: {result['implemented']}/{result['total_controls']}")
        print(f"Tests Overdue: {result['test_overdue']}")
        
        if result['critical_gaps']:
            print(f"\n⚠ CRITICAL GAPS (highest NCA audit risk):")
            for gap in result['critical_gaps']:
                ctrl = next(c for c in self.controls if c.control_id == gap)
                print(f"  {gap}: {ctrl.description}")
        
        for cat, gaps in result['gaps_by_category'].items():
            if gaps:
                print(f"\nGaps — {cat}: {', '.join(gaps)}")
        print()


# Example usage:
if __name__ == "__main__":
    assessor = NIS2BCMAssessor(org_name="MyApp GmbH")
    assessor.load_standard_controls()
    
    # Mark implemented controls with evidence
    for ctrl in assessor.controls:
        if ctrl.control_id in ["BCM-01", "BCM-02", "BCM-03", "BKP-01", "BKP-06"]:
            ctrl.implemented = True
            ctrl.evidence = "policy_v2.pdf"
            ctrl.last_tested = datetime(2026, 1, 15)
    
    assessor.print_report()

8. NIS2 Art.21(2)(c) — 25-Item Compliance Checklist

Use this checklist as pre-audit preparation. NCAs expect documentation, evidence, and test records for each item.

BCM Policy (6 items)

• BCM-01 Board-approved BCM policy document in place, signed within last 12 months
• BCM-02 Business Impact Analysis (BIA) completed, identifying Tier 1/2/3 services
• BCM-03 RTO and RPO targets defined for each Tier 1 service based on BIA
• BCM-04 BCM scope explicitly includes cybersecurity incidents (not only natural disasters)
• BCM-05 BCM policy links to Art.21(2)(b) IR process (handoff criteria defined)
• BCM-06 BCM policy links to Art.23 notification obligations (escalation triggers)

Backup Management (7 items)

• BKP-01 Written backup policy covering scope, frequency, retention, encryption
• BKP-02 3-2-1-1-0 rule implemented: 3 copies, 2 media, 1 offsite, 1 immutable, 0 restore errors
• BKP-03 All Tier 1 backups encrypted (AES-256+), keys stored separately from backup data
• BKP-04 Immutable backup copy exists (S3 Object Lock WORM, offline media, or equivalent)
• BKP-05 Backup restore test completed in last 90 days with timestamped evidence
• BKP-06 Backup retention schedule defined and enforced (automated lifecycle rules)
• BKP-07 Backup access control: separate service account + MFA (Art.21(2)(j) alignment)

Disaster Recovery (7 items)

• DR-01 DR runbooks written for all Tier 1 services (step-by-step, no ambiguity)
• DR-02 DR runbooks version-controlled in git with last-modified date and owner
• DR-03 Full DR test completed in last 6 months; actual RTO measured vs target
• DR-04 DR environment exists and is reachable: hot/warm/cold standby documented
• DR-05 DR test includes failover, smoke tests, and rollback validation
• DR-06 DR test results include delta analysis (target RTO vs actual) and action items
• DR-07 Post-DR review (PDR) findings fed back into runbook updates

Crisis Management (5 items)

• CMT-01 Crisis Management Team defined: roles, responsibilities, contact details, backup contacts
• CMT-02 Escalation criteria documented: when P1 incident escalates to L1/L2/L3 crisis
• CMT-03 Pre-approved communication templates: customer notice, press statement, NCA notification
• CMT-04 Annual BCM exercise completed (tabletop minimum, full live drill preferred)
• CMT-05 BCM exercise lessons learned documented and fed back into policy updates

9. Cross-Article Dependencies

Art.21(2)(c) does not operate in isolation. NCA auditors assess the system of controls:

An entity that has excellent DR runbooks but no backup encryption fails Art.21(2)(h) and weakens the Art.21(2)(c) posture simultaneously. NCAs assess the entire Art.21(2) system.

10. Implementation Timeline — 12 Weeks to June 2026 NCA Audit Readiness

11. Hosting Infrastructure and Art.21(2)(c)

Your hosting platform directly determines how achievable your Art.21(2)(c) targets are.

Key questions to ask your infrastructure provider:

• Does the platform provide built-in automated backups with configurable retention?
• Can backups be replicated to a separate geographic region?
• Does the platform support immutable backup policies (WORM / object lock)?
• What is the provider's own RTO/RPO in their SLA — and does it match your BCM targets?
• Is the provider subject to laws that could compel backup access without your knowledge (US Cloud Act)?

European SaaS entities increasingly specify EU-native infrastructure to avoid jurisdictional risk on backup data. A ransomware scenario where recovery depends on backup data held under US Cloud Act jurisdiction creates regulatory and operational complexity that a fully EU-based stack avoids.

Conclusion

NIS2 Art.21(2)(c) is simultaneously the most overlooked and most audited of the ten mandatory measures. Policy documents without tested DR runbooks, backup configs without restore evidence, and crisis plans that have never been exercised are the three fastest paths to an NCA finding in June 2026.

The 25-item checklist above maps directly to what NCA auditors inspect. The NIS2BCMAssessor Python tool gives you a gap score before the audit finds it. And the 12-week timeline leaves exactly enough runway if you start today.

The next article in the NIS2 Art.21(2) series covers Art.21(2)(f): Policies to Assess the Effectiveness of Cybersecurity Risk Management Measures — the measurement and audit obligation that closes the loop on the entire Art.21(2) framework.

See also:

• NIS2 Art.21(2)(b): Incident Handling Internal Response Framework
• NIS2 Art.21(2)(e): Secure Development Lifecycle for SaaS
• NIS2 Art.21(2)(h): Cryptography and Encryption Policy
• NIS2 Art.21(2)(j): Multi-Factor Authentication Implementation Guide
• NIS2 Art.21: All 10 Mandatory Cybersecurity Measures Overview