Before the 36-hour clock: deciding which bank incidents count

The week

On January 12, 2021, the OCC (which supervises national banks), the Federal Reserve and the FDIC published in the Federal Register a joint proposed rule on computer-security incident notification. The agencies had approved it in December 2020, while banks and government agencies across the United States were absorbing the news of the SolarWinds compromise and security teams were working out what it meant for them and for the technology suppliers they depended on. The rule addressed exactly that kind of moment.

The SolarWinds timeline explains the mood. On December 8, 2020, the security firm FireEye disclosed that it had been breached. On December 13 it emerged that attackers had inserted malicious code into updates of SolarWinds’ Orion network management software, which was widely used in government and industry. CISA issued an emergency directive that night ordering federal civilian agencies to disconnect affected Orion products. On January 5, 2021, the FBI, CISA, the Office of the Director of National Intelligence and the NSA said the actor was likely Russian in origin.

The idea was straightforward. When something goes badly wrong with a bank’s technology, its regulator should hear about it quickly rather than weeks later in an examination. The proposal would require a banking organization to notify its primary federal regulator within 36 hours of believing in good faith that a significant computer-security incident had occurred. A computer-security incident is any event that harms, or could harm, the systems or data a bank depends on, whether caused by a cyberattack or something else.

The proposal gave examples of what would count. They included a large-scale distributed denial of service attack that blocked customer access for more than four hours, and a widespread outage at a core banking service provider with no clear recovery time. A failed system upgrade causing widespread outages qualified. So did ransomware that encrypted a core banking system or its backups. The agencies estimated about 150 such incidents a year and asked for comment on that figure. Comments were due by April 12, 2021.

The agencies also explained why existing channels were not enough. Suspicious activity reports serve a different purpose and allow up to 30 days, too slow for an early warning. The agencies considered treating a SAR filing as notice and rejected the idea because it would delay notification.

The proposal also reached beyond the banks themselves. Many banks, especially smaller ones, run on technology provided by other companies: core processors that keep the accounts, digital banking firms that run the app, payment processors and cloud providers. The proposal said these bank service providers would have to notify their bank customers promptly about incidents that could materially disrupt services. That mattered because a bank cannot report what it does not know.

As proposed, the provider standard was strict. A provider would notify at least two people at each affected bank immediately after experiencing an incident it believed in good faith could disrupt services for four or more hours. Coverage on the bank side followed each agency’s charter map. For the OCC, that meant national banks and federal savings associations. For the Federal Reserve, it meant bank holding companies, savings and loan holding companies, state member banks and the US operations of foreign banks. For the FDIC, it meant insured state nonmember banks and state savings associations. Credit unions, supervised by the NCUA, were outside it.

The agencies finalized the rule in November 2021. They kept the 36-hour window, measured from the bank’s determination that a notification incident has occurred, and set a compliance date of May 1, 2022.

Between proposal and final rule, the agencies narrowed several points. The final definition of a computer-security incident turned on actual harm to a system or its information, dropping language about potential harm and violations of security policies. Providers were to notify “as soon as possible” rather than “immediately.” The duty arose only once a provider determined that an incident had materially disrupted or degraded covered services, or was reasonably likely to, for four or more hours.

On the surface, it was a rule about a deadline. Underneath, it raised harder questions that most banks had never answered in writing: who decides that an incident is serious enough to count, on what basis, and how fast word reaches them from the vendors that run much of the bank.

Banks were not new to incident reporting. Suspicious activity reports, state breach laws and, for New York-regulated institutions, the state cybersecurity regulation’s 72-hour notice already applied. The federal proposal was different in two ways. It focused on operational disruption rather than data exposure, and it reached into the vendor relationship.

Most earlier rules turned on whether customer data had been exposed. This one turned on whether the bank could still do its job. A ransomware attack that freezes the systems customers use to reach their money may not expose a single record, yet it can do more immediate harm than a data leak. The new rule treated that kind of disruption as something regulators needed to hear about fast.

That created three separate problems for banks: classifying the event, hearing from vendors in time, and reconciling the federal clock with every other one. All three follow from how a bank’s technology is put together.

The bank runs on other people’s systems

At the heart of every bank is a core banking system. It is the master ledger: it holds every account, every balance and every transaction, and it posts deposits, withdrawals and interest. If the core is down, the bank cannot reliably say how much money anyone has.

Around the core sit many other systems. Online and mobile banking is the window customers use to see and move their money. Payment systems connect the bank to card networks and to the services that move money between banks. Lending systems handle loan applications and repayments. Each of these talks to the core, often many times a second.

Very few banks, outside the largest, build and run all of this themselves. Most community and regional banks rent their core from a small number of specialist companies called core processors, and buy their digital banking, card processing and other services from further vendors. Many now also use cloud platforms, which means renting computing power and storage in someone else’s data centers rather than running their own. The bank resembles a restaurant that leases its kitchen equipment, buys its bread from a bakery and uses a delivery app: it is responsible for the meal, but much of what makes the meal possible belongs to others.

This arrangement is efficient. It also means that when a core processor or digital banking provider has a serious problem, many banks feel it at once, and none of them controls the fix. Every part of the notification rule was written against that background.

Why concentration changes the problem

When a widely used provider fails, many banks experience the same event at once. Each bank sees only its own slice. The regulators, receiving notices from many banks within hours, can see the whole pattern. That aggregate view was part of what the agencies wanted after SolarWinds: early sight of a problem spreading through shared suppliers, before examinations or press reports caught up.

The agencies already examined the largest technology service providers directly, under the Bank Service Company Act, and client banks can request those examination reports. An examination report describes a provider’s controls at a point in time. It cannot tell a bank that the provider is down this morning. The notification rule filled that gap with a live channel.

Who is covered, and who is not

The rule follows the bank charter map, which makes coverage less obvious than it sounds. A national bank answers to the OCC, a state member bank to the Federal Reserve, and a state nonmember bank to the FDIC. A bank holding company also owes notice to the Federal Reserve. A group with a bank subsidiary and a holding company may therefore have two notices to send for one incident, each to a different agency.

Other financial firms sat outside the rule entirely. Credit unions had no federal equivalent until the NCUA’s own rule in 2023. Broker-dealers and investment advisers report to the SEC and FINRA under different regimes, which in 2021 had no equivalent of the 36-hour notice. A financial group with a bank, a broker-dealer and an advisory business could face three different notification standards for the same outage on shared infrastructure.

Size changes the question as well. For a community bank, the test that matters most is whether a material portion of its customers lost access to services. For the largest banks, the rule also reaches core business lines and critical operations, terms borrowed from resolution planning, whose disruption could matter to the financial system. Those banks typically had the mapping already. Community banks often had to build it.

Classifying the event

The final rule defines a notification incident by its effect. It is a computer-security incident that has materially disrupted or degraded, or is reasonably likely to, a bank’s ability to operate or deliver services to a material portion of its customers. Disruption to business lines or operations whose failure would matter more widely also qualifies. The 36 hours run from the bank’s determination rather than from the first alert.

That design avoids a flood of notices about routine events. Banks deal with attempted attacks, failed logins and minor outages every day; regulators did not want to hear about each one. It also puts weight on a decision many banks had never formalized: who makes the determination, on what criteria, and how the timing is recorded so an examiner can later see it was not delayed to manage the clock.

The timing point is subtle but important. Because the clock starts at the determination, a bank could in theory delay deciding in order to delay reporting. Regulators know this. A bank that cannot show when and why it decided is exposed to the suspicion that it waited.

Banks that handled the rule well wrote down the answers in advance:

• A named decision-maker and deputy, usually in operational risk or the chief information security officer’s office, with authority to decide without convening a committee.
• Criteria tied to critical services. The bank defines which services matter, such as payments, deposit access, lending and online banking, and what level of outage for each counts as material.
• A decision log. The incident record captures when the determination was made, by whom, on what facts, and why earlier facts did not meet the threshold.

The criteria force a question that predates the rule: which services are critical, and what counts as a material portion of customers. Institutions that had mapped critical business services for operational resilience could answer quickly. Others found the notification rule required that mapping anyway. “Operational resilience” is the discipline of keeping the most important services running, or restoring them quickly, whatever goes wrong; mapping critical services is its first step.

What counts as a computer-security incident

The final definition requires actual harm to the confidentiality, integrity or availability of a system or its information. It does not require an attacker. A botched software release that takes down online banking is a computer-security incident under that definition, and so is a hardware failure that corrupts data. The proposal’s own examples included a failed system upgrade.

That matters because many banks run two separate processes. The IT service desk handles outages through a major incident process, and the security operations center handles attacks through a security incident process. The notification rule straddles both. A determination process fed only by the security team will miss the outages, and the outages are often where material disruption first appears.

The fix is structural. Both processes route any incident touching a critical service to the same decision-maker, with the same criteria. The major incident manager’s checklist includes one line: does this affect a critical service, and if so, has the notification decision-maker been told? The security team’s playbook has the same line.

Writing thresholds that work at 3 a.m.

Thresholds have to be usable by a tired person with partial facts. Vague phrases such as “significant impact” invite debate. Workable thresholds combine three elements: the service, the share of customers or transactions affected, and the expected duration. A bank might decide, for illustration, that mobile banking unavailable to most users for more than a few hours is material. It might treat a payment channel failing for a large share of transactions as material sooner.

Two refinements help. First, “reasonably likely” means the decision can be made on a forecast; if the vendor cannot say when service will return, the duration test may already be met. Second, thresholds should reflect customer alternatives. A bank whose small business customers depend on same-day payments has less tolerance than one whose customers can visit a branch.

The thresholds also need an owner and a review date. Services change, customer behavior shifts toward digital channels, and a threshold written for a branch-heavy bank may understate the impact of a mobile outage a few years later. An annual review, tied to the business impact analysis, keeps them current.

The trade-off runs both ways. A bank that sets thresholds low will notify often, which costs little because the notice is short and informal. A bank that sets them high risks being asked why it waited. Most found that erring toward early notice was the cheaper mistake, because regulators had made clear the first notice was meant to be brief.

A committee has one advantage over a single decision-maker: shared accountability for a judgment call. Some banks prefer it for that reason. The cost is time, especially at night or on weekends, when assembling a quorum can consume much of the window. A workable compromise is to let the named person decide alone and have a small group ratify or revisit the decision at the next checkpoint. The log shows both steps.

Hearing from vendors in time

The second requirement applies to service providers covered by the Bank Service Company Act, the law that lets regulators oversee companies providing certain services to banks. Under the final rule, a provider must notify each affected bank customer as soon as possible after it determines that an incident has materially disrupted or degraded covered services, or is reasonably likely to, for four or more hours.

This mattered because so much bank technology runs at core processors, digital banking providers, payment processors and cloud platforms. A bank cannot classify an incident it does not know about. The rule gave banks a regulatory basis for a demand that had been hard to enforce through contracts alone: tell us promptly, through a channel we will actually see.

Who counts as a bank service provider

The rule reaches providers performing services covered by the Bank Service Company Act. Those include core processing, recordkeeping and other data processing for banks. Whether a particular fintech, cloud platform or software company is covered depends on the services it performs, and the answer is not always obvious. A bank should settle the question for each critical provider in the contract, rather than rely on the provider’s own reading.

The final rule also put a task on the bank. Providers notify a bank-designated point of contact. If the bank has not designated one, the notice goes to the chief executive and chief information officer, or two people of comparable responsibility. A bank that never designated a monitored contact has, in effect, chosen two executives’ inboxes as its early warning system. Scheduled maintenance, testing and software updates communicated in advance are excluded.

The rule does not reach the provider’s own providers. A digital banking firm may run on a cloud platform, use a separate authentication service and rely on a data center operator. If one of those fails, the bank hears only if its direct provider passes the word on. Contracts can require that flow-down, with the provider’s notice clock running from when it learns of the problem at its own supplier.

The work fell to vendor management, and it was more detailed than adding a clause. Banks had to identify which providers were covered and confirm who at each would send notices. The notices then had to reach the people making the classification decision rather than a shared mailbox read the next morning.

A useful test is to ask each critical provider to send a test notice, then measure how long it takes to reach the decision-maker. Suppose a community bank runs this test for the first time. Its core processor sends the notice at 4 p.m. on a Friday to an email address listed in a contract signed years earlier. That address belongs to an employee who has since left; the message lands in an unmonitored inbox. Nobody at the bank sees it until Monday. In a real incident, that is most of the 36 hours gone before the bank even knows to start thinking. Contract renewals are the moment to align notice terms with the rule and to require that contacts be tested as well as listed.

Vendor notices also change the classification problem. A four-hour outage at a core processor may hit dozens of banks at once. Each bank must make its own determination, and each may reach a different answer depending on its customers and alternatives. A bank whose customers mostly bank in branches may judge a digital outage differently from one whose customers live in the app. A bank that has thought through its vendor outage scenarios in advance decides faster.

Contract terms that make the rule work

The rule sets a floor. Contracts can make it operational. Terms worth negotiating at renewal include the following.

• A bank-designated primary and alternate contact, reachable around the clock, by phone as well as email.
• A minimum content for the first notice: affected services, start time, expected duration if known, and a contact at the provider.
• An update cadence until service is restored, and a written root cause report afterward.
• Flow-down, so the provider must pass on incidents at its own critical suppliers.
• An annual test notice, with the provider’s cooperation in measuring delivery time.
• Cooperation with the bank’s regulators if they ask about the incident.

Large providers often resist bespoke terms and offer standard notification language instead. A bank with little negotiating power can still test the channel, record the result and escalate through the provider’s account team when it fails.

Community banks, credit unions and large banks approach this work differently. A community bank may have one core processor that supplies most of its critical services, so a single tested channel covers much of the risk. A large bank may have hundreds of covered providers, and the work becomes a program: tiering providers by criticality, testing the top tier regularly and sampling the rest. The principle is the same; the scale changes the method.

A bad Thursday, hour by hour

The pieces fit together most clearly in a single incident. Say a regional bank has a bad Thursday. The bank runs its core on a large processor, uses a separate company for its mobile app, and has its own card program.

6:40 a.m. The bank’s overnight monitoring shows that some customers cannot log in to the mobile app. The on-call engineer opens an incident record. At this stage it looks like a glitch.

7:30 a.m. The digital banking provider emails a notice to the bank’s tested incident address: it is investigating suspicious activity on its platform and has taken some services offline as a precaution. Because the bank tested this channel at its last contract renewal, the notice reaches the duty decision-maker’s phone within minutes.

8:15 a.m. The decision-maker, the head of operational risk, reviews the facts against the bank’s written criteria. Mobile banking is listed as a critical service. The bank’s threshold says that an outage affecting most mobile users that is expected to last beyond a set number of hours is material. The provider cannot yet say when service will return. She logs her reasoning: material disruption is reasonably likely, so this is a notification incident. The time is recorded. The 36 hours start now.

9:00 a.m. A short notice goes to the bank’s primary federal regulator: what is known, what is not, and who to contact. It takes a few paragraphs. Nobody waits for the full picture, because the rule does not ask for one.

9:30 a.m. The incident lead opens the decision matrix. Nobody yet knows whether customer data is involved, so the breach notice row is marked “watch” with an owner. Cards are not affected, so the card network row is marked “not triggered,” with a time and initials. The bank is listed, so the securities disclosure row goes to the general counsel to assess materiality on its own track.

Afternoon. The branch network and call center are briefed to help customers who cannot use the app. The board chair receives a short update. The matrix is reviewed again at each scheduled checkpoint.

The next morning. The provider restores service overnight and sends a short update. The bank tells its regulator that service is back and that the provider’s investigation continues. The rule requires no formal follow-up report, but a supervisor will expect to hear how the incident ended and will ask questions at the next examination.

The following weeks. The bank asks the provider for its root cause analysis and for evidence that the weakness has been fixed. It runs an after-action review covering what worked, what was slow and what the thresholds missed. Customer complaints from the outage are reviewed for anyone who suffered fees or losses. The vendor’s performance is recorded for the next contract renewal.

The morning requires no heroics. Every step depends on something decided weeks or months earlier: which services are critical, who decides, what the threshold is, which vendor address is tested, what the matrix contains. On the day, the team is simply following a path it already laid down. Without that preparation, the same morning would have been spent discovering the vendor’s email in a dead inbox, arguing in a conference room about whether the outage was “material,” and wondering which other rules applied.

The same Thursday at a credit union

Change one fact. The institution is a federally insured credit union, and its mobile app runs on a credit union service organization’s platform. In 2021 the banking agencies’ rule did not apply. Since September 2023, the NCUA’s rule has: the credit union must notify the NCUA within 72 hours of reasonably believing it has had a reportable cyber incident.

The trigger and the clock differ, but the preparation is the same. Someone has to decide, on written criteria, whether the outage is reportable. The service organization’s notice has to reach that person quickly. The longer clock gives more room, and credit unions that share a service organization may all be deciding at once. The NCUA, like the banking agencies, gains a view across many institutions from those simultaneous reports.

Reconciling the clocks

The federal rule did not replace other obligations. One incident at a New York state-chartered bank could trigger the federal 36-hour notice and the state’s 72-hour notice. It could also require state breach notices if personal data were involved, card network reporting and suspicious activity reporting. Later, listed banks also had to consider the SEC’s 2023 requirement to disclose material cybersecurity incidents within four business days of a materiality determination.

Each regime has its own definitions, triggers and recipients. Treating each as a separate procedure invites a missed notice in the confusion of a live incident. During a serious incident, the same small group of people is trying to restore systems, talk to customers, brief the board and handle the press. Asking them to remember five different rulebooks from memory is asking for trouble.

How the clocks differ

The regimes differ in what starts the clock as much as in its length. That difference is the main source of missed notices.

• Federal banking agencies: 36 hours from the bank’s determination that a notification incident has occurred, to the primary federal regulator.
• New York DFS: 72 hours from the determination that a reportable cybersecurity incident has occurred; since the 2023 amendments, extortion payments must also be reported within 24 hours. This applies to institutions licensed by the department.
• NCUA: 72 hours from a credit union’s reasonable belief that a reportable cyber incident has occurred, since September 2023.
• SEC Form 8-K: four business days from a public company’s determination that an incident is material, since December 2023.
• State breach laws: notice to residents, and sometimes to state officials, when personal information is involved, on timelines that vary by state.
• Suspicious activity reports: generally 30 days from initial detection of facts that may support a filing.

Determination, reasonable belief, materiality and detection are different moments, often hours or days apart. The matrix should record each start time separately, with the facts that triggered it. A team that writes down one “incident start time” will calculate at least one deadline wrongly.

Who owns the matrix

The matrix needs an owner outside the incident. Compliance usually maintains it, updating rows when rules change and recording the version in use. Legal confirms which rows apply to the institution’s charters, listings and licenses. During an incident, the incident commander or a deputy runs it, and the general counsel’s office signs off on the rows with legal judgment in them, such as securities materiality.

Exercises should use the matrix as written. A tabletop exercise that reaches the matrix and finds a stale row, such as a regulator contact that has changed, has done its job. The fix goes into the next version, and the version history becomes evidence that the bank maintains its obligations.

Card network obligations come from contracts rather than statute, and banks with European operations face the EU’s Digital Operational Resilience Act from January 2025, with an initial notice for major incidents within hours. A bank’s counsel should confirm which rows belong in its own matrix.

A single incident record with a decision matrix works better. It lists every potential obligation, its trigger, its deadline and its owner, and the team reviews it at set points during the response. In practice the matrix looks like a simple table. It has one row for the federal banking regulator, one for the state, one for each relevant card network, one for breach notices and one for securities disclosure. Columns show whether each has been triggered, the deadline and who sends it. How the triggers interact for a given bank depends on its charter and listing status, which is a question for its lawyers.

The first conversation with the supervisor

Regulators. The 36-hour notice is often the first conversation a bank has with its supervisor about a crisis. A clear, timely notice builds trust. A late one, or one the bank cannot explain, starts the relationship on the wrong foot just when goodwill matters most.

Customers. The rule’s focus on disruption is a focus on customers who cannot pay bills, access deposits or receive wages. A bank that knows its critical services and thresholds is also a bank that knows which customers to call first.

Customer communication follows the same logic as the regulator notice. Holding statements for the website, the app, branches and the call center can be drafted in advance for the main scenarios, such as a core outage, a digital banking outage or a card outage. On the day, the team fills in the facts. Customers who were charged fees or missed payments because of the outage need a process for refunds and corrections, and frontline staff need to know it exists.

Small business customers deserve separate attention. Payroll, supplier payments and card acceptance depend on the bank’s systems, and a day’s outage can cascade into their own customers and employees. Relationship managers who know which clients run payroll that day can call them before the clients call the bank.

Vendors and cost. Contracts with core processors and other providers are among the most important a bank signs. Notice terms, tested contacts and agreed scenarios belong in those contracts, and renewals are the cheapest moment to get them right.

Reputation. In a shared-vendor outage, several banks are in the news at once. The ones that communicate early and accurately tend to come out better than the ones that appear surprised.

What the first notice should say

The first notice is short by design, but its content still matters. A useful template covers what happened as currently understood, which services and customers are affected, and whether a provider is involved. It adds what the bank is doing, when it expects to know more, and who the supervisor should call. It avoids speculation about the attacker or the cause. It states clearly what is not yet known.

Counsel should approve the template in advance, so the duty decision-maker does not wait for legal review on the day. For a listed bank, the notice to the regulator and any public statement need to be consistent, even though they serve different purposes and follow different tests. Agreeing the template with the disclosure team ahead of time removes one source of delay.

The case for waiting

Some executives argue that early notice with incomplete facts is risky. A first notice may turn out to be wrong. Regulators may react to an incident that proves minor, and a stream of early notices could make a bank look less well run than its peers.

The argument has some force where thresholds are set so low that every hiccup becomes a notice. It does not justify waiting on a genuine material disruption. The rule asks for good faith and speed, not accuracy to the last detail. A notice that says “we do not yet know” is still compliant. A notice that arrives after the deadline, with a decision log that shows the bank knew earlier, is the outcome that damages trust.

Habits of the prepared bank

Banks that are well prepared share a recognizable set of habits.

• One named person, with a deputy, decides whether an incident counts, and is empowered to decide alone.
• Critical services and their materiality thresholds are written down before anything goes wrong.
• Every determination is logged with its time, facts and reasoning.
• Critical vendors have tested notice contacts, and the bank knows how long a notice takes to reach the decision-maker.
• All reporting obligations run from one incident record and one matrix.
• The team rehearses a shared-vendor outage as well as an attack on the bank itself.

The unprepared ones slip along the same lines.

• Leaving the determination to a committee that has to be assembled first.
• Defining “material” only after an incident is under way.
• Listing vendor contacts in contracts but never testing them.
• Routing vendor notices to a shared mailbox nobody watches out of hours.
• Running each reporting regime as a separate procedure with a separate owner.
• Waiting for certainty before notifying, when the first notice was designed to be brief and early.

A few measures show whether the habits are real. The first is the time from a provider’s test notice to the decision-maker’s acknowledgment. The second is the time from first alert to determination in each real incident and exercise. The others are the share of critical providers with a contact tested in the past year and the number of exercises run against shared-vendor scenarios. Each has an owner, and each goes to the operational risk committee.

Ownership of the decision differs by institution. At a community bank, the decision-maker may be the chief operating officer or even the chief executive, with the information security officer as deputy. At a large bank, it usually rests with a designated role in the chief information security officer’s office or operational risk, backed by a 24-hour rota. Either works if the person is reachable, trained and empowered to decide alone.

Before the 36-hour clock starts

1. Who decides whether an incident is a notification incident, who is their deputy, and can either decide without calling a meeting?
2. Which of our services are critical, and what level of outage in each counts as material?
3. When did each critical vendor last send us a test notice, and how long did it take to reach the decision-maker?
4. If our core processor went down for four hours on a Friday evening, what would happen, minute by minute?
5. Do we have one incident record that lists every notice we might owe, with deadlines and owners?

These questions are about decisions, owners, contracts and rehearsal, which is exactly where an executive’s attention adds the most. A bank that can answer these quickly has done most of the hard work.

With hindsight

The rule took effect in 2022 without significant disruption. Because the 36-hour notice is short and informal by design, it signals that something is wrong without requiring a full report, which has kept it workable in severe events. Regulators get early warning; banks are not forced to write a polished account while the incident is still unfolding. That balance has proved sensible.

The rule also became a reference point for later rules. When the NCUA approved its own reporting rule in February 2023, it said the rule aligned credit union requirements with those of the federal banking agencies and with the 2022 critical infrastructure reporting law. The early, short notice of disruption, separate from fuller reports later, had become the model.

The vendor provision mattered in the incidents that followed. Ransomware and outages at technology providers serving many community banks and credit unions disrupted several institutions at once. These were exactly the shared-vendor scenarios the rule anticipated, and they showed why a bank needs to hear from its providers through a channel someone is actually watching.

Two episodes illustrate the pattern. In late 2023, ransomware at a cloud services provider owned by a credit union technology company disrupted dozens of credit unions at once, according to the NCUA. In 2024, a breach at Evolve Bank & Trust, a bank serving many fintech partners, showed the same dependency running the other way: fintech customers learned of an incident through a bank they had never chosen directly.

The July 2024 CrowdStrike outage tested the definition from another angle. A faulty software update, with no attacker involved, crashed Windows systems at many organizations worldwide, including financial institutions. The final rule’s focus on actual harm to availability, rather than on malice, meant that banks had to judge such an event on its effects. Those whose determination process listened only to the security team had a gap.

Other regulators kept adding rules of their own. Credit unions are not covered by this rule; the NCUA adopted its own 72-hour reporting requirement, effective in September 2023. The SEC’s incident disclosure requirement, adopted that July, took effect in December 2023. CISA proposed its rule under the 2022 critical infrastructure reporting law in April 2024, with 72-hour incident and 24-hour ransom payment reporting, and targeted September 2026 for the final rule. For a listed financial institution, that means several clocks may be running at once, each with its own trigger. The single incident record and decision matrix described above become more valuable with every clock added.

Third-party expectations tightened too. The banking agencies’ June 2023 interagency guidance on third-party relationships listed incident reporting among the terms to address in contracts. The SEC’s 2024 amendments to Regulation S-P required broker-dealers, investment advisers and other covered firms to notify affected customers of certain data breaches within 30 days. Those firms must also require their service providers to notify them within 72 hours. The vendor channel the banking rule pioneered has become a standard expectation across finance.

What has not happened is harmonization. Each new regime brought its own trigger, recipient and clock, and one event can now require several notices. Proposals to let a single report satisfy several agencies have been discussed for years without displacing the separate requirements. Institutions have had to do the harmonizing themselves, in their own incident records.

Across finance and beyond, regulators have converged on fast, early notice of disruption, separate from slower breach and disclosure processes. Institutions that run notification as one capability with one incident record handle the overlap best. Notification is less a legal task performed at the end of an incident than a decision made early, by a named person, on criteria agreed in advance, fed by information from vendors that arrives in time. Getting those pieces right is ordinary preparation, and it is far easier on an ordinary Tuesday than in the middle of a crisis.