After the 36-Hour Clock Stops: What OCC Examiners Review Following a Bank Cyber Incident

TL;DR

• Filing the 36-hour OCC cyber incident notification starts regulatory awareness of the incident—the examiner follow-up is what tests whether your incident response program can prove what it documented
• Post-notification examiner reviews most commonly surface: undocumented incident classification decisions, gaps in SaaS and email detection coverage, and policies that describe controls that aren’t enforced in practice
• The OCC’s own April 2025 email breach—detected late because of SaaS monitoring gaps—is the reference case for why detection coverage across cloud and email environments matters as much as core banking infrastructure
• Since January 1, 2026, OCC examiners for community banks focus on whether risk management decisions are documented and defensible, not whether policies match a checklist format

There’s a version of the 36-hour notification that feels like the finish line. You’ve identified the incident. You’ve escalated internally. You’ve drafted the notification. You’ve sent it to your OCC relationship manager at 2:47 AM because the clock doesn’t stop for business hours. The incident is reported.

That feeling is wrong.

The notification is the beginning of the regulatory interaction, not the end. What follows—documentation requests, examiner review of your incident response program, and in some cases a targeted examination—is where most incident response programs either hold up under scrutiny or develop examination findings. Here’s what to expect, and what to have ready.

The Regulatory Framework: 12 CFR Part 53

Under 12 CFR Part 53, banking organizations must notify their primary federal regulator as soon as possible—and no later than 36 hours—after determining that a “notification incident” has occurred. A notification incident is a computer-security incident that has materially disrupted or degraded covered services, operations, or the stability of the financial sector, or is reasonably likely to do so.

The rule covers OCC-supervised national banks and federal savings associations. Parallel requirements apply to FDIC-supervised state non-member banks (under the FDIC’s computer-security incident notification rule) and Federal Reserve-supervised state member banks. Bank service providers face their own notification obligation to notify affected bank customers immediately upon determining that a notification incident has occurred.

What the rule doesn’t specify: what comes after the 36-hour notification. That’s where examiner discretion and supervisory judgment enter.

What the Examiner Follow-Up Actually Looks Like

The OCC examiner response to a notification incident isn’t standardized the way the notification itself is. Outcomes depend on the bank’s prior examination history, the severity of the incident, whether customer data was involved, and—critically—whether the bank’s documentation tells a coherent story.

Here’s the typical sequence:

Immediate (0–5 business days): Your OCC supervisory office receives the notification and may follow up with questions. These are typically factual: what systems were affected, what customer data was involved, what was the initial containment action, and what is the current status. This is a preliminary scoping exchange, not a formal examination request.

Short-term (1–8 weeks): If the incident is classified as significant, the examiner may request follow-up documentation. This is where the examination content begins. Requests commonly include: your incident timeline from first detection to notification, your incident classification rationale, evidence of internal escalation consistent with your written incident response plan, and your initial root cause assessment.

Extended (2–6 months): For major incidents—particularly those involving customer data, extended dwell time, or regulatory notification to multiple agencies—a targeted examination of your cybersecurity and incident response controls may follow. This is a formal examination, not just a documentation review. Examiners will evaluate your detection capabilities, your classification processes, your notification execution, and your remediation.

The severity of the examiner follow-up is often more correlated with the quality of your documentation than the severity of the incident itself. An institution that experienced a significant incident and can produce a complete, consistent documentation set—timeline, classification rationale, escalation trail, remediation evidence—typically receives less examiner attention than one that experienced a moderate incident and cannot document why the classification decision was made.

The Reference Case: The OCC’s Own Incident

In April 2025, the OCC disclosed a major security incident involving its own email system. Unauthorized access to emails and attachments had occurred over a significant period—the OCC hadn’t detected it until abnormal activity was observed months later. The OCC notified Congress per its own reporting obligations. Congress was not satisfied with the timeline. In a letter to the Comptroller, the House Financial Services Committee asked pointed questions about how long the access occurred, how it went undetected, and what controls failed.

The OCC’s own experience surfaced two lessons that apply directly to supervised institutions:

Detection coverage across SaaS and email environments matters as much as core banking. The OCC’s monitoring gap was in an email system—not a core banking platform, not a payment rail. Many bank cybersecurity programs are built around network and infrastructure monitoring; coverage for cloud-hosted email and SaaS tools is often weaker. That gap is where modern threat actors operate, and it’s increasingly what examiners ask about.

Dwell time is a regulatory question. The period between when unauthorized access began and when it was detected determines how long the incident ran before the 36-hour clock started. Examiners evaluate detection timing not just as an operational metric but as evidence of whether your detection capabilities are calibrated for the threats you face.

The OCC’s 2025 cybersecurity disclosure to Congress reinforced a point it makes in examinations: the absence of anomaly-based detection across your full environment—including SaaS and email—is an examination finding waiting to happen.

The Five Documentation Gaps That Create Examination Findings

Based on OCC, FDIC, and FFIEC examination patterns through 2026, these are the documentation gaps most commonly cited in post-incident examination findings:

1. Undocumented Classification Decisions

The incident happened. You made a determination that it did or didn’t meet the notification threshold. That determination needs to be documented—not just the outcome, but the reasoning.

Examiners ask: how did you conclude this was a notification incident? Or: how did you conclude this wasn’t? If the answer is “we had a call and decided,” that’s not documentation. The classification decision should have a record: what facts were known at the time, who was in the room (or on the call), what criteria the team applied, and what the conclusion was.

Undocumented classification decisions are the most common post-notification examination finding because they affect the most fundamental question: did the 36-hour clock start when it should have, and did you notify when required?

2. Detection Coverage Gaps

Examiners evaluate whether your detection capabilities are appropriate for the environment you operate in. Gaps specifically flagged in recent examination patterns:

• No anomaly-based monitoring for cloud-hosted email and SaaS tools
• Logging configured for retention periods shorter than the typical dwell time for relevant threat types
• Privileged access activity not monitored or log review not occurring on a defined cadence
• No process for reviewing log integrity (logs that can be modified or deleted by an attacker don’t provide reliable detection)

The question isn’t whether you have a SIEM. It’s whether the SIEM has coverage across all the environments where an incident could originate.

3. Policy-to-Practice Gaps

This is the most durable finding category across all examination types: your written incident response policy describes controls that aren’t consistently enforced in practice.

Common examples:

• Policy requires notification to the CISO within one hour of discovery; actual notifications happen hours later with no documentation trail
• Policy requires executive notification before external communications; evidence shows external communications went out before internal escalation
• Policy requires an incident log entry within 30 minutes of triage; logs show gaps or no entries for several incident categories

Under OCC Bulletin 2025-24, which took effect January 1, 2026, OCC examiners for community banks focus on whether risk management decisions are documented and defensible—not whether policies match a checklist format. That shift actually increases the scrutiny on policy-to-practice gaps, because the question is now “can you demonstrate that your actual practice matches your documented approach?” rather than “does your policy match our template?“

4. Remediation Evidence

Filing the notification doesn’t satisfy the examiner’s interest in whether the incident was fixed. Post-incident follow-up typically asks for evidence of remediation: what specific actions were taken, when they were completed, and how the effectiveness of those actions was validated.

Remediation documentation gaps look like: a list of actions with no completion dates, remediation steps described but no evidence collected, or a patch applied to the directly affected system but not to other systems running the same vulnerable software.

The remediation audit trail—timestamped, evidence-linked—is what turns a remediation claim into an examiner-accepted remediation finding.

5. Post-Incident Lessons Learned

Examiners increasingly ask for evidence that the incident informed your control environment going forward. This is the after-action review requirement made formal: what did you learn, what did you change, and how are you verifying the change is working?

The absence of a documented lessons learned process—or a lessons learned record that identifies no changes because “no significant deficiencies were found”—tends to generate follow-up questions. Significant incidents produce lessons. Institutions that can’t document what they learned are typically institutions that didn’t look.

The 2026 Examination Standard: Documented and Defensible

The framework shift under OCC Bulletin 2025-24 and the FFIEC CAT retirement (August 31, 2025) changed what examiners look for in cybersecurity programs. The FFIEC CAT—structured around a specific set of declarative statements the institution would affirm—has been replaced by NIST CSF 2.0 as the recommended framework. The examination standard is no longer “does your policy document match this template?”

It’s: “Can you show us that risk management decisions are documented, and can you defend those decisions with evidence?”

For incident response programs, that means:

• The classification decision is documented, including the facts available at the time and the criteria applied
• The timeline is reconstructable, from first detection through notification and containment, without relying on memory
• The internal escalation followed the written plan, and there’s a record showing it did
• Remediation is evidenced, not just described
• Lessons learned informed changes, and those changes can be demonstrated

The OCC Cybersecurity Supervision Work Program structures examiner review around risk management governance rather than control checklists. That shifts the examination weight toward documentation quality and decision-trail consistency.

Building the Documentation Before You Need It

The time to organize your incident response documentation is not after an incident. It’s before the next one.

Here’s what should be ready to produce on a short turnaround:

The Incident Response & Breach Notification Kit includes a pre-built incident documentation package: an incident classification decision record, a multi-regulator notification log, an incident timeline template, and a post-incident lessons learned worksheet—designed for the documentation demands that appear after the 36-hour clock stops.

Related posts: The Incident Response Decision Log: Documenting the Notification Clock, Post-Incident Lessons Learned: Closing the Loop on Control Changes, and FTC Safeguards Rule: The 30-Day Breach Notification Clock Non-Banking Financial Institutions Keep Missing.

So What?

The 36-hour notification is not the finish line. For most institutions, it’s the first communication in what becomes a regulatory documentation review. The quality of that documentation—classification rationale, timeline, escalation trail, remediation evidence, lessons learned—determines whether that review ends quickly or becomes an examination finding.

The most common outcome for institutions with strong documentation: the examiner acknowledges the notification, may ask a few clarifying questions, and closes out the matter. For institutions with documentation gaps: the post-notification review becomes the opening chapter of a longer regulatory conversation.

You don’t have to wait for an incident to know which category your program falls in. The documentation gaps listed here are identifiable from a table-top walkthrough of your last incident response test. Find them before the examiner does.

External references:

• 12 CFR Part 53 — Computer-Security Incident Notification Requirements
• OCC Notification of Major Security Incident to Congress, April 2025
• OCC Cybersecurity and Financial System Resilience Report 2025
• OCC Cybersecurity Supervision Work Program — Tandem
• FFIEC IT Examination Readiness for Financial Institutions — ABT