NIS2 and Infrastructure: What Must Be in the Runbook

TL;DR

NIS2 accountability lands on management — but auditors test whether operators can execute within legal timelines.
Your runbook must name systems, owners, comms paths and evidence locations — not generic “activate IR plan”.
Early warning (24h) and notification (72h) require pre-agreed severity thresholds and draft templates.
Backup without tested restore is theatre; keep last restore report where legal can find it.

Regulation talk often stops at governance charts. For infrastructure and security teams, NIS2 translates into time-bound actions when something breaks: classify, contain, notify, preserve evidence, recover. If those actions live only in a PDF that legal reviewed once, the first real incident will invent a new process at 02:00 — and counsel will ask for timestamps you do not have. NIS2 does not care that your policy folder is thick. It cares whether the person on call can open a runbook, follow steps tied to real systems, and produce evidence that notifications happened within statutory windows.

We have supported essential and important entities across manufacturing, logistics and IT services through NIS2 readiness. The gap is rarely missing policies. It is missing operability: severity definitions that five people interpret five ways, backup reports stored on a share only the backup admin knows, and supplier phone numbers that reach voicemail during an outage. Runbooks fix that gap — not by adding pages, but by naming who does what on which system before adrenaline is involved.

Runbook sections that must exist on day one

Severity matrix tied to NIS2 triggers is non-negotiable. Define what constitutes a significant incident for your services: customer outage duration, data categories affected, cross-border impact, ransom demands against crown-jewel systems. Map severities to internal war-room activation, early warning draft, customer communications and regulator notification. Ambiguity here costs days. A managed services provider we advised spent the first eighteen hours of a ransomware event debating whether customer PII was “affected” because files were encrypted but not exfiltrated — while the 24-hour clock ticked.

Contact tree with backups must name deputies for CISO, DPO, legal, communications, cloud provider TAM, ISP and MSSP. Include after-hours numbers and contractual escalation clauses — not “open a ticket” as the only path. During a DDoS against a Polish e-commerce operator, the runbook’s missing secondary ISP contact added four hours to mitigation while sales leadership learned about the outage from Twitter.

Technical preserve-and-contain steps per tier turn generic IR plans into executable checklists. For crown-jewel systems document how to isolate a network segment, disable compromised credentials, snapshot logs to immutable storage and maintain chain of custody for disk images. “Disconnect from network” is insufficient if you cannot state which switch port, VLAN or security group rule applies. Operators should not improvise containment under legal observation.

Backup, restore and supplier maps

Backup and restore proof belongs in the runbook body, not an appendix nobody opens. RPO and RTO per tier, last successful restore test date, who signed it, where reports live. NIS2 emphasises resilience — untested backup is a finding and a fiction. One industrial client discovered during tabletop that their “nightly backup” of a file server had been failing silently for six weeks because a credential rotated without updating the job. The runbook now links directly to the backup console dashboard and names who checks green status daily.

Supplier and sub-processor maps document which incidents require notifying which vendor within which SLA. Cloud shared responsibility means your runbook references provider status pages, support tiers and evidence export procedures. When identity compromise spans Microsoft 365 and your on-prem AD, the runbook should already state who opens the Microsoft case, who preserves Entra sign-in logs and who correlates with on-prem DC logs — not discover that split at 03:00.

Early warning and notification mechanics

The 24-hour early warning and 72-hour notification obligations punish improvisation. Pre-draft templates with placeholders for affected services, data categories, estimated user impact and containment status. Pre-agree severity thresholds that trigger legal review — not “we will call legal if it seems bad.” Legal needs time to wordsmith; operators need time to preserve evidence. Parallel workstreams require a shared timeline document updated hourly during significant incidents.

Templates should exist in the language regulators expect and in plain language for customer comms — often different documents, same facts. Store them where on-call can access without hunting through email. A logistics firm keeps draft packs in the incident channel wiki with last-reviewed dates; legal signs quarterly that placeholders still match entity structure after acquisitions.

Tabletop beats another policy version

Run a ninety-minute exercise: ransomware on a hybrid file service, or IAM compromise with malicious mail rules. Time each decision — classify, contain, notify internal leadership, draft early warning, request backup restore. Gaps become runbook edits the same week, not after an audit finding. Tabletops also reveal whether your tooling matches your story: if the runbook says “export logs to immutable storage” but nobody has tested the export in six months, fix the tooling or fix the runbook.

Repeat tabletop scenarios quarterly with rotating roles — the CISO should not always play commander. NIS2 expects organisational capability, not heroics from one person who remembers the 2019 incident. Document lessons learned with ticket IDs; auditors and regulators increasingly ask for exercise history, not only policy existence.

Scenario: cloud-first SaaS vs hybrid manufacturing

A cloud-first SaaS vendor’s runbook emphasises tenant isolation, customer notification lists pulled from CRM, and coordinated status page updates with sub-processor notification clauses in contracts. Evidence lives in ticketing, chat exports and cloud audit logs with retention locked.

A hybrid manufacturer adds OT segments, on-prem historians and physical safety interlocks. The same NIS2 timelines apply, but containment steps reference VLANs touching PLCs and a process safety officer who must approve network isolation that could stop a line. One runbook does not fit both without tier-specific chapters — and that is correct. What fails is a single generic IR PDF pasted into both environments without customisation.

What to do next

Open your incident runbook tonight. Highlight every step that says “relevant team” or “as appropriate” and replace them with names, systems and links. Schedule a ninety-minute tabletop before your next policy review. Secure infrastructure without operable incident mechanics fails NIS2 in practice. Our Secure Public Cloud Infrastructure and audit teams align technical controls with runbooks you can execute under pressure — not binders that only satisfy procurement.

Want to discuss a project?