Who this page is for
This page is for anyone creating, reviewing or revising an incident response plan - in IT, security, risk, legal and executive functions.
Purpose and tone
A plan is not a novel. It should make people effective immediately during an incident. Long, hard-to-find documents are useless in a crisis. A short core plan with detailed annexes for special cases works well.
Typical contents
A plan usually contains:
- Scope and definitions
- Severity classification
- Roles, deputies, contact details
- Escalation matrix with timelines
- Reporting paths internal and external (authorities, regulators, customers)
- Communication templates
- Initial technical actions per incident type
- Evidence and log preservation
- Recovery priorities and procedures
- Lessons learned procedure
Responsibilities
Each role needs a named owner, a deputy and out-of-hours contact details. The plan states who decides, not only who is informed.
Communication rules
Templates for internal updates, status reports, customer notes and regulatory notifications save time. Important: a consistent message line, a single source of truth for status and clear ownership for external communication.
Evidence preservation
Before systems are cleaned up, relevant artefacts should be preserved: memory images, logs, mail traces, configurations. Forensics needs intact evidence. Cleaning up too quickly can compromise later analysis or legal steps.
Recovery
A recovery section prioritises critical systems and defines order, tests before sign-off and owners. Backups should be tested regularly - otherwise availability is only an assumption.
Lessons learned
After the incident, a structured review follows - ideally without blame. Actions get owners and deadlines and feed back into the security programme.
Maintenance and exercises
A plan that sits unread in the intranet for a year does not help. At least yearly reviews, updates after each incident and yearly tabletops, ideally with executive participation, are appropriate.
Legal note
This page is orientation. For reportable incidents under NIS2, DORA or data protection law, qualified legal review is required.
Checklist
- Clear roles and named deputies
- Escalation matrix with timelines
- Out-of-hours contacts available
- Communication templates, internal and external
- Initial technical actions per incident type
- Evidence and log preservation described
- List of critical systems and recovery priorities
- Yearly exercise and review documented
Frequently asked questions
+How long should the plan be?
The core plan should be short, supported by annexes for special cases. Findability and rehearsal matter more than volume.
+Who writes the plan?
Security or IT leadership in the lead, together with legal, data protection, communications and executive management.
+Is one tabletop per year enough?
As a minimum. Critical functions should have additional, more realistic exercises.
Related topics
A security incident requires a clear process, rehearsed roles and prepared communication. Improvising during an incident wastes time and creates mistakes. This page covers the phases, responsibilities and common pitfalls.
Ransomware remains one of the most expensive cyber risks. It is typically the result of a chain of weaknesses rather than a single click. This page covers typical patterns, effective controls and an orderly first response.
A security operations centre combines people, process and technology to detect cyber incidents early, handle them in a structured way and learn from them. This page covers tasks, models and common pitfalls.
Phishing remains one of the most common entry points. Modern attacks look professional, use trusted brands and adapt quickly. Technical filters, awareness and a simple report button belong together.
Effective enterprise security combines governance with concrete technical and organisational controls. This page shows what decision makers and IT leaders should focus on first - calm, practical and clearly prioritised.
The NIS2 directive raises the cyber security bar in the EU noticeably. This page offers editorial orientation - not legal advice.
A compromised account is one of the most common incident types today. This page outlines causes, early signs and reasonable first actions.
Backups are a core defence against data loss and ransomware. This page explains the 3-2-1 rule, offline and immutable backups, restore tests and common mistakes.