Incident response plan template: the six phases that matter

An incident response plan tells people what to do at 3am when something has gone badly wrong. Its value is measured in decisions that do not have to be improvised - who declares an incident, who can take production offline, who calls the regulator, and who speaks to customers.

Define severity before you need it

Severity drives everything else, so define it concretely:

• SEV1 - Critical: confirmed breach of sensitive data, ransomware, or a critical service down. Immediate executive involvement, 24/7 response.
• SEV2 - High: suspected compromise, significant degradation, or a control failure with material exposure. Response within hours.
• SEV3 - Medium: contained issue with limited impact and a known fix.
• SEV4 - Low: minor issue handled through normal support.

Include worked examples. Ambiguity at declaration time is what causes the damaging delay.

Roles

• Incident commander - runs the response and owns decisions. Not necessarily the most technical person.
• Technical lead - investigation and remediation.
• Communications lead - internal updates, customer messaging, public statements.
• Legal and privacy - regulatory obligations, privilege, contractual notice.
• Executive sponsor - authorises spend, downtime and disclosure.
• Scribe - maintains the timeline. Underrated and essential, because the timeline is your evidence.

Name deputies for every role. Incidents do not wait for people to return from leave.

The six phases

1. Preparation - tooling, logging, contact lists, retainers with forensic and legal support, and exercises.
2. Detection and analysis - how incidents are detected, triaged and confirmed; how severity is assigned.
3. Containment - short-term (isolate the host) and long-term (rebuild clean). Decide in advance whether preserving forensic evidence outweighs immediate containment.
4. Eradication - remove the cause: close the vulnerability, revoke the credentials, remove persistence.
5. Recovery - restore service, validate integrity, and monitor closely for recurrence.
6. Lessons learned - a blameless review within two weeks, producing tracked actions.

The notification clocks

Put these in the plan itself, with the decision-maker named next to each:

• GDPR - notify the supervisory authority within 72 hours of becoming aware of a notifiable personal data breach; notify individuals where risk is high.
• NIS2 - early warning within 24 hours, notification within 72 hours, final report within one month.
• DORA - staged reporting for major ICT incidents.
• Sector regulators - SAMA, NCA and others set their own expectations.
• Contractual - customer contracts frequently demand notice within 24 to 48 hours, sometimes faster than the law.

A 24-hour clock cannot be met if the plan does not say who decides. Pre-authorise the decision.

What auditors ask for

• The approved plan, with a version and review date.
• The incident register for the audit period - including how minor incidents were handled.
• Sample incident records showing detection time, actions, resolution and lessons learned.
• Evidence of an exercise if you had no real incidents. "Nothing happened" is not evidence that the process works.
• Proof that lessons-learned actions were completed.

Run at least one tabletop exercise a year, and record what went badly. An exercise that exposed a gap and drove a fix is far stronger evidence than one that reported everything was fine.

Key takeaways

• Define severity with worked examples so declaration is not a debate.
• Name roles and deputies, including a scribe to own the timeline.
• Put regulatory clocks and the named decision-maker in the plan.
• If you had no incidents, an exercise is your evidence.