Beyond the 36-Hour Rule: Real-World Examples You Might Not Know About

Most community financial institutions are well aware of the 36-hour incident notification rule that went into effect in April 2022. But what’s not always top of mind, and what deserves a closer look, are the specific examples the regulators provided of what counts as a “notification incident.”

The rule itself is broad by design: any significant incident that materially disrupts your operations, service delivery, or poses a threat to financial stability may require notification to your primary federal regulator (FDIC, OCC, or Federal Reserve). But to help institutions make that call, the final rule includes a non-exhaustive list of examples.

Here is an example that stands out and one you might not have expected:

Core Provider Outages

“A bank service provider that is used by a banking organization for its core banking platform to operate business applications is experiencing widespread system outages, and recovery time is indeterminable.”

This one is big and easy to overlook. Even though the disruption is coming from a third party, your institution is still responsible for notification if the incident materially affects your ability to operate. This means that a major outage from your core provider, especially one with no clear ETA for recovery, could absolutely be a reportable event under the 36-hour rule.

So yes, vendor issues count. And in many cases, they’re just as disruptive as internal incidents. Do you have to notify for every core outage? Not necessarily. The final rule often references the 4-hour timeframe. If your core provider has a system outage lasting over 4 hours with no clear recovery time, it's advisable to notify relevant parties.

Other Examples Worth Knowing

• DDoS Attack: A distributed denial-of-service attack that blocks customer account access for more than 4 hours.
• Failed Upgrade: A system update or change that causes widespread outages for employees and customers.
• Disaster Recovery Activation: An unrecoverable system failure that forces you to activate your BCP or DR plan.
• Extended Hacking Incident: A cybersecurity breach that disables banking operations for an extended time.
• Disruptive Malware: Malware that threatens core business lines or forces you to disconnect critical systems from the internet.
• Ransomware on Core Systems: A ransomware attack that encrypts your core banking system or backup data.

A Few Practical Reminders

• The rule doesn’t require certainty, just a good-faith determination that a reportable incident has occurred.
• If you're unsure, you're encouraged to notify your regulator anyway. False positives won’t trigger penalties.
• Make sure your incident response plan includes notification triggers and clearly documents who’s responsible for making the call.
• And again, don’t underestimate vendor outages. Core providers, internet service disruptions, and key software vendors can absolutely put you in notification territory.

The Bottom Line

You probably already know the rule. But do your incident responders and your executive team know what it looks like in action?

These examples are more than just guidance; they’re a reality check. And the better you understand them, the more confidently (and quickly) you can respond when something goes wrong.

If you require assistance in strengthening your Incident Response Plan to better address notification incidents, please contact Bedel Security to explore how we can help you.