- NIS2 requires operational recovery that is tested, documented, and based on real behaviour change, not wishful thinking.
- Most failures are not technical. They stem from unclear roles, poor data backup design, and outdated incident reporting flows.
- This guide highlights the five most common runbook mistakes and gives you actionable steps to fix them.
- IT Managers can use it to benchmark readiness before audits or tabletop exercises.
Introduction: Runbooks Are the First Thing Auditors Ask For
Recovery runbooks look simple on paper. Under NIS2, they become legally relevant documents tied to business continuity, incident reporting, and evidence of security training.
The directive expects recovery workflows that:
- actually work under stress
- align with real infrastructure, not a fantasy architecture
- demonstrate repeatable behaviour, not heroic improvisation
- integrate tightly with data backup and recovery capabilities
Yet in almost every readiness assessment, the runbook is the weak link. The good news: most mistakes are predictable and fixable.
The 5 Most Common Mistakes
1. Treating the Runbook as a Documentation Task Instead of an Operational System
Most runbooks read like a technical bedtime story: beautifully formatted, never used, and forgotten until ransomware hits. NIS2 requires operational resilience, not PDFs gathering dust.
Why this fails:
- Roles are unclear when engineers operate under pressure.
- Critical steps depend on tribal knowledge, not defined procedure.
- No alignment with RTO/RPO, resource ownership, or escalation paths.
Fix it:
- Treat runbooks as “operational code.” Version control them. Keep them alive.
- Link each step to a real responsible role, not a vague “IT team.”
- Use short, atomic actions: one step, one outcome, one owner.
2. Incomplete Integration with Data Backup and Recovery Workflows
NIS2 expects you to prove that your recovery relies on verifiable, tested backups. Many runbooks skip over the messy middle: locating the correct backup set, validating integrity, and restoring into a clean environment.
Symptoms of this mistake:
- Backup locations or retention policies in the runbook are outdated.
- Recovery procedures assume infinite bandwidth or nonexistent replicas.
- No fallback documented if primary recovery fails.
Fix it:
- Map each workload to its backup source, recovery point objective, and restore method.
- Include commands, scripts, consoles, or tools used for recovery.
- Document both primary and secondary recovery paths.
3. Missing the NIS2 Requirements for Incident Reporting and Evidence Capture
Incident reporting under NIS2 has strict timelines (notably the 24-hour early warning). Most runbooks treat reporting as an afterthought or a “notify management” bullet. Here most are missing the NIS2 requirements for incident reporting and evidence capture as described in the NIS2 Compliance guide.
Why this breaks compliance:
- You must demonstrate when the incident was detected and how decisions were made.
- Runbook execution must create an auditable trail.
- Evidence collection must not contaminate forensics.
Fix it:
- Add a “Reporting & Evidence Capture” stage to every runbook.
- Specify who logs timestamps, which systems produce evidence, and where data is stored.
- Prewrite templates for internal and external notifications.
4. No Behaviour Change or Security Training Plan Connected to Runbook Usage
People default to habit under pressure. If the runbook contradicts real-world behaviour, the runbook loses every time.
This is where organisations skip the hard part: training the operators.
Common issues:
- Engineers do not know where the runbook lives.
- Steps require tools or access they don’t have.
- Training is theoretical instead of scenario-driven.
Fix it:
- Run quarterly exercises where staff must execute the runbook as written.
- Include soft-skills training: communication, escalation, and decision-making.
- Track recurring mistakes and update the runbook accordingly.
5. Testing Is Treated as Optional, Not Mandatory
NIS2 expects tested, validated recovery capabilities. The measuring maturity goes beyond RTO/RPO.
Most organisations test once per year, if at all, which basically means never.
What goes wrong:
- Hidden dependencies appear only in real tests.
- Cross-team gaps remain invisible until an incident.
- Backup and restore times are theoretical, not proven.
Fix it:
- Run at least two types of tests:
- Tabletop exercises simulating decision-making.
- Technical recovery tests restoring actual systems.
- Measure RTO/RPO, integrity validation, operator workload, and escalation times.
- Document results and feed them back into both the runbook and your security training plan.
Example Scenario: Healthcare SME
A mid-sized healthcare organisation rewrote its runbooks for NIS2. During testing, they discovered:
The documented backup repository had been deprecated six months earlier.
Only one engineer knew how to validate the imaging server backups.
No one knew who was responsible for sending the 24-hour NIS2 incident report.
They rewired the runbook to:
- Map systems to correct backup locations
- Add evidence-handling steps
- Add a rotating on-call reporting owner
- Introduce quarterly behaviour-focused drills
Their recovery time dropped by 35 percent, and their audit readiness score improved dramatically.
Actionable Checklist
Use this as a quick internal audit before finalising your runbooks.
NIS2 Recovery Runbook Readiness Checklist
[ ] Each runbook has clear owners for every step
[ ] Backup locations, RTO/RPO, and restore commands documented
[ ] Evidence capture and incident reporting flows included
[ ] Operators trained on the exact steps and tools
[ ] Tests performed and documented (tabletop + technical)
[ ] Runbook stored in a controlled, versioned location
[ ] Escalation paths validated against real on-call schedules
[ ] Alternative recovery scenarios defined
[ ] Runbook integrates with the broader Business Continuity Plan
[ ] Lessons learned feed into security training and behaviour change
FAQ
- Is a recovery runbook required for NIS2 compliance?
Not explicitly, but the directive requires demonstrable operational resilience, recovery capability, and incident reporting. A tested runbook is the easiest way to prove this.
- How often should we test NIS2 recovery runbooks?
At minimum annually, but quarterly testing (tabletop + technical) is recommended for high-impact systems.
- What is the link between data backup and runbook readiness?
Your runbook must reference real, validated backup data. If backups are untested or misaligned with RTO/RPO, your entire recovery posture collapses.
- Do we need to include incident reporting steps?
Yes. NIS2 includes strict timelines and traceability requirements. Your runbook should define how and when reporting actions occur.
- How does security training relate to runbook execution?
Training translates procedures into behaviour. Without it, the runbook becomes theoretical and operators revert to improvisation under stress.
Leave a Reply