Master Incident Response Plan Checklist
Check the part of your incident response plan that every incident shares: roles and authority, the severity model, escalation and on-call, communications and legal privilege, notification decisions, evidence, recovery and testing. 35 items with guidance and a sample organisation already filled in.
Template & sample only — a structured starting point with sample content, not legal, audit, certification or investment advice.Customise it with your own details for free; exporting the generated document is part of Pro.
The master plan is the part every incident shares: who is in charge, how bad it is, who gets woken up, what is said and to whom, who decides on notification, how evidence is kept and how you recover and learn. Mark each item In place, Partly, Not in place or N/A. A material item marked Not in place is a red flag in the generated review. Domain playbooks (ransomware, identity, cloud and the rest) then plug into this plan.
- An out-of-band communication channel is ready for when email, chat or identity systems may be compromised, and the team knows how to join it
Your context
Roles & authority
Who runs an incident, and what they are allowed to decide without asking. Most slow responses are authority problems, not technical ones.
An incident commander role is defined, separate from the people doing technical work, with a named primary and deputyNIST SP 800-61r3material
Pre-approved authority is written down: who can isolate systems, disable accounts, take a service offline or shut down the internet edge without further sign-offmaterial
An executive sponsor is named for SEV1/SEV2 incidents, with authority over business trade-offs such as shutting down revenue systems or engaging outside firms
Supporting roles are listed with contacts: legal, privacy, communications, HR, finance, IT operations and the business owners of critical systems
A scribe or timeline keeper is assigned for every SEV1/SEV2 incident from the first call
Severity model
One shared scale, so that "this is a SEV2" means the same thing to security, IT, legal and the executive team.
Severity levels (for example SEV1–SEV4) are defined in plain business terms: impact on operations, data, safety, customers and reputationNIST CSF RS.MAmaterial
Each level states what it triggers: who is paged, the update cadence, whether executives and legal are engaged, and whether the IR retainer is called
Severity can be raised or lowered during an incident, and the plan says who decides and that each change is logged with a reason
The plan maps incident types to domain playbooks (identity, ransomware, data breach, cloud and so on) so responders know which playbook to open after triage
Escalation & on-call
A 24/7 on-call path exists for security incidents, with a primary, a deputy and a maximum time to acknowledgematerial
Every intake route is defined and monitored: SOC alerts, help desk, staff reports, customer and researcher reports, supplier notices and law enforcement contact
Escalation time limits are set: how long triage may run before a decision on severity, and when a suspected incident must be escalated even if unconfirmed
An out-of-band communication channel is ready for when email, chat or identity systems may be compromised, and the team knows how to join itmaterial
Communications & legal privilege
What you say, to whom, and under whose direction — so the response is accurate, consistent and protected where the law allows.
The plan says when legal counsel is engaged and how investigation work is directed to support legal privilege where it is available in your jurisdictionCheck with counselmaterial
Internal update cadence and audiences are defined per severity (incident team, executives, board, all staff), with a single owner for updates
Holding statements are pre-drafted for customers, media and partners, with approval routes that work out of hours
Staff guidance says who may speak about an incident, that speculation stays off chat and email, and how to route media or attacker contact
A rule covers contact from an attacker (ransom notes, extortion emails): nobody engages without the incident commander, counsel and, where used, a specialist negotiator
Notification decision process
Deadlines start from when you become aware or determine materiality, not from when you finish investigating. Decide who decides before the clock starts.
A named decision owner and process exist for regulatory, contractual and individual notifications, with legal and privacy inputmaterial
A register lists the notification obligations that may apply: data protection (for example GDPR 72 hours to the supervisory authority after becoming aware), sector rules, securities disclosure and contractsGDPR Art. 33material
The plan defines when the organisation is treated as "aware" of a breach, and requires the time of awareness to be recorded
Cyber insurance notification terms are known: who notifies, how fast, and which panel firms must be used to keep cover
Each notify / do-not-notify decision is documented with the facts known at the time and the reasoning
Evidence handling
Responders know what to preserve before containment changes it: volatile data, logs, disk images, cloud audit trails and mailbox dataISO/IEC 27037material
Chain of custody is recorded for evidence that may go to court, regulators or insurers: who collected it, when, how, and where it is stored
Log retention covers a realistic dwell time for your key sources (identity, endpoint, network edge, cloud control plane)
A legal hold process can stop routine deletion of relevant data once an incident is declared
Recovery & lessons learned
Recovery criteria are defined: what must be true (attacker access removed, credentials rotated, systems rebuilt or verified clean) before a system goes back into serviceNIST CSF RC.RPmaterial
Recovery order follows an agreed list of critical services and their dependencies, including identity and backups
Heightened monitoring continues for an agreed period after recovery to catch re-entry
A blameless post-incident review is required for SEV1/SEV2 within a set time, producing actions with owners and dates that are tracked to closurematerial
Testing cadence
The plan is exercised at least yearly with a tabletop that includes executives, legal and communications, not only the technical teammaterial
Technical drills test the steps that fail in practice: restoring from backup, revoking sessions at scale, isolating a network segment, joining the out-of-band channel
The plan and contact lists are reviewed at least yearly and after every SEV1/SEV2 incident, major reorganisation or new regulation
New responders and on-call staff are trained on the plan before they join the rota
What this template gives you
- A master IR plan covers what every incident shares. Domain playbooks (ransomware, identity, cloud and so on) add the technical steps for each incident type.
- 35 checks in eight sections: roles & authority, severity model, escalation & on-call, communications & privilege, notification decisions, evidence, recovery & lessons learned, and testing.
- Material items marked Not in place are flagged; each section gets a weighted score.
- Starts from a sample logistics company so you can see what good answers look like, then replace them with your own.
- If you do not have a plan yet, draft one with the Incident Response Plan Builder, then review it here.
Frequently asked questions
What belongs in a master incident response plan?
The decisions and structure that do not change with the type of attack: who leads, what the severity levels mean, who is paged, how and when executives, legal and communications are involved, who decides on regulatory and customer notification, how evidence is preserved, when systems may return to service, and how the plan is tested. The technical steps for a specific incident type belong in a domain playbook that refers back to it.
How is this different from the Incident Response Plan Builder?
The plan builder helps you draft a plan. This checklist reviews a plan you already have, item by item, and shows where it is weak. Many teams use the builder first and this checklist at each annual review.
Which frameworks does it follow?
It is organised around the incident response guidance in NIST SP 800-61 Revision 3 and the Respond and Recover functions of the NIST Cybersecurity Framework 2.0, and it is consistent with ISO/IEC 27035. The wording is our own and no clause numbers are reproduced.
Is this a finished document I can rely on?
No. Every tool in this suite is a template with sample content. It gives you a structured, editable starting point and generates a document from your own answers, but it is not legal, audit, certification, investment or professional advice. Review and adapt the output, and have it checked by the appropriate specialist before you rely on it.
Who can use it?
Anyone. Using it and customising it with your own details is free, and your work is saved in your own browser. Exporting the generated document (Word, PDF, Markdown, CSV) is part of any PlayCISO paid plan.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.