The Incident Packet Should Start the Notification Clock

A practical weekly article for community bank and credit union boards and senior leaders on cyber incident governance, focused on regulatory notification clocks, provider disrup...

Some board packets treat a cyber incident like a technical mystery novel.

First comes the timeline. Then the likely root cause. Then the vendor update. Then a few screenshots from systems nobody on the board uses.

Useful? Sometimes.

Enough? Not anymore.

For community banks and credit unions, the first board-level question after a material technology incident should not be, "Do we know exactly what happened?"

The better first question is, "Which clocks started, who owns them, and what evidence are we preserving?"

The clock starts before the story is clean

Regulators do not wait for clean root-cause narratives.

For banking organizations supervised by the FDIC, Federal Reserve, or OCC, the federal computer-security incident notification rule requires notification to the primary federal regulator as soon as possible and no later than 36 hours after determining that a notification incident has occurred. The rule is not asking for a finished forensic report. It is asking the institution to recognize when a serious disruption has crossed the line into a reportable event. Source: Federal Register, Computer-Security Incident Notification Requirements for Banking Organizations and Their Bank Service Providers: https://www.federalregister.gov/documents/2021/11/23/2021-25510/computer-security-incident-notification-requirements-for-banking-organizations-and-their-bank

Credit unions have a different clock. NCUA requires federally insured credit unions to notify the agency as soon as possible and no later than 72 hours after reasonably believing a reportable cyber incident has occurred. Source: NCUA, Cyber Incident Notification Requirements: https://www.ncua.gov/regulation-supervision/letters-credit-unions-other-guidance/cyber-incident-notification-requirements

Those are not trivia points for compliance staff.

They are governance design requirements.

If the incident response plan does not define who can determine that the threshold has been met, who notifies the regulator, who briefs the board, and what evidence gets preserved, then the institution is asking tired people to invent governance while the clock is running.

It is also an unfair thing to do to good employees.

Example 1: The service provider problem

The federal banking rule also covers bank service providers. A bank service provider must notify at least one bank-designated point of contact at each affected banking organization as soon as possible when the provider determines it has experienced a computer-security incident that has materially disrupted or degraded covered services for four or more hours. Source: Federal Register rule cited above.

That matters because many community institutions do not operate their digital delivery stack alone.

Core processing, online banking, mobile banking, card processing, bill pay, ACH processing, call center platforms, cloud hosting, managed security tools, email filtering, loan origination, document imaging, and customer communication tools may all involve third parties.

So the board packet should not simply say, "Vendor incident under investigation."

That tells the board almost nothing.

A better packet should show:

1. Which business services depend on the affected provider. 2. Which customer or member functions are degraded. 3. Whether the provider has triggered its own notification obligation. 4. Who at the institution owns the response. 5. Whether regulator, customer, insurer, or contractual notices might be implicated.

This is where governance gets very practical.

A vendor incident is not automatically your reportable incident. But it can become your operational disruption, customer communication problem, exam question, and board oversight issue very quickly.

The board does not need packet filler. It needs a dependency map and a decision log.

Example 2: Ransomware guidance is really governance guidance

CISA's StopRansomware guidance tells organizations to maintain offline encrypted backups, test restoration, secure remote access, use multifactor authentication, keep systems patched, and prepare communications before a ransomware event. Source: CISA StopRansomware Guide: https://www.cisa.gov/stopransomware/ransomware-guide

Those are security controls.

They are also board evidence.

When a ransomware event happens, the question is not just, "Did IT have backups?"

The real board questions are more specific:

Can we restore the systems that support cash movement, member service, loan operations, branch work, wires, ACH, debit cards, call center routing, and online banking?

Have we tested that restoration in the order the business would actually need it?

Who approved the degraded operating mode?

What transactions stop, what transactions continue, and who can make exceptions?

What do we tell customers or members when the facts are still incomplete?

That last sentence matters. Incident communication is usually messy because reality is messy. The first update is rarely perfect. The second may correct the first. The third may make everyone wish they had written the first two more carefully.

This is why the board packet should separate facts, assumptions, decisions, and open questions. Put them in different sections. Do not mush them into a heroic paragraph that sounds confident but hides uncertainty.

Confidence is nice. Traceability is better.

Example 3: Notification failure can become the story

NCUA's rule is useful because it gives credit union leaders a plain governance reminder: the notification obligation is tied to reasonable belief, not total certainty. Source: NCUA Cyber Incident Notification Requirements, cited above.

That distinction matters in the real world.

Wait for every forensic detail and the institution may miss the governance window. Notify without a threshold process and leaders create noise. The answer is a decision process that can operate under uncertainty.

A good incident packet should show the board how management is making the call.

For example:

• Current known facts.
• Systems, services, or data believed to be affected.
• Customer or member impact known so far.
• Operational degradation and duration.
• Regulatory thresholds considered.
• Counsel, regulator, insurer, law enforcement, and vendor contacts made or pending.
• Open questions and next update time.

That is not bureaucracy. That is a shared operating picture.

The goal is not to bury the board in incident command detail. The goal is to prevent the board from receiving a polished update that skips decisions management had to make.

What the board should expect before the next incident

This is a board packet problem before it becomes a breach problem.

Before the next cyber tabletop, insurance renewal, exam prep session, or technology committee meeting, management should be able to show three things.

First, a notification matrix.

Not a 40-page plan nobody reads. A practical matrix that names the trigger, clock, owner, backup owner, approval path, evidence source, and communication channel for regulators, law enforcement, insurer, core provider, critical vendors, customers, members, and the board.

Second, a dependency map.

A simple map showing which critical services rely on which systems and providers. If online banking is down, what else is affected? If email is unavailable, how does the incident team communicate?

Third, a decision log.

During an incident, people will make judgment calls with incomplete information. That is not failure. That is leadership. But those calls need to be captured: who decided, based on what evidence, with what tradeoff, and when the decision will be revisited.

I have sat in enough technology conversations to know that smart people often assume this will be obvious in the moment.

It will not be obvious in the moment.

The moment will be noisy. A vendor will be late. A system owner will be deciding whether a dashboard is lying or just delayed. Legal will want cleaner facts. Operations will want an answer right now. The board will want assurance without being fed theater.

This is exactly why governance has to be designed before the adrenaline shows up.

The packet I would rather read

If I were reviewing a serious incident packet with a community bank or credit union board, I would rather see five blunt pages than thirty polished ones.

Page one: what happened, what we know, what we do not know.

Page two: which clocks started, which thresholds were evaluated, who owns each notice.

Page three: customer, member, and operational impact by critical service.

Page four: vendor dependencies, open requests, escalation status, and contractual notice issues.

Page five: decisions made, decisions pending, evidence preserved, and next board update.

That packet does not make the incident smaller.

It makes leadership clearer.

And that is the point. Boards do not need to become forensic analysts. They do need to govern the institution's response when technology risk turns into operational reality.

A notification clock is not just a compliance timer. It is a test of whether the institution knows who decides, who acts, who communicates, and who can prove it later.

Board and executive discussion questions

1. If a critical technology provider notified us of a material disruption today, who would receive that notice, who would evaluate our regulatory clock, and how would the board know the decision was made?

2. Does our incident packet clearly separate known facts, assumptions, decisions, open questions, and next update times, or does it blend them into a narrative that sounds cleaner than reality?

3. Which critical service would create the most confusion if it failed for four hours, and have we tested the notification, vendor escalation, and customer communication path for that specific scenario?