Incident Response Plan Template Mapped to NIST SP 800-61r3

An incident response plan template is a fill-in document that settles four things before anything goes wrong: who has authority to act, what turns an alert into a declared incident, who must be told and by when, and what each phase has to produce before the next one starts. The one below is Markdown you can paste into a wiki.

It follows NIST SP 800-61 Revision 3, the version in force since April 2025, and it is written for the people who actually run it: the analyst who declares the incident at 02:40, the incident lead who takes it from there, and whoever has to phone the regulator. Several of the top results for this search hand you the template only after a download form, and the NIST-labelled one in the top five is dated 2022, three years before the current revision. This one is on the page, and every section maps to a named NIST outcome.

What the plan has to answer

The plan is the document an incident lead opens to find out what they are allowed to do. NIST SP 800-61r3 lists the elements most incident response policies share: a statement of management commitment, purpose and scope, definitions of events and incidents, roles and authorities "such as which roles have the authority to confiscate, disconnect, or shut down technology assets", guidelines for prioritising and estimating severity, and performance measures. The plan turns that policy into operations. NIST's outcome ID.IM-04 calls incident response plans "the roadmap for implementing the incident response capability" and recommends synchronising them with business continuity plans, because an incident is usually also a continuity event.

Under pressure, that becomes seven questions. A usable plan answers each one in a place the incident lead can find in under a minute:

1. Is this an incident? Declaration criteria, and who is allowed to declare.
2. How bad is it? Severity levels with criteria, not adjectives.
3. Who is in charge? A named incident lead and a backup, with the authority they hold.
4. What may I do without asking? Pre-approved containment actions, and the ones that need sign-off.
5. Who has to be told, and by when? Internal cadence and external deadlines, with owners.
6. What do we keep? Evidence handling and the incident log.
7. When is it over? Recovery criteria, closure criteria and the review that follows.

If your current document cannot answer the fourth question, start there. It is the one that decides whether a tier-2 analyst isolates a host at 3 a.m. or spends 40 minutes trying to reach someone who can say yes.

The incident response plan template

Copy the block, replace every field in angle brackets, and delete what does not apply. The values in brackets are examples from a mid-sized organisation, not recommendations. Keep the section numbers: the checklists further down refer to them.

# Incident Response Plan: <Organisation>
 
## 0. Document control
| Field            | Value                                                   |
|------------------|---------------------------------------------------------|
| Plan owner       | <one named person, not a team>                          |
| Approved by      | <executive sponsor>, <YYYY-MM-DD>                       |
| Version          | <x.y>                                                   |
| Last exercised   | <YYYY-MM-DD>, <tabletop or technical>, <scenario>       |
| Next review      | <YYYY-MM-DD>, or earlier on any trigger in section 12   |
| Offline copies   | <printed binder location>; <copy outside corporate SSO> |
 
## 1. Purpose and scope
This plan defines how <Organisation> detects, declares, manages and
recovers from cybersecurity incidents.
- In scope: <on-prem networks, cloud tenants, SaaS, OT, subsidiaries>
- Out of scope: <IT outages with no security cause, physical safety>
- Related: incident response policy, business continuity plan, disaster
  recovery plan, playbook library at <link>
 
## 2. Definitions and declaration
- Event: any observable occurrence involving our technology assets.
- Incident: an occurrence that actually or imminently jeopardises the
  integrity, confidentiality or availability of information or systems,
  or violates law or security policy.
- Declare an incident when ANY of these is confirmed or strongly suspected:
  - <malicious code executed on a server or privileged workstation>
  - <unauthorised use of an administrator or service account>
  - <personal or regulated data accessed, copied or exfiltrated>
  - <encryption, destruction or a ransom note observed>
  - <a supplier, CERT or law enforcement reports a compromise of ours>
- Who may declare: <SOC tier 2 and above, incident lead, CISO>
- Declaration = an entry in the incident log (Appendix B) with UTC time.
 
## 3. Roles, responsibilities and authority
| Role                  | Primary | Backup      | Decides                                      |
|-----------------------|---------|-------------|----------------------------------------------|
| Executive sponsor     | <name>  | <name>      | Business shutdown, ransom, public statements |
| Incident lead         | <name>  | <name>      | Severity, task assignment, outside help      |
| SOC / handlers        | <rota>  | <MSSP/MDR>  | Triage, scoping, pre-approved containment    |
| IT and cloud ops      | <name>  | <name>      | How isolation, rebuilds and restores are run |
| Legal / privacy (DPO) | <name>  | <counsel>   | Notifications, privilege, law enforcement    |
| Communications        | <name>  | <name>      | Wording and timing of every external message |
| HR                    | <name>  | <name>      | Insider cases, staff communications          |
| Asset owners          | <CMDB>  | <CMDB>      | Restore priority, accepted residual risk     |
| Scribe                | <name>  | <name>      | Keeps the incident log, nothing else         |
 
Pre-approved (no sign-off needed, log the action and time):
- Network-isolate one workstation or server through EDR
- Disable a user account confirmed as compromised
- Block an IP, domain, URL or hash at the perimeter, proxy and EDR
Needs incident lead approval:
- Isolating a domain controller, hypervisor or backup server
- Resetting privileged or service accounts
- Taking a customer-facing service offline
Needs executive sponsor approval:
- <shutting down a business unit or site; contacting the attacker>
 
## 4. Severity levels
| Level | Criteria (any one)                                   | Lead engaged | Leadership updates |
|-------|------------------------------------------------------|--------------|--------------------|
| SEV-1 | <critical service down; ransomware spreading;        | <15 min>     | <every 2 h>        |
|       |  regulated data confirmed exfiltrated>               |              |                    |
| SEV-2 | <privileged account or server compromised, no spread>| <1 h>        | <every 4 h>        |
| SEV-3 | <one standard endpoint or account, contained>        | <same day>   | <daily>            |
| SEV-4 | <policy violation, no evidence of compromise>        | <not needed> | <weekly report>    |
Severity is set by the incident lead, re-checked at every update, and
can go down as well as up. Factors: asset criticality, functional impact,
data impact, stage of the attack, attacker characterisation, recoverability.
 
## 5. Escalation and elevation
- Escalation (more people or time): incident lead calls <IR retainer>
  when <no containment within 4 h; more than 10 hosts; tier-0 involved>.
- Elevation (more seniority): SEV-1 and SEV-2 go to the executive sponsor
  immediately; any possible notification duty goes to legal immediately.
 
## 6. Communications
### 6.1 Internal
- War room: <bridge link>, <channel>
- Out-of-band fallback: <phone bridge or messaging group outside
  corporate SSO>. Switch at declaration if mail, chat or identity may be
  compromised.
- Status update format: severity, what we know, what we did, what is
  next, decisions needed, time of next update.
### 6.2 External notification register (legal confirms which apply)
| Obligation   | Clock starts at            | Deadline         | Owner | Draft     |
|--------------|----------------------------|------------------|-------|-----------|
| <regulation> | <event that starts it>     | <hours or days>  | <who> | <link>    |
### 6.3 Third parties
- IR retainer: <firm>, <24/7 number>, <contract ID>
- Cyber insurer: <policy number>, <claim line>; vendor approval needed? <y/n>
- MSSP or MDR: <contact>; may act without asking: <list>
- Cloud and SaaS providers: <support route>, <account IDs>
- Law enforcement and national CERT: <contacts>
 
## 7. Response procedures
- Detect: triage, validation and declaration per section 2
- Respond: playbook per incident type at <link>; containment per section 3
- Recover: section 9
- Improve: section 10, plus lessons logged during the incident
 
## 8. Evidence handling
- Collect from most to least volatile (memory before disk).
- Hash every artifact (SHA-256) at acquisition; record who, when, from where.
- Store at <restricted location>; retention <period>; legal hold via <name>.
- The incident log is evidence too: restricted access, no edits after the fact.
 
## 9. Recovery and closure
- Start recovery when: <no attacker activity for 72 h; root cause known;
  eradication verified on all affected hosts>
- Restore order: <identity and DNS, then backups, then line-of-business apps>
- Check backups for indicators of compromise and integrity before use.
- Close the incident when: <criteria met>, owners have confirmed normal
  operation, and the after-action report is filed.
 
## 10. Post-incident review
- Within <10 business days> of closure for SEV-1 and SEV-2.
- Output: after-action report; one owner and one due date per improvement.
 
## 11. Metrics
- Detection to declaration; declaration to containment; containment to
  recovery; notification deadlines met (yes/no); actions closed on time.
 
## 12. Testing and maintenance
- Tabletop exercise <twice a year>; technical exercise <once a year>.
- Review on: a major incident, re-organisation, change of incident lead or
  sponsor, new regulation, SIEM or EDR migration, new cloud provider.
 
## Appendix A: Contact sheet (printed copy in the binder)
## Appendix B: Incident log
| Time (UTC) | Who | Action, decision or finding | Evidence ref |
## Appendix C: Handoff brief (see the example below)

Two fields in that template do most of the work. The Decides column in section 3 turns a contact list into a chain of authority. The Clock starts at column in section 6.2 forces legal and the SOC to agree, before any incident, on which logged event starts each deadline.

How the template maps to NIST SP 800-61r3

Revision 3 dropped the circular four-phase diagram that most templates still draw. In its own words, that model fit a time when "incident response and recovery was usually completed within a day or two". Today, NIST notes, recovery "often takes weeks or months", and lessons learned "should often be shared as soon as they are identified, not delayed until after recovery concludes". So r3 maps incident response onto the six CSF 2.0 Functions. Govern, Identify and Protect are preparation. Detect, Respond and Recover are the response. Improvement (ID.IM) feeds lessons back from every Function, at any point in the incident.

The table maps each section of the template to the CSF 2.0 outcomes r3 attaches to it, so you can show an auditor where each one lives:

If your auditor works from the old phases, r3's Table 1 gives the crosswalk: Preparation maps to Govern, Identify and Protect; Detection and Analysis to Detect; Containment, Eradication and Recovery to Respond and Recover; Post-Incident Activity to the Improvement Category. The SANS incident handler's handbook uses six steps (preparation, identification, containment, eradication, recovery, lessons learned). All three describe the same work, so pick one vocabulary for the plan and keep it consistent across the playbooks it links to.

Roles: who decides what

NIST's list of incident response roles goes well beyond the SOC: leadership, incident handlers, technology professionals, legal, public affairs and media relations, human resources, physical security and facilities, and asset owners, plus third parties under contract. Handlers can be on staff, on contract through an MSSP, or on call from a provider. r3 also notes that a service provider "may detect malicious activity sooner than individual organizations would", which is why the template has an MSSP row with its own list of actions it may take without asking.

Four gaps to check for in the roles section:

• The incident lead with no backup. Incidents start on Friday nights and last weeks. A single name means the plan stops working the first time that person sleeps.
• Legal brought in after the clock started. Several deadlines run from awareness, and legal decides what awareness means for your organisation. Call them at declaration for anything that may touch personal or regulated data, not at the end of the day.
• Communications without a draft. The first external message is usually written under the worst pressure of the whole incident. Pre-approve holding statements for ransomware, data theft and service outage.
• No scribe. The person running the response cannot also keep the log. A dedicated scribe produces the timeline that every later deadline, report and lawsuit depends on.

Notification clocks: the start time is the trap

Each notification deadline starts on a different event, and that event has to exist as a timestamp in your log. These are four common obligations. Legal decides which apply to you; the plan records the trigger, the deadline and the owner for each.

The failure mode is a log that records "incident declared at 14:36" and nothing else. Three months later, when a regulator asks when you became aware of the personal data breach, the honest answer may be a different time: the moment an analyst confirmed that the staged archive held customer records, for example. If nobody logged that moment, nobody can prove the 72 hours were met. Add one log entry type to Appendix B, clock event, and write one every time a fact that could start a deadline is confirmed.

The checklist for each phase

The template says what the organisation does. These checklists say what happens, in order, once an incident is declared. They follow r3's Functions, and each item names the template section it relies on.

Detect: validate and declare

• Read the raw alert, not just the rule name, and confirm a true positive through alert triage.
• Identify the affected asset and its business function in the CMDB. A finance laptop and a domain controller are not the same incident.
• Check whether the activity is still running: live process, authenticated session, upload in flight.
• Pivot on the indicators (source IP, account, hash, parent process) across SIEM, EDR and firewall to see how far it reaches.
• Apply the declaration criteria in section 2. If one is met, declare and log the UTC time.
• Name the incident lead and the scribe. Open the war room. Switch to out-of-band if mail, chat or identity may be affected.
• Set an initial severity from section 4. Expect to change it.

Respond: contain, analyse, eradicate, communicate

• Choose the containment tempo. Active encryption or exfiltration: isolate now. A single suspicious sign-in with no follow-on: scope first, stage the account disable.
• Contain with the least destructive action that stops the harm. For an endpoint that is network isolation through EDR, not shutdown. Isolation keeps memory and running state for collection. The EDR, antivirus and XDR comparison covers which tool can do it in your stack.
• Do not power off, reboot or clean the host, and do not log in to it with a privileged account. Each destroys evidence or hands credentials to the attacker.
• Do not reset one compromised credential in isolation. Stage a coordinated reset once the scope is known, or the attacker moves to the footholds you have not found.
• Collect evidence before anything destructive, in order of volatility (section 8).
• Open the matching playbook for the incident type, for example ransomware activity, and run its queries.
• Log a clock event whenever a fact that could start a deadline is confirmed. Tell legal at the same time.
• Escalate per section 5 if containment has not held or the scope keeps growing.
• Send status updates on the cadence for the current severity, in the section 6.1 format.
• Eradicate: remove persistence, disable breached accounts, patch the entry point on every affected host, not only the first one found.

Recover: restore and verify

• Apply the recovery start criteria in section 9. Starting a restore while the attacker still holds credentials restores their access too.
• Check backups and golden images for indicators of compromise and corruption before using them.
• Restore in the agreed order, starting with identity and DNS.
• Have asset owners confirm normal operation, and keep watching restored systems for a defined period.
• Declare the end of recovery against the criteria and record it in the log.

Improve: learn while it is fresh

• Log lessons as they come up during the incident, not only at the end.
• Hold the post-incident review within the window in section 10, with everyone who took part, including third parties.
• Write the after-action report: what happened, what was done, what worked, what did not.
• Turn each lesson into an owned, dated change to the plan, a playbook, a detection or a control. Lessons without an owner never get done.
• Update the "last exercised" field if the incident tested the plan, and note the sections that failed.

Evidence handling in practice

The governing rule comes from RFC 3227: collect "from the volatile to the less volatile". Its example order runs from registers and cache, through routing table, ARP cache, process table, kernel statistics and memory, then temporary file systems, disk, remote logging and monitoring data, physical configuration and network topology, and finally archival media. In practice that means a memory image before anything that changes the host's state, and network isolation rather than a power-off when you have to cut the attacker's channel. More on the discipline behind it is in the digital forensics glossary entry.

NIST does not demand formal chain of custody every time. RS.AN-07 notes that formal chain-of-custody procedures "might not be performed for every incident that occurs (e.g., most malware incidents will not result in prosecution)", but that collected data is still evidence. So hash everything at acquisition and record the same fields every time:

# Hash collected artifacts at acquisition time (Linux/macOS)
sha256sum memory.raw triage-collection.zip > evidence_hashes.txt
 
# Windows PowerShell equivalent
Get-FileHash memory.raw, triage-collection.zip -Algorithm SHA256 |
  Out-File evidence_hashes.txt

Artifact:    Memory image (WKSTN-4471)
Acquired by: <name> (Tier 2)
Acquired at: <YYYY-MM-DD HH:MM> UTC
Source:      WKSTN-4471 (10.40.12.18), EDR memory acquisition
SHA-256:     <hash recorded at acquisition>
Stored at:   evidence-share/<incident-id>/ (access-restricted)

A filled-in example: incident log and handoff brief

Simulated example generated by SOCSimulator Research. A SEV-2 incident as it looks in Appendix B, followed by the handoff brief that tier 1 passes to the incident lead. Hostnames and accounts are invented; the IP address comes from the 203.0.113.0/24 documentation range.

INCIDENT LOG  INC-2026-0142  (times UTC)
 
14:08  SOC-T1 (J. Okafor)  Alert: encoded PowerShell on WKSTN-4471, parent winword.exe
14:14  SOC-T1              Triage: true positive, macro-borne. Same C2 IP seen on WKSTN-4471 only
14:16  SOC-T2 (M. Brandt)  DECLARED. Section 2 criterion 1 (malicious code executed). SEV-3
14:17  SOC-T2              Incident lead: R. Silva. Scribe: K. Duarte. War room opened
14:29  SOC-T2              Memory image acquired, SHA-256 recorded (EV-01)
14:32  SOC-T2              WKSTN-4471 network-isolated via EDR, host left powered on (pre-approved)
14:40  R. Silva            Account corp\j.reyes active on 2 other hosts since 14:00. SEV-2
14:41  R. Silva            Elevated to executive sponsor. Legal informed
15:05  SOC-T2              CLOCK EVENT: staged archive on WKSTN-4471 contains customer records.
                           Possible personal data breach. Legal (A. Moreau) notified 15:06
15:20  R. Silva            Coordinated reset of j.reyes approved, scheduled 15:45 with IT ops

HANDOFF BRIEF  INC-2026-0142
Status:   Contained (host isolated), under investigation. SEV-2
From:     J. Okafor (Tier 1)  To: R. Silva (incident lead)
 
VERDICT
Confirmed intrusion on WKSTN-4471 (Finance). Credential theft suspected;
lateral movement not ruled out.
 
EVIDENCE PRESERVED
- Memory image EV-01 (hash in evidence_hashes.txt)
- EDR process tree export EV-02
- Firewall flows for 203.0.113.45, last 24 h, EV-03
 
INDICATORS (defanged)
- C2: 203.0.113[.]45
- Account: corp\j.reyes (reset pending, coordinated)
 
OPEN QUESTIONS
- Lateral movement across the finance subnet: NOT yet checked
- Was the staged archive sent out? Proxy and firewall egress not yet reviewed
- Mail compromise unknown: out-of-band comms until cleared

Two details make this example usable. The 15:05 clock event is separate from the 14:16 declaration, because the possible GDPR deadline starts when the organisation becomes aware of a personal data breach, not when the SOC declares an incident. And the handoff lists what was not done. The most dangerous handoff is the one where the next responder assumes lateral movement was already checked because nobody said it was not. The phishing email analysis walkthrough shows the same habit at the end of a phishing investigation: hand over the evidence as it stands, with open items stated.

Mistakes that make a plan fail on the day

Contacts that live inside the incident. The plan, the contact sheet and the war room all sit on the identity provider and collaboration suite the attacker now controls. Keep a printed contact sheet and a copy outside corporate SSO, and say where they are in section 0.

Names without authority. A list of names tells you whom to call. It does not tell the analyst at 3 a.m. whether isolating the backup server needs a second opinion. The pre-approved actions in section 3 are what let the SOC contain in minutes instead of waiting on a phone call.

Per-alert procedure copied into the plan. Once the ransomware query sits in both the plan and the playbook, one of the copies goes stale after the next SIEM migration. The plan links to the playbook library; the playbook links back to the plan for anything involving regulators or leadership. The SOC playbook template covers where that line sits.

A severity scale made of adjectives. "High: significant impact" does not let two people reach the same level. Criteria such as "privileged account compromised" or "regulated data confirmed exfiltrated" do.

Never exercised. r3's ID.IM-02 lists security tests and exercises as a source of improvements and points to NIST SP 800-84 for designing tabletop and functional exercises. A tabletop is the cheapest place to find a missing phone number, an approval nobody holds or a deadline nobody owns.

Testing the plan before it is needed

Run the first tabletop against the plan exactly as written. Pick a scenario your detections actually produce, give the room the first alert, and add new facts every 15 minutes: the account is also active on a server, a journalist emails the press office, legal asks when you became aware. Every time someone asks "who decides that?" and the plan has no answer, write it down. That list is your next version.

The plan covers the organisation. The analysts who run its first steps also need practice making the containment call on telemetry that looks like their own. SOCSimulator operations run that part: realistic SIEM, XDR and firewall evidence and a verdict at the end, so the "isolate, don't power off" reflex is already there when a real incident is declared. Background on the lifecycle itself is in the incident response glossary entry.