Incident Response Checklist: The Practical 2026 Guide

An incident response checklist earns its place only if it follows the order in which work actually happens, and gives the incident lead a quick way to see what has been done, what is outstanding and who owns it. NIST SP 800-61 Rev. 3 does not publish a checklist. It publishes a CSF 2.0 Community Profile of 134 rows, and every Detect, Respond and Recover Subcategory in it is rated High priority.

This incident response checklist turns those rows into tick-box items, ordered by CSF Function: preparation first (Govern, Identify and Protect), then Detect, Respond and Recover, and finally Improve (the Identify Improvement Category, ID.IM). Each item carries its Rev. 3 reference so you can trace it back to the source.

How this incident response checklist maps to Rev. 3

NIST SP 800-61 Rev. 3 splits its profile into two tables. Table 2 covers preparation (GV, ID, PR) and lessons learned (ID.IM). Table 3 covers incident response itself (DE, RS, RC). Rev. 3 also says lessons should be shared as soon as they are identified rather than held until recovery ends, which is why the improvement section below is not only a post-incident task. Our NIST incident response lifecycle post explains how the Functions replaced the old four phases.

Checklist section	Rev. 3 Functions	When you use it
Preparation	Govern, Identify, Protect (Table 2)	Before any incident; reviewed on a schedule
Detect	DE.CM, DE.AE (Table 3)	Continuously, up to the declaration
Respond	RS.MA, RS.AN, RS.CO, RS.MI (Table 3)	From declaration until recovery is initiated
Recover	RC.RP, RC.CO (Table 3)	From recovery initiation until its end is declared
Improve	ID.IM (Table 2)	Throughout, and formally after each incident

Preparation: the incident response checklist before an incident

None of the response items work if these are missing. Review them on a fixed cycle and after any major change.

Check	Rev. 3 reference
An incident response policy is approved and defines events, incidents and investigations	GV.PO.R1, Section 2.3
Roles, responsibilities and authorities are documented, including who may disconnect or shut down assets, with deputies named	GV.RR-02, Section 2.3
The incident response plan is current and synchronized with the business continuity plan	ID.IM-04.R1
Supplier contracts set incident responsibilities, information flows, coordination and authority to act	Section 2.2, GV.SC-08
Asset inventories are current and available to responders	ID.AM-01
Logs are generated and available for continuous monitoring	PR.PS-04
Backups are created, protected, maintained and tested	PR.DS-11
Cyber threat intelligence is received from sharing forums and sources	ID.RA-02
Existing risk estimation mechanisms are reused for incident response	ID.RA-05.R1
Incident declaration criteria and a known false-positive list are written	DE.AE-08.R1
Playbooks exist for the most common incident types, plus a procedure for redeploying the primary authentication platform	Section 2.3
An out-of-band contact list and communication channel are ready (our recommendation)	Supports RS.CO

Detect: incident response checklist items up to declaration

Check	Rev. 3 reference
Monitoring covers networks, the physical environment, personnel activity, external service providers, and computing hardware, software and data	DE.CM-01, -02, -03, -06, -09
Monitoring is tuned to keep false positives and false negatives at acceptable levels	DE.CM.R2
Events from multiple sources are correlated	DE.AE-03
Threat intelligence and asset context are applied to the analysis	DE.AE-07
Impact and scope of adverse events are estimated, then refined	DE.AE-04
Alerts reach the SOC and responders; tickets are raised automatically where useful	DE.AE-06
Declaration criteria are applied to known and assumed characteristics, and the time of declaration is recorded	DE.AE-08.R1

The last row is the hinge of the whole incident response checklist. If your team argues about whether something counts, our security event vs incident post covers the definitions and how to write criteria.

Respond: the core of the incident response checklist

Rev. 3 calls the Respond Function the core of incident response. Split its items across four sub-lists so each role can see its own work.

Manage the incident (RS.MA)

Check	Rev. 3 reference
An incident lead is designated	RS.MA-01.C1
The plan is executed; the incident response service provider is contacted if appropriate; continuity and disaster recovery plans are started as needed	RS.MA-01.R2, R3
A preliminary review verifies the incident; severity and urgency are estimated	RS.MA-02.R1
The incident is categorized by type and prioritized by scope, likely impact, time-critical nature and resource availability	RS.MA-03.R1, R2
A response strategy is chosen, balancing quick recovery against observing the attacker or investigating further	RS.MA-03.R3
Status is tracked: summary, indicators of compromise, status and time frame of each action, next steps	RS.MA.R3
Escalation (more resources or time) or elevation (a higher level of management) is triggered as needed	RS.MA-04
Recovery criteria are applied, taking operational disruption into account	RS.MA-05

Rev. 3 says incidents should not be handled first-come, first-served. Our incident severity levels post shows how to rank them using its six risk evaluation factors.

Analyze (RS.AN)

• Establish the sequence of events and the assets involved in each (RS.AN-03.R1).
• Look for underlying or systemic root causes (RS.AN-03.R3).
• Record every action taken, and protect those records from unauthorized access (RS.AN-06).
• Collect and retain evidence under your evidence preservation procedures, considering the possibility of prosecution (RS.AN-07.R1).
• Search other potential targets, not just the known ones, for indicators and persistence, so the incident’s magnitude is not underestimated (RS.AN-08.R1).

Communicate (RS.CO)

• Coordinate with internal and external parties under established procedures for what is reported to whom and when (RS.CO-02.R1, R2).
• Have counsel assess notification duties under each law, regulation and contract that applies; clocks and triggers differ by regime (RS.CO-02.R3, R4).
• Notify law enforcement and regulators based on plan criteria and management approval (RS.CO-02.R5).
• Update senior leadership regularly on major incidents (RS.CO-03.R2).
• Notify human resources when malicious insider activity has occurred (RS.CO-03.R3).
• Follow media communication procedures (RS.CO-03.R4).

Contain and eradicate (RS.MI)

• Choose containment using your criteria, including how long each measure will stay in place, from an emergency workaround removed within hours to a permanent fix (RS.MI note).
• Discuss any deliberate delay, such as redirecting the attacker to a sandbox, with legal first (RS.MI.R1).
• Contain the incident, through automated actions where configured and manual actions where needed (RS.MI-01).
• Identify all affected hosts and services, then remove persistence mechanisms and entry points (RS.MI-02).

Type-specific steps belong in playbooks rather than in a general incident response checklist. Our incident response playbook post covers how to structure them.

Recover: incident response checklist items for restoration

Check	Rev. 3 reference
Everyone with recovery duties knows the recovery plan and the authorizations each step needs	RC.RP-01.R2
Recovery actions are selected for timeliness, precision and reliability, and changed if needs shift	RC.RP-02
Backups and other restoration assets are checked for indicators of compromise, corruption and integrity issues before use	RC.RP-03.R1
Essential services are restored in the right order and system owners confirm normal operation	RC.RP-04.R1, R2
Restored assets are checked for indicators of compromise and root causes remediated before production use	RC.RP-05.R1
Restored systems are monitored to confirm the restoration is adequate	RC.RP-04.R3
Recovery progress is shared with leadership and with suppliers under contract rules	RC.CO-03
Public updates use approved methods; breach notification procedures are followed where they apply	RC.CO-04
The end of recovery is declared against criteria and an after-action report is prepared	RC.RP-06.R1

Improve: closing the loop

• Hold a lessons-learned review with everyone involved, covering what happened, what was done and how well it worked (ID.IM-03).
• Log improvements to the program itself and to wider controls, such as attacker techniques your safeguards did not block (ID.IM-03).
• Update the plan, policy, procedures and this incident response checklist when a significant improvement is needed (ID.IM-04.R2).
• Feed findings into the next exercise, including exercises with suppliers (ID.IM-02).
• Evaluate the program periodically through self-assessment, third-party assessment or audit (ID.IM-01).

Using an incident response checklist under pressure

Give the incident response checklist one owner: the incident lead. Rev. 3 notes that the incident lead is often responsible for safeguarding incident records, so the checklist and the record should be the same artifact. Each tick gets a time and initials.

Split it by role so the communications lead is not scrolling past forensic steps. Never delete an item that does not apply; mark it not applicable with a reason, because an auditor or regulator may later ask why a step was skipped. And rehearse it: a checklist first read during a live incident will be read slowly.

Keep a copy where the incident cannot reach it. If ransomware encrypts the document store or an attacker controls your identity provider, an incident response checklist that lives only on the shared drive is gone with everything else. A printed copy in the incident binder and an offline copy on the incident lead’s out-of-band device are cheap insurance.

Finally, remember what a checklist cannot do. Rev. 3 notes that every response strategy decision has trade-offs, such as observing an attacker versus returning quickly to normal operations. An incident response checklist makes sure those decisions are taken, recorded and owned. It does not make them for you, and it should never be used to delay a containment call that the incident lead has the authority to make.

Incident response checklist FAQ

Does NIST SP 800-61 Rev. 3 include an incident response checklist?

No. Rev. 3 is a CSF 2.0 Community Profile of Recommendations, Considerations and Notes. A checklist like this one is a way to turn its High-priority rows into actions.

Should we have one checklist or one per incident type?

One general incident response checklist for the steps every incident shares, plus a playbook per type for the specific technical actions.

Who should own the checklist?

The incident lead during an incident. Between incidents, the owner of the incident response plan keeps it current alongside the plan.

How often should it be reviewed?

Rev. 3 ID.IM-04.R2 says to review plans periodically or when a need for significant improvement is identified. Treat every lessons-learned review as a trigger.

Our Incident Response Toolkit provides 93 editable templates aligned to NIST SP 800-61 Rev. 3 — including the Incident Handling Checklist, the Incident Lead Handbook and the Lessons Learned and Post-Incident Review Procedure — for $99.