Incident Response Plan Template: What Each Section Must Say

An incident response plan template should give your team ten sections it can act on in the middle of an incident: purpose and scope, roles and authority, definitions and severity levels, detection and reporting, triage and escalation, containment and recovery playbooks, evidence handling, communications, legal and regulatory notification, and lessons learned. Align it to NIST SP 800-61 Revision 3, which places incident response inside the six functions of the NIST Cybersecurity Framework 2.0. Then test the finished template with one question: can the on-call responder find, in under a minute, who has authority to act, how severe the incident is, and which notification clock has started? If the answer is no, the team will improvise when it matters most.

What belongs in an incident response plan template?

A plan earns its place when it removes decisions from the worst hour of an incident. Every section should name a person, set a threshold, or start a clock. Statements of intent, such as a commitment to protect customer data, belong in the information security policy, which the plan can reference in a sentence.

• Purpose and scope: the systems, business units, subsidiaries, and third parties the plan covers.
• Roles and authority: the incident commander, the deputies, and who can approve taking production offline.
• Definitions and severity levels: what counts as an event, an incident, and a breach, and the criteria for each severity.
• Detection and reporting: how employees, the SOC, vendors, and customers report a suspected incident.
• Triage and escalation: response times by severity and who gets called at each level.
• Playbooks: containment and recovery steps for the scenarios you are most likely to face.
• Evidence handling: what to preserve, who collects it, and how custody is logged.
• Communications: internal updates, customer notices, and media holding statements.
• Legal and regulatory notification: every clock that can start and who decides whether it has.
• Lessons learned: the review after closure and how its findings change the plan.

How does NIST SP 800-61 Revision 3 change the template?

NIST SP 800-61 Revision 3, finalized in April 2025, superseded the 2012 Computer Security Incident Handling Guide. It is written as a CSF 2.0 Community Profile, so its recommendations sit inside the CSF functions instead of a separate handling manual. In NIST's incident response life cycle model, Govern, Identify, and Protect are preparation activities that support incident response without being part of it. Detect, Respond, and Recover are the response itself, and lessons from every function feed the Improvement category under Identify.

That shift has two practical effects on a template. First, the plan can stay short, because preparation work such as asset inventories, logging standards, and backup testing lives in the security program and the plan points to it. Second, each section should map to the CSF categories you already report on, so an auditor or a cyber insurer can trace a requirement to an existing control. Revision 3 also dropped step-by-step handling procedures, because NIST concluded those details change too often and vary too much to maintain in a static publication. Your playbooks have to carry that detail, and someone has to own them.

Roles, authority, and contacts

The roles section fails most often by naming a committee. Name one incident commander, two deputies, and the executive who can overrule the commander. Give the commander written authority to isolate systems, disable accounts, and engage outside responders without waiting for a meeting, because the first hours of a ransomware event decide how far it spreads.

Sample language: "The incident commander directs the response and may isolate any system, disable any account, and engage the retained incident response firm and outside counsel without further approval. The chief information officer may overrule a decision to take a revenue-producing system offline, and the decision is recorded in the incident log with its time and rationale."

Keep the contact list in an appendix that someone updates monthly, and store a copy outside your primary environment. If email and chat are compromised, the team needs an out-of-band channel, such as a separate messaging tenant or a standing phone bridge, and the plan should say which one and who holds the credentials.

Severity levels that drive decisions

Severity levels set response times and decide who gets woken up. Four levels work for most organizations, and each should be defined by criteria a responder can observe. A level defined as major business impact invites a debate during the incident. A level defined as confirmed access to regulated data or encryption of production systems ends that debate before it starts.

Sample language: "Severity 1: confirmed compromise of production systems, confirmed access to regulated or customer data, or ransomware encryption on any server. The incident commander is engaged within 15 minutes and executives are notified within one hour. Severity 2: confirmed compromise of a single endpoint or account with no evidence of lateral movement or data access. Response begins within one hour." Those response times are a BD Emerson planning range for a company with a 24/7 security operations center. Set yours from your own staffing, your managed service contracts, and your insurer's conditions.

Tie the severity table to the notification section. Any Severity 1 or 2 incident should trigger a legal review of the clocks described next, even before anyone knows whether data left the environment.

Which notification clocks should the plan name?

Regulatory and contractual clocks start at different moments, and the plan has to say which moment each one uses. Some run from discovery, one runs from a determination of materiality, and contract terms often run from the moment you become aware of an incident. Record the discovery time in the incident log as soon as anyone suspects an incident, because several deadlines are measured from it.

The SEC rule makes an Item 1.05 filing due four business days after a registrant determines that an incident is material, and it allows a delay only when the US Attorney General determines that disclosure would pose a substantial risk to national security or public safety. The HIPAA Breach Notification Rule requires notice to affected individuals without unreasonable delay and no later than 60 days after discovery, and a business associate must notify the covered entity within the same limit. Under DFARS 252.204-7012, "rapidly report" means within 72 hours of discovery of any cyber incident.

Sample language: "The general counsel decides whether an incident triggers any notification obligation and approves every filing and notice. The incident commander records the time of discovery in the incident log and briefs the general counsel within two hours of declaring any Severity 1 or 2 incident. Materiality assessments for SEC purposes follow the disclosure committee procedure."

Containment, evidence, and recovery

Write playbooks for the scenarios your threat profile makes likely: ransomware, business email compromise, compromised privileged credentials, data exfiltration, an incident at a critical vendor, and, for companies that ship software, a compromised build pipeline. Each playbook should list the first containment actions, the evidence to preserve before anything is wiped, the decisions that need the incident commander, and the criteria for declaring recovery.

Evidence handling deserves its own section because containment destroys evidence. Reimaging a laptop or rotating a cloud access key before capturing logs can erase the record your forensic team, your insurer, and possibly a court will ask for. The template should name who collects evidence, where it is stored, and how custody is recorded.

Sample language: "Before reimaging, rebuilding, or deleting any affected system, the responder preserves volatile memory where feasible, exports the relevant logs, and records each item in the evidence log with the collector, time, storage location, and hash."

Recovery criteria close the loop. Restore from backups that predate the intrusion, rotate every credential the attacker could have reached, and watch restored systems for the same actor before you declare the incident closed. Our ransomware investigation guide covers the forensic side of that decision.

Communications that hold up later

Regulators, plaintiffs, and customers may read every statement made during an incident, so the communications section should route all external statements through a single approval path. Prepare holding statements for customers, employees, and the media in advance, and add facts only after legal review. Inside the company, set an update rhythm by severity, such as every two hours for Severity 1, so executives get status without interrupting the responders.

Sample language: "No employee comments on a suspected incident outside the response team. Customer, regulator, and media statements are approved by the general counsel and the incident commander before release."

Lessons learned and keeping the plan current

NIST's Revision 3 model feeds lessons from every function into improvement, and the template should make that a scheduled step: a review within two weeks of closing any Severity 1 or 2 incident, with each finding assigned an owner and a due date. That two-week window is a BD Emerson planning range, and regulated firms often set a shorter one. Update the plan whenever a review, an exercise, or a major system change exposes a gap.

Exercises turn a template into a plan your team can run. Hold at least one tabletop exercise a year with executives and counsel in the room, using realistic scenarios like the ones in our tabletop exercise scenarios article. Each exercise should walk one notification clock from discovery to filing, because those are the steps teams rehearse least.

BD Emerson writes incident response plans and playbooks, runs tabletop exercises, and responds when an incident happens. Our cyber incident response services cover containment, forensics, and recovery, and an incident response retainer puts named responders on call with a defined response window before you need them.