Most incident response plans are written for an auditor and read for the first time at 3 a.m., by someone who did not write them. That is the test this template is built to pass: not «does it look complete», but «can somebody who is frightened and half-awake do the right thing with it open on a second screen».
This incident response plan template gives you the complete section structure with guidance on what belongs in each part, a severity matrix you can adapt, a first-hour checklist, and an editable copy to download. It is aligned to the current NIST guidance and to what a PCI DSS assessor will test.
- Most templates online still teach the four-phase lifecycle NIST retired in April 2025. Check the date on anything you copy.
- If PCI DSS applies, Requirement 12.10 tells you exactly what the plan must contain — and the sub-requirements are where assessments actually fail.
- A plan without a severity matrix and named humans is a document, not a response capability.
- The parts auditors test hardest are the ones nobody rehearses: annual testing, training, and alert handling.
Why most incident response plan templates are already out of date
If you search for an incident response plan template, most of what you will find teaches the four-phase lifecycle: preparation, detection and analysis, containment/eradication/recovery, and post-incident activity. That model came from NIST SP 800-61 Revision 2, and it was the industry’s shared vocabulary for over a decade.
It was retired. In April 2025, NIST published SP 800-61 Revision 3, which reframes incident response as part of cybersecurity risk management and aligns it to the six Functions of the Cybersecurity Framework 2.0 — Govern, Identify, Protect, Detect, Respond and Recover — rather than to a sequence of phases.
The practical difference is not cosmetic. The phase model implied that response starts when detection ends. The Function model says the things that decide whether your response works — governance, asset inventory, protective controls — belong to the plan even though they happen long before the incident. It also stops the pretence that containment, eradication and recovery happen in a tidy order; in a real ransomware event they overlap for days.
You do not have to rewrite a working plan tomorrow. But if you are building one now, build it on the current model — and if a template you found does not say which revision it follows, that tells you something about how carefully it was written.
What PCI DSS Requirement 12.10 demands
If cardholder data is in scope, your plan is not a matter of good practice. Requirement 12.10 is prescriptive, and each sub-requirement is tested separately:
| Requirement | What it demands |
|---|---|
| 12.10.1 | A documented plan covering roles, responsibilities, communication and contact strategies; containment and mitigation procedures for different incident types; business recovery and continuity; data backup processes; analysis of legal reporting requirements; coverage of all critical system components; and reference to the payment brands’ own incident procedures. |
| 12.10.2 | The plan is reviewed, updated and tested at least once every 12 months. |
| 12.10.3 | Specific personnel are available 24/7 to respond. |
| 12.10.4 | Responders are trained periodically, on their own responsibilities and on the monitoring tools they will use. The frequency is justified by a targeted risk analysis (12.10.4.1). |
| 12.10.5 | The plan covers monitoring and response to alerts from security systems: network controls, IDS/IPS, file-integrity monitoring, anti-malware, change-detection on payment pages, wireless detection. |
| 12.10.6 | The plan is modified and evolved from lessons learned and from environment changes. |
| 12.10.7 | Procedures for when PAN is found where it should not be: retrieve and delete it securely, check for sensitive authentication data, determine how it got there and fix the leak. |
The sub-requirement that catches people is 12.10.7. Most plans describe what to do when an attacker gets in, and say nothing about what to do when a developer finds a CSV of card numbers in a log bucket. That second scenario is far more common, and it is explicitly required.
The template, section by section
Use this as the table of contents. Under each section is what actually belongs there — the parts people leave vague are the parts that fail on the night.
Incident response plan — structure
- Document controlOwner, version, approval date and next review date. An unapproved plan is a draft, and a draft is what an assessor will call it.
- Purpose and scopeWhich systems, which data, which locations and which subsidiaries. If PCI applies, name the cardholder data environment explicitly. Vague scope is how plans end up not covering the system that actually broke.
- DefinitionsWhat is an event, what is an incident, what is a breach. Write the threshold that promotes one into the other, because that decision will be argued about at 3 a.m.
- Roles and responsibilitiesNamed people, not job titles alone: incident lead, technical lead, communications, legal, executive sponsor, and the deputy for each. Add the external ones — acquirer, payment brands, forensic investigator, insurer, outside counsel, your QSA.
- Severity classificationThe matrix below. Each level needs a definition, an example, an acknowledgement time and who gets woken up.
- Detection and reportingEvery channel an incident can arrive through: monitoring alerts, the helpdesk, an employee, a customer, a supplier, a researcher, law enforcement. One phone number and one mailbox that work at 3 a.m., and what information to capture.
- Response procedures by incident typeShort playbooks, not prose: ransomware, cardholder data exposure, account compromise, supplier breach, insider misuse, denial of service, and PAN discovered where it should not be. Each with first actions, who decides, and what must not be done.
- Containment and evidenceWho authorises isolating or shutting down a production system, and the rule that evidence is preserved before anything is wiped. This single sentence saves the investigation.
- CommunicationsInternal, customers, regulators, acquirer and payment brands, law enforcement, insurer. Include holding statements written in advance: nobody drafts good copy during a crisis.
- Legal and regulatory obligationsYour applicable reporting duties with their deadlines, listed by jurisdiction. This is a legal question, not an IT one — get it answered before you need it.
- Recovery and closureThe criteria for declaring the incident closed, who signs it off, and how you verify the environment is clean before restoring.
- Post-incident reviewTimeline, root cause, what worked, what did not, and actions with an owner and a date. Without owners and dates it is a feelings exercise.
- Testing and maintenanceThe annual test at minimum, who takes part, how findings feed back into the plan, and the training programme with its justified frequency.
- AppendicesContact list, critical systems inventory, decision log template, communication templates, and a printed copy — because your plan may live on the network you just isolated.
Print it. Your plan may live on the network you just disconnected.
Severity: the table that stops the argument
The most valuable page of any incident response plan is the one that tells a tired engineer whether to wake the CTO. These levels are an example to adapt, not a standard — but adapt something, and agree it before you need it.
| Level | Example | Acknowledge | Who is told |
|---|---|---|---|
| SEV1 Critical | Confirmed compromise of cardholder data, ransomware encrypting production, active exfiltration | 15 minutes, any hour | Incident lead, executive sponsor, legal — immediately |
| SEV2 High | Confirmed intrusion with no data impact yet, malware on an in-scope server | 30 minutes | Incident lead; executive sponsor within 4 hours |
| SEV3 Medium | Endpoint malware contained by EDR, phishing with credentials entered | 4 working hours | Security team; escalate if scope grows |
| SEV4 Low | Policy violation, isolated failed login patterns, unverified report | Next working day | Security team, logged only |
The first hour
The plan’s opening page should be this list, in this order. Everything else is reference material.
- 1Write down the time. Start a decision log with a timestamp on every entry. It becomes your evidence, your timeline and your post-incident review.
- 2Assign the incident lead. One person, by name, who is not also doing the technical work.
- 3Classify the severity. Use the matrix, and re-classify later if it grows. Under-calling it is the more common error.
- 4Preserve evidence before touching anything. Memory captures and log copies first. Rebuilding the box destroys the answer to «how did they get in».
- 5Contain what you can without destroying evidence. Isolate at the network, disable accounts, revoke sessions and tokens.
- 6Open the communication channel agreed in the plan — and assume the usual one may be compromised.
- 7Notify the people the plan says to notify, on the clock the plan gives you. If cardholder data may be involved, that includes your acquirer.
- 8Decide whether you need external help — forensics, legal, insurer — early. Making that call at hour twenty is what turns an incident into a bad one.
What an assessor actually tests
Writing the plan is the easy half. In an assessment, the questions land on the parts that require the plan to have been alive for a year:
- Evidence of the annual test — attendance, scenario, findings, and what changed in the plan afterwards. A tabletop with no output does not count.
- Evidence of training, per responder, matched to their role and to the tools they operate — plus the risk analysis that justifies the frequency.
- Evidence that alerts get handled: tickets, timestamps, and what happened to the alerts that fired at 2 a.m. on a Sunday.
- Evidence the plan evolved: a version history that shows lessons learned going back in.
- The 24/7 rota, with names and contact details that are current.
Five ways these plans fail
- Job titles instead of people. «The Security Manager will…» is useless when the Security Manager left in March.
- No severity matrix, so every incident is either ignored or escalated to the board.
- Recovery steps that assume the network works. Store the plan, the contacts and the backups’ restore procedure somewhere reachable when the domain is down.
- Legal obligations left as «consult legal». The deadlines exist whether or not you looked them up in advance.
- Written once. A plan that has never produced a lesson learned has never been used, and it will show the first time it is.
Take the template
The editable version follows this exact structure, with the guidance notes in place so whoever fills it in knows what each section is for.
Two honest caveats. A template gets you a structure, not a capability: the value appears when you name real people, agree the severity levels with the business, and test it. And if PCI DSS is in scope, the plan has to match the environment your assessor will look at — which is the part we usually end up doing alongside the PCI DSS work rather than as a separate exercise.
Filling this in is where most teams discover their real gap is detection: a response plan cannot start before somebody notices. If that is your situation, the conversation is about monitoring and incident response readiness together, and it is one we have a lot. Talk to our DFIR team.
Sources
- NIST SP 800-61 Revision 3 (April 2025), Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile — replaces the four-phase lifecycle of Revision 2.
- NIST Cybersecurity Framework 2.0 — the six Functions: Govern, Identify, Protect, Detect, Respond, Recover.
- PCI DSS v4.0.1, Requirement 12.10 and its sub-requirements 12.10.1 to 12.10.7.
