Guide
What should an incident response plan contain?
What an incident response plan must contain: roles, escalation, communication, NIS2 and CRA reporting deadlines, evidence and lessons learned.
Summary
A useful incident response plan defines who leads and decides, when to escalate, how to classify incidents, whom to inform internally and externally, which reporting deadlines apply, what to document and how lessons learned flow back into the ISMS. It should be short enough to use under stress and tested in exercises.
When an incident happens, nobody has time to read a 60-page document. A good incident response plan is short, clear and practiced.
The building blocks
1. Scope and definitions
What counts as a security event, what as an incident, what as a crisis? Clear definitions prevent both overreaction and underreaction.
2. Roles and responsibilities
- Incident lead — coordinates the response.
- Decision-makers — who may take systems offline, involve external parties, notify authorities.
- Technical responders — internal IT and service providers.
- Communication — internal, customers, public.
- Deputies for every role.
3. Escalation and classification
A simple scheme (for example low / medium / high / critical) based on impact on confidentiality, integrity, availability and on business processes — with clear triggers for escalation to management.
4. Contacts
Internal contacts and external partners, reachable outside office hours: IT service providers, hosting and cloud providers, cyber insurer, forensics provider, legal counsel, data protection officer, authorities.
5. Reporting obligations
Translate deadlines into concrete steps and owners:
| Regime | Typical deadlines |
|---|---|
| NIS2 (significant incidents) | early warning within 24 h, notification within 72 h, final report within one month |
| Cyber Resilience Act (manufacturers) | actively exploited vulnerabilities and severe incidents: early warning within 24 h, notification within 72 h, final report afterwards |
| GDPR (personal data breaches) | notification to the supervisory authority within 72 h where required |
6. Communication templates
Prepared texts for employees, customers and authorities save critical time.
7. Documentation and evidence
A simple log: who noticed what and when, which decisions were made, which actions taken. Preserve evidence before systems are restored where possible.
8. Recovery
Criteria for restoring systems and returning to normal operation, linked to backup and continuity plans.
9. Lessons learned
After every significant incident: what happened, what worked, what did not — and which corrective actions follow.
Close the loop with the ISMS
Incident → response → documentation → lessons learned → risk reassessment → corrective action → ISMS improvement. An incident that is closed without improving anything is a missed opportunity.
Test it
Walk through the plan in a tabletop exercise at least once a year. You will find missing phone numbers, unclear decisions and outdated assumptions — better in an exercise than in an emergency.
What a plan does not replace
A plan does not replace a security operations center, an emergency response provider, forensics or legal counsel. It defines when and how you involve them.
Frequently asked questions
What are the NIS2 reporting deadlines?
For significant incidents, affected entities must submit an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report within one month. Check the exact national requirements that apply to you.
What is a tabletop exercise?
A discussion-based exercise in which the people named in the plan walk through a realistic scenario step by step. It reveals gaps in roles, contacts and decisions — without touching production systems.