The Problem
Every regulated institution is required to have an incident response plan. Most have one. Fewer have actually tested it. And a significant number discover its gaps at the worst possible time — in the middle of an actual incident, when staff are under pressure, decisions need to be made quickly, and the regulators may be watching closely.
An incident response plan is not a form you fill out to satisfy an examiner. It is an operational playbook that determines how fast you contain a breach, how clearly you communicate with affected parties, and whether you meet your regulatory notification obligations on time. The institutions that handle incidents well almost always have plans that are specific, tested, and practiced. The ones that handle incidents poorly almost always have plans that are generic, outdated, or untested.
What Regulators Require
The GLBA Safeguards Rule requires covered financial institutions to have a written incident response plan as part of the information security program. The 2021 Safeguards Rule update added specific requirements: the plan must address the goals of the response program, internal processes for responding to a security event, clear roles and decision-making authority, communications and information sharing, remediation of system weaknesses, and documentation and reporting.
In addition, the bank regulators’ 36-hour notification rule (effective May 2022 for OCC, FDIC, and Federal Reserve-supervised institutions) requires notification to the primary federal regulator within 36 hours of determining that a “computer-security incident” has occurred that rises to the level of a “notification incident.” NCUA has parallel notification requirements. Meeting a 36-hour notification deadline requires a plan that has been thought through in advance — not one you are reading for the first time during the incident.
What an Effective IRP Looks Like
Clear Incident Classification
The plan should define what constitutes a security event, a security incident, and a notification incident — and provide examples specific to your environment. Without clear definitions, staff will spend critical time during an actual event debating whether something needs to be escalated. Classification criteria should be specific enough to guide decision-making, not just state that “significant incidents” should be reported.
Defined Roles and Decision Authority
During an incident, people need to know who is in charge, who makes containment decisions, who authorizes external communications, and who notifies the board. Ambiguity about authority causes delays. The plan should name roles (not just titles), with backups identified for each role in case the primary contact is unavailable. This is especially important at smaller institutions where a single person may wear multiple hats.
Specific Notification Timelines
Regulatory notification timelines are unforgiving. The 36-hour rule leaves very little room for internal deliberation. Your plan should document the notification chain explicitly: who determines that a notification incident has occurred, who prepares the notification, who submits it, and through what channel. The same applies to customer notification obligations under state data breach laws, which vary by state and can be as short as 30 days from discovery.
Containment and Eradication Procedures
Generic plans describe containment at a high level. Effective plans include specific steps for common incident scenarios relevant to your environment — ransomware, business email compromise, core system outage, unauthorized data access. These scenario-specific playbooks don’t need to anticipate every possibility, but they should give responding staff a starting point rather than a blank page.
Evidence Preservation
Many institutions inadvertently destroy forensic evidence during incident response by reimaging systems before logs are preserved or by failing to capture network traffic data. The plan should include explicit steps for evidence preservation — particularly if the incident may result in litigation, regulatory action, or insurance claims. Coordinate with legal counsel and, if applicable, cyber insurance carriers on what evidence they will need.
Post-Incident Review
A post-incident review (sometimes called a lessons-learned process) is required by the GLBA Safeguards Rule and is a standard examiner expectation. After every significant incident — and ideally after exercises as well — the response should be reviewed for gaps, and the plan updated accordingly. Examiners will ask whether prior incidents resulted in plan improvements. An institution that experienced a phishing compromise two years ago and has not updated its plan or controls since will have difficulty explaining why not.
Testing Your Plan
A plan that has never been tested is an untested hypothesis. At minimum, conduct an annual tabletop exercise that walks key staff through a realistic incident scenario. The scenario should be specific enough to force real decisions: Who do you call first? At what point do you notify the board? When does the 36-hour clock start? What do you say to customers?
Document the exercise — the scenario, the participants, the decisions made, and any gaps identified. Then update the plan to address those gaps. This documentation is what examiners want to see, and it demonstrates that your program is functional and improving, not static.
Practical Checklist
- Written incident response plan reviewed and approved within the last 12 months
- Incident classification definitions are specific and include examples relevant to your environment
- Roles, responsibilities, and decision authority documented with named individuals and backups
- Regulatory notification timelines and procedures explicitly documented (36-hour rule, state breach laws)
- Customer and stakeholder communication templates prepared in advance
- Scenario-specific playbooks for common incident types (ransomware, BEC, data breach)
- Evidence preservation procedures included in the plan
- Cyber insurance carrier and legal counsel contact information documented and current
- Annual tabletop exercise conducted with results and identified gaps documented
- Post-incident review process defined and followed for any significant security events
- Board notification procedure defined and reflected in board meeting minutes when applicable