How do you get ready for NIS2 incident handling and business continuity?

Getting ready for NIS2's incident handling and business continuity requirements comes down to three things: implementing the Article 21(2) measures (incident handling; business continuity with backups, disaster recovery, and crisis management; supply-chain security; secured emergency communications), being able to hit the Article 23 reporting cascade (early warning within 24 hours, notification within 72 hours, final report within one month), and holding evidence that all of it actually works — because Article 20 puts accountability on the management body, with fines up to €10 million or 2% of worldwide turnover for essential entities. The gap in most organizations isn't the policy documents; it's whether responders can reach the plans, the people, and the credentials when the primary environment is the thing that's down. This guide turns the requirements into a checklist you can pre-stage and drill.

The Article 21(2) measures that matter here

Article 21(2) lists ten categories of minimum measures. Four do the heavy lifting for incident and continuity readiness:

• (b) Incident handling — a defined process for detecting, analyzing, containing, and recovering from incidents, with the access and roles to execute it.
• (c) Business continuity — explicitly including backup management, disaster recovery, and crisis management. This is the clause that makes "we have backups" insufficient: crisis management — roles, decision rights, communications — is named alongside them.
• (d) Supply-chain security — assessing the security posture of direct suppliers, including any vendor your incident response itself depends on.
• (j) MFA and secured emergency communication systems — the tools you coordinate with during an incident must themselves be strongly authenticated and secured, not an unencrypted fallback group chat. (For the access-control reading of NIS2 specifically, see what NIS2 requires for incident-response access.)

The Article 23 clock

For significant incidents, in-scope entities report to their CSIRT or competent authority in stages: an early warning within 24 hours of becoming aware (flagging suspected malicious action or cross-border impact), an incident notification within 72 hours with an initial assessment of severity, impact, and indicators of compromise, intermediate reports on request, and a final report within one month covering root cause, severity, impact, and mitigations (or a progress report if the incident is still running). Member states transpose the details, so verify your authority's current forms and thresholds — but design your readiness around those planning numbers.

The 24-hour early warning is the one that breaks teams. It requires that within a single day — possibly a weekend — you detect, assess significance, find the right authority contact, and submit. None of those steps can start from zero at 2 a.m.

Copy-pasteable NIS2 readiness checklist

# NIS2 Incident & Continuity Readiness Checklist

## Crisis roles and governance
- [ ] Crisis roles named with deputies: incident lead, authority
      liaison, comms owner, business-continuity lead, management-body
      contact (Art. 20 accountability)
- [ ] "Significant incident" criteria from [authority] encoded in a
      one-page assessment worksheet; decision-maker named
- [ ] Management body has approved the measures and receives
      post-incident reports (record dates)

## Contact trees and communications
- [ ] Contact tree current and verified [date]: CSIRT/authority,
      management body, staff, key customers, suppliers
- [ ] Notification templates pre-drafted: early warning (24h),
      notification (72h), customer notice
- [ ] Emergency communication channel secured (MFA, encrypted) and
      INDEPENDENT of corporate SSO/email/chat (Art. 21(2)(j))
- [ ] Escalation rule defined: who is tried next when a contact
      doesn't acknowledge within [x minutes]

## Offline / out-of-band access
- [ ] Continuity and incident-response plans reachable with primary
      systems down; verified from a clean device [date]
- [ ] Recovery credentials (backup consoles, DNS, cloud root,
      authority portals) vaulted OUTSIDE the primary environment,
      with multi-party approval to release — no single custodian
- [ ] Backup restore tested [date]; restore-time measured against
      continuity targets

## Supply chain (Art. 21(2)(d))
- [ ] Critical suppliers listed, incl. incident-response tooling
- [ ] Each assessed for: encryption, MFA, incident-notification
      commitments, their own continuity posture
- [ ] Supplier incident-notification clauses align with YOUR 24h clock

## Drills and evidence (Art. 21(2)(f))
- [ ] Drill cadence set: tabletop [semi-annual], contact-tree /
      emergency-access drill [quarterly], full continuity exercise
      [annual]
- [ ] Each drill recorded: date, participants, scenario, findings,
      fixes — retained [x years]
- [ ] Evidence pack maintained: measure-by-measure mapping to
      Art. 21(2), drill records, incident reports, management sign-off

Mapping the checklist to Glassbreak

The checklist's recurring theme — secured, independent, evidenced — is what Glassbreak, an end-to-end-encrypted break-glass platform, is built around:

• Independent emergency channel — Glassbreak runs on two independent cloud providers (AWS US and Scaleway EU Paris) with continuous replication, outside your corporate identity and email blast radius, and its chat and calls are end-to-end encrypted — a secured emergency communication system in the Article 21(2)(j) sense rather than an insecure fallback. (An EU-only residency zone is in rollout for Enterprise customers on request; today data replicates across the EU and US regions.)
• Contact trees with acknowledgment — emergency messages fan out over voice, SMS, and email with per-recipient acknowledgment tracking and escalation tiers, so the "escalate on no-ack" rule executes itself and leaves a timestamped record for your 24-hour narrative.
• Out-of-band plans and credentials — playbooks and recovery plans live alongside the vaulted credentials they reference; secrets are client-side encrypted and released only by M-of-N quorum approval (Shamir secret sharing over an RSA-OAEP-4096 + ML-KEM-1024 hybrid), so emergency access exists without a single custodian. The failure mode this prevents is the one in when the password manager is down.
• Drills and evidence — drill scheduling runs the contact-tree and access drills on your chosen cadence, and the audit log plus exportable evidence packs give the management body and any supervisor dated proof the measures operate — the Article 21(2)(f) effectiveness question, answered with records.
• Supply chain — for your own Article 21(2)(d) file, Glassbreak publishes its posture, scope analysis, and notification commitments at /trust/nis2.

Financial entities face the stricter sibling regime — see the DORA incident reporting checklist — and the same emergency-access controls map to certification audits in the ISO 27001 break-glass procedure guide and to underwriting in cyber-insurance questionnaire prep. Plans are priced per responder with recipients free, with a 30-day trial — see pricing.

This page summarizes NIS2 obligations at a general level for readiness planning; it isn't legal advice — your member state's transposition and your competent authority's guidance govern your actual obligations.