◆ Quick answer
An Incident Response Plan template should include an incident log (incident ID, dates detected and reported, incident type, severity, systems and data types affected, estimated records affected, Incident Commander, status, containment and resolution dates, root cause category, breach notification flag, lessons learned reference), a phase-by-phase response checklist with responsible roles, and a state-by-state breach notification tracker.
Guide vs. template
This guide explains what belongs in the template. The paid template gives you the editable working files so you're not rebuilding from a blank page.
Paid template includes
- ◆ Incident response plan template
- ◆ Incident classification and severity matrix
- ◆ Breach notification letter templates
- ◆ All 50 states + DC notification requirements
What is this template for?
An Incident Response Plan (IRP) template is the working file security and compliance teams use to log incidents with consistent fields, classify severity, walk a phase-by-phase response checklist under pressure, track breach notification obligations by state, and capture lessons learned. The useful version is not a policy PDF describing intent. It is the incident log everyone actually fills in, the checklist the Incident Commander runs during the event, and the notification tracker that tells you — mid-incident, without research — which state attorneys general need notice and by when.
◆ Audience
Who needs this.
- ◆ You do not know your breach notification deadline off the top of your head — and in a real incident, you will not have time to look it up.
- ◆ Your Incident Response Plan exists as a document but has never been tested, and a bank partner or examiner is starting to ask about tabletop exercises.
- ◆ Your fintech operates across multiple states and needs a single-reference tool for jurisdiction-specific notification requirements.
- ◆ You need to meet the federal banking regulator 36-hour computer-security incident notification requirement.
- ◆ Past incidents were handled from memory and Slack threads, with no consistent log, severity classification, or lessons-learned trail.
◆ Required fields
What every row needs.
The fields that make this template defensible to an auditor, bank partner, or examiner — and what goes in each.
| Field | Why it matters | Example |
|---|---|---|
| Incident ID, date detected, and date reported | The detection-to-report gap is one of the first things reviewers examine — you cannot show it without both dates. | IR-2026-004, detected 2026-03-01, reported 2026-03-01 |
| Incident type | Consistent typing enables trend analysis and routes the right playbook. | Social Engineering; Unauthorized Access; Vendor/Third-Party; Ransomware; DDoS/Availability |
| Severity | Severity drives escalation speed, who gets activated, and whether breach counsel is engaged. | Critical — ransomware deployed on 3 workstations; Medium — phishing compromised single employee credentials, no exfiltration confirmed |
| Systems affected and data types affected | Scoping the blast radius determines whether this is an IT event or a legal event. | Staging DB and firewall — PII; Payment API and vendor systems — financial data; Email and SSO — credentials |
| Estimated records affected | Notification thresholds and regulator obligations turn on this number. | 2,500 customer records (staging database exposure); 8,000 customers (vendor payment processor breach) |
| Incident Commander | One named owner per incident prevents the everyone-and-no-one problem during response. | A. Johnson; role activated per the escalation matrix based on severity |
| Containment date and resolution date | Time-to-contain and time-to-resolve are the core response metrics — and they only exist if the dates are logged. | Contained 2026-02-03; resolved 2026-02-10 |
| Root cause category | Aggregating by root cause tells you where to invest — controls, training, or vendors. | Human error; technical vulnerability; vendor/third-party; malicious actor |
| Breach notification required flag | Connects the incident log to the legal workstream so notification analysis is never skipped. | Yes — notification sent to 3 states; Under Assessment — forensics in progress; No — MFA prevented account takeover |
| Lessons learned reference | Closing an incident without a lessons-learned entry means paying for the same incident twice. | LL-2026-002 — firewall change management gap; LL-2026-005 — CDN rate limiting effective, origin protections enhanced |
◆ Worked example
Example incident log row
| Incident | IR-2026-002 — Unauthorized Access, High severity. Unauthorized access to staging database via misconfigured firewall rule; 2,500 customer records potentially exposed. |
|---|---|
| Response | Contained same day; resolved in 7 days. Root cause: technical vulnerability — firewall rule change during deployment. |
| Notification | Breach notification required: Yes — notification sent to 3 states. Lessons learned logged as LL-2026-002. |
◆ Implementation roadmap
How to roll this out.
Stand up the incident log and severity classification before you need them
Owner · Security or compliance lead
Output · Master incident register with consistent fields and dropdowns — incident type, severity, status, root cause — so every incident is logged the same way
Build the phase-by-phase response checklist with named roles
Owner · Incident response lead with SOC, IT, legal, and privacy input
Output · Action items across detection, escalation and assessment, containment, and beyond — each assigned to a responsible role (SOC analyst confirms the alert is a true positive; Incident Commander establishes an out-of-band communication channel; Technical Lead preserves initial evidence)
Pre-map breach notification obligations by state
Owner · Privacy officer with breach counsel
Output · Reference covering individual notification deadlines, attorney general notification triggers and thresholds, and substitute notice provisions — deadlines range from 30 days in states like Colorado and Florida to 60 days in Connecticut and Delaware, with several states requiring "most expedient" notice
Wire in escalation triggers for counsel, insurance, and partners
Owner · Incident Commander with legal counsel
Output · Checklist steps that fire automatically at severity thresholds: engage external breach counsel for Sev-1 and Sev-2 incidents, notify the insurance carrier per policy requirements, notify the bank partner per contractual requirements
Test with a tabletop exercise and close the loop on lessons learned
Owner · Incident response lead
Output · Exercise findings plus a lessons-learned log referenced from every closed incident, with remediation items tracked to completion
◆ Ready to use it?
Download the Incident Response & Breach Notification Kit.
Use the guide to understand the structure, or buy the editable template to move faster.
◆ FAQ
Frequently asked questions.
What should an Incident Response Plan template include? ⌄
Four working artifacts: a master incident log with consistent fields (type, severity, systems and data affected, records affected, Incident Commander, containment and resolution dates, root cause, notification flag, lessons learned reference), a severity classification matrix, a phase-by-phase response checklist with responsible roles, and a state-by-state breach notification tracker. A policy document alone is not a plan you can run at 2am.
What is the difference between an incident and a breach? ⌄
Every breach is an incident, but not every incident is a breach. A phishing click stopped by Multi-Factor Authentication (MFA) is an incident with no notification obligation. Unauthorized acquisition of unencrypted personal information is what state statutes generally define as a breach — and that is when notification clocks start. The incident log should carry a "breach notification required" field with Yes / No / Under Assessment so the legal determination is explicit for every incident.
How fast do I have to notify after a breach? ⌄
It depends on the state and the regulator. State individual-notification deadlines range from 30 days (for example Colorado and Florida) to 60 days (Connecticut, Delaware), with many states requiring notice in the "most expedient time possible." Attorney general notification is a separate obligation with its own triggers — often a resident-count threshold like 500 or 1,000. Federally regulated institutions also face requirements like the banking agencies' 36-hour computer-security incident notification rule. Pre-map all of this before an incident; verify with breach counsel during one.
Who should be the Incident Commander? ⌄
A named individual per incident — activated through the escalation matrix based on severity — with authority to assemble the response team, establish secure communications, own the incident timeline, and make escalation calls: executive notification, external breach counsel for Sev-1 and Sev-2 incidents, insurance carrier, and bank partner. It is a role, not a department.
Do vendor breaches go in my incident log? ⌄
Yes. If a vendor holding your customer data is breached, it is your incident to log, scope, and potentially notify on. Track it with type Vendor/Third-Party, record affected data and record counts, obtain the vendor's forensic report, and run your own notification analysis — a payment processor breach affecting 8,000 of your customers is a multi-state notification event regardless of whose systems failed.
How do I test an Incident Response Plan? ⌄
Run tabletop exercises: a facilitated scenario walked end to end against your actual checklist and escalation matrix. The output should be captured findings and tracked action items, not just attendance. Bank partners and examiners increasingly ask whether the plan has been exercised, and an untested plan reliably fails at the same points — unclear escalation ownership, missing contacts, and notification analysis started too late.