An incident response plan defines what counts as an incident, who is accountable, how response is staffed, how information is shared, how effectiveness is measured, and how the plan itself is kept current. Write it so a tired person can follow it at 3 a.m.
Use IR-8 as the skeleton
NIST SP 800-53 IR-8 lists what a plan should contain. In paraphrase, it should:
- Give a roadmap for building incident response capability.
- Describe how the capability is structured and staffed.
- Reflect the organisation's mission, size, structure and operations.
- Define which events are reportable incidents.
- Set measures for how well response works.
- Identify the resources and leadership support needed.
- Cover how incident information is shared.
- Be reviewed and approved by defined roles on a schedule.
- Assign accountability to named roles.
Section checklist
- Purpose and scope. What systems and data the plan covers.
- Definitions. What is an event, an incident, a major incident. Give examples.
- Roles. Incident lead, technical lead, communications lead, legal contact, executive sponsor. Name backups and give contact methods that do not depend on the systems under attack.
- Severity levels. Three or four, with who is called at each.
- Reporting. How staff report suspected incidents and how fast. IR-6 asks for prompt reporting within a defined window. See internal incident reporting rules.
- Response stages. Preparation, detection and analysis, containment, eradication, recovery, and lessons learned, as in IR-4.
- Communication. Who talks to customers, regulators, law enforcement, insurers, press. Pre-approved holding statements help.
- Evidence handling. What to preserve, who may touch it.
- Third parties. Contacts for your cloud, key vendors, forensic firm, outside counsel.
- Measures. Time to detect, time to contain, time to recover, tracked per incident.
- Testing and review. See running a tabletop exercise.
- Plan maintenance. Owner, review schedule, distribution list.
Keep it usable
A forty page plan will not be read in a crisis. Put the one-page contact sheet and severity table at the front. Link to detailed playbooks for common cases such as stolen credentials, ransomware, and a leaked secret. See policy, plan and playbook.
Protect and distribute it
IR-8 also expects the plan to be given to designated response staff and protected from unauthorised disclosure and modification. Store a copy offline or somewhere that does not rely on your main identity system, because your email may be down when you need it.
Legal duties
Notification duties depend on your jurisdiction and contracts. The plan should point to who decides, not try to restate the law. Ask counsel.
Safeguard's compliance and evidence automation can help keep records of plan reviews and test results together for audits.
Quick check
How often should the plan be reviewed?
IR-8 says on a schedule you define, and also when systems or the organisation change or when testing exposes problems. Annually plus after every real incident is a common choice.
Do we need a plan if we are tiny?
Yes, a short one. A single page with roles, contacts and first steps beats improvising.
Sources
- IR-8 Incident Response Plan, NIST SP 800-53 Rev. 5
- IR-4 Incident Handling, NIST SP 800-53 Rev. 5
- IR-6 Incident Reporting, NIST SP 800-53 Rev. 5
Last reviewed: 19 October 2026.
