What goes in an incident response plan template?

An incident response plan template needs ten parts: purpose and scope, roles, severity levels, detection and reporting, response steps, communication, evidence handling, recovery, legal and regulatory duties, and review. Keep it short enough that someone can use it at 3 a.m.

Why base the plan on a standard?

NIST SP 800-61 Rev. 3 frames incident response as part of overall cybersecurity risk management, aligned with the functions of NIST CSF 2.0. Its stated aim is to help organizations prepare for incidents, reduce how many occur and how bad they are, and improve the efficiency of detection, response and recovery.

That alignment is a useful design rule: preparation and lessons learned are as much part of the plan as the response itself. CISA also publishes incident and vulnerability response playbooks for US federal agencies, which show a step by step structure you can borrow.

The template

1. Purpose and scope. One paragraph: what counts as an incident, which systems and data are covered, who the plan applies to.

2. Roles and contacts. An incident lead, a technical lead, a communications lead, a legal contact, an executive sponsor. Give each a named deputy and a phone number that works outside office hours. Include external contacts: your cloud provider, insurer, outside counsel and forensic firm if you have one.

3. Severity levels. Define three or four levels by impact, not by technology. For example, level 1 is loss of a critical service or confirmed exposure of sensitive data. State who is called at each level and how quickly.

4. Detection and reporting. Where alerts come from, how staff report something odd, and the one address or phone line that always reaches the on-call person.

5. Response steps. Short checklists for triage, containment, eradication and recovery. Keep one page per common scenario, such as stolen credentials, ransomware or a leaked secret in a repository.

6. Communication. Who tells staff, customers, partners and regulators, using what channel, and who approves the wording. Include a fallback channel in case email is down.

7. Evidence handling. What to preserve before cleaning up: logs, disk images, timelines. Record who touched what and when.

8. Recovery. How to restore from backups, how to verify systems are clean, and who signs off before services return.

9. Legal and regulatory duties. A table of notification obligations that apply to you, with deadlines. Ask counsel to maintain it, and do not guess at deadlines in the plan.

10. Review. A blameless review within a set number of days after each incident, with actions assigned and tracked.

A constructed scenario

An engineer finds a cloud access key committed to a public repository. Using the plan: severity is set to level 2 because the key had read access to a storage account. The technical lead revokes the key within minutes, the incident lead starts a timeline, and logs for that key are exported before retention rules delete them. Communications is told but no outside message is needed because the logs show no use. The review adds a pre-commit secret check to the pipeline. The plan did not stop the leak, but it made the response calm and the learning concrete.

How to check or apply this

1. Copy the ten headings into a document and fill in each in plain language. Aim for ten pages at most, with checklists at the end.
2. Print or store a copy outside your main systems.
3. Run a tabletop exercise within the first month: pick a scenario, walk through the plan, note where it fails.
4. Check every contact number by calling it.
5. Update after each incident and after any organizational change.
6. Review the plan at least once a year.

Quick check

Sources

• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks

Last reviewed: 18 October 2026.