Free Incident Response Plan Template (ISO 27001, SOC 2 & NIS2)
When an incident hits, you need a plan you wrote *before* the chaos — not during it. This free Incident Response Plan template covers the response lifecycle, roles and notification timelines, aligned to ISO 27001 (A.5.24–5.28), SOC 2 (CC7.3–CC7.4) and the NIS2 reporting deadlines.
Every organization pursuing ISO 27001, SOC 2 or subject to NIS2. An untested, undocumented incident process is one of the riskiest gaps you can have.
Template
Incident Response Plan
ISO 27001 A.5.24–5.28 · SOC 2 CC7.3–7.4 · NIS2 Art. 23
1. Purpose & Scope
This plan defines how ✎ Company Name detects, responds to and recovers from information security incidents. It applies to all systems, staff and third parties within scope of the ISMS.
2. Roles & Reporting
All staff must report suspected incidents immediately to ✎ channel, e.g. security@company.com / your ticketing queue. The incident response team comprises ✎ e.g. Incident Manager, IT Lead, Communications. The ✎ Incident Manager coordinates the response and decides on escalation.
3. Incident Classification
Incidents are classified by severity (e.g. Low / Medium / High / Critical) based on impact to confidentiality, integrity, availability and affected parties. Severity drives response speed and escalation. A "significant incident" triggers regulatory notification obligations.
4. Response Phases
- Detect & triage: confirm and record the incident, assign severity and an owner.
- Contain: limit the impact (isolate systems, revoke access).
- Eradicate: remove the cause (malware, vulnerability, compromised credentials).
- Recover: restore services from trusted sources and verify integrity.
Evidence is preserved throughout for investigation and any legal need.
5. Communication & Notification
Internal stakeholders are kept informed per severity. Where personal data is affected, the breach is assessed against GDPR's 72-hour notification rule. Where NIS2 applies, provide an early warning within 24 hours, a notification within 72 hours, and a final report within one month. Customer notifications follow ✎ your contractual commitments.
6. Post-Incident Review
After resolution, conduct a review to capture root cause and lessons learned, and track corrective actions to closure. Update controls and this plan accordingly.
✎ Highlighted items are placeholders — replace them with your organization's details.
Generate a tailored Incident Response Plan instantly with CompliWiseAI
Skip the placeholders — get a version written for your company's industry, size, country and risk level, ready to review and export.
How to customize this template
- Set a real reporting channel everyone knows — a plan no one can find at 2am is useless.
- Name the incident response roles and keep an up-to-date contact list (including out-of-hours).
- Map your notification obligations: GDPR 72 hours, NIS2 24h/72h/1-month, plus customer contracts.
- Test the plan at least annually with a tabletop exercise and record the results.
- Feed every post-incident review back into your controls and risk register.
What an auditor looks for
- •Is there a clear reporting channel and defined response roles?
- •Are severity classification and escalation criteria defined?
- •Are breach-notification timelines documented and understood?
- •Has the plan been tested, and are post-incident actions tracked to closure?
Frequently asked questions
What should an incident response plan include?+
Scope, roles and a reporting channel, severity classification, the response phases (detect, contain, eradicate, recover), notification obligations, and a post-incident review process.
What are the NIS2 incident reporting deadlines?+
For a significant incident: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month.
How often should I test the plan?+
At least annually, typically with a tabletop exercise that walks the team through a realistic scenario. Record the outcome and any improvements.