Your core system goes down at 10:02 a.m. Members can’t access accounts. Branch staff are staring at frozen screens. Your IT lead is knee-deep in logs.
Quick. Who:
Calls the NCUA?
Contacts cyber insurance?
Tells members what’s happening
Decides whether to shut anything else down?
If you hesitated on any of those, your incident response plan isn’t really a plan. It’s a document that, figuratively, collects dust. Downtime doesn’t just expose your systems. It exposes your coordination.
You definitely have a plan, and it’s probably long. It passed your last exam. But here’s the real question: When was the last time your leadership team actually ran it?
Most credit unions don’t rehearse their plan under pressure. So, when things break, the gaps show up fast. This usually looks like:
IT trying to fix everything and answer everyone
Leadership is waiting for clarity that never comes
No one actually owns the communication
The clock is ticking on reporting requirements
Let’s be honest, the plan isn’t failing because it’s wrong. It’s failing because no one practiced it. When downtime costs companies in the financial services industry $152 million each year, it is of the utmost importance to actually practice your plans.
Your documented RTO looks reasonable. When was the last time you proved it?
This doesn’t mean just testing a backup. A real test involves restoring core systems, validating access, reconnecting dependencies, and getting users working again.
Unfortunately, most people haven’t done this. And when an incident hits, that “4-hour recovery” quietly turns into:
12 hours of scrambling
24 hours of partial functionality
Days of cleanup
Meanwhile, members are locked out, and your call center is drowning. Most backup strategies have never survived contact with a real outage.
You rely on your core provider, telecom vendor, and cloud platform. When they go down, you inherit the outage.
You’ve probably seen it play out this way already:
These aren’t just systems. They are dependencies on top of other dependencies. Unfortunately, you won’t find them in your documentation. You’ll find them when everything breaks at once.
Members don’t necessarily care if it’s ransomware, power, or a vendor outage. They care that they can’t withdraw money, their payment didn’t go through, and no one is telling them what’s happening.
One poorly handled outage can undo years of trust. Honestly, put yourself in a member’s shoes. If you were trying to access your money and weren’t able to, and no one said anything about it, wouldn’t you be upset?
Ultimately, you don’t need a better document. You need operational readiness. The good news is that you can start working on improvements right away.
Here’s where you can begin:
The first time you do this. It might be uncomfortable, but that’s the point.
Take one scenario, such as: “The core system is down. You don’t know why. Members are calling. Go.”
There doesn’t need to be any slides or prep. Just decisions. Because when a real incident hits, you won’t have time to figure it out.