Three Clocks, One Incident: How to Manage the Overlapping Cyber Notification Timelines Under OCC, NYDFS, and SEC Rules

On July 6, 2023, Delta Dental confirmed that data had been exfiltrated from its systems following a MOVEit Transfer vulnerability attack. By that date, the company had determined that a qualifying cybersecurity event had occurred. Under NYDFS Part 500, the 72-hour notification clock to the New York Department of Financial Services started running.

Delta Dental notified NYDFS on December 15, 2023 — 162 days later.

In April 2026, NYDFS imposed a $2.25 million civil penalty. The differentiating factor from the hundreds of organizations hit by the same MOVEit vulnerability wasn’t the breach itself. It was the notification failure.

The incident is a useful illustration of a specific failure mode that plagues financial institutions managing cyber incidents: the assumption that incident response is a single process with a single output, when it’s actually a set of parallel obligations with different clocks running simultaneously from the moment a qualifying event is determined.

TL;DR

• A single cyber incident can simultaneously trigger up to six separate notification obligations: OCC/FDIC/Fed 36-hour rule, NYDFS 72-hour requirement, NYDFS ransomware 24-hour payment notice, SEC 4-business-day materiality disclosure, GLBA 30-day customer notice, FinCEN SAR filing, and bank partner contractual obligations
• The clocks have different triggers — some start at “discovery,” some at “determination,” some at “detection of suspicious activity” — and mixing these up consistently produces late notifications
• NYDFS’s April 2026 enforcement action against Delta Dental ($2.25M) directly resulted from delayed notification: breach confirmed July 6, notified NYDFS December 15 — 162 days late
• The SEC’s OCC 36-hour rule applies to banking organizations; NYDFS Part 500 applies to any NYDFS-licensed entity; the SEC 8-K rule applies only to public companies; GLBA applies to all covered non-banks
• The fix is a notification coordination matrix in your incident response plan that maps each obligation, its clock trigger, its deadline, and its owner — before the incident, not during it

The Six Clocks

No single incident response plan can address these in sequence. They run in parallel, and the fastest clocks don’t wait for the slower ones to start.

Clock 1: OCC/FDIC/Federal Reserve — 36 Hours

The federal banking agencies’ computer-security incident notification rule has been in effect since May 2022. It applies to OCC-supervised national banks and federal savings associations, FDIC-supervised state non-member banks and savings institutions, and Federal Reserve-supervised bank holding companies and state member banks.

Clock trigger: Determining that a “notification incident” has occurred.

What constitutes a notification incident: A computer-security incident that has materially disrupted or degraded — or is reasonably likely to disrupt or degrade — the viability of banking operations; results or is likely to result in customers being unable to access their accounts; or impacts or is reasonably likely to impact the stability of the financial sector.

Timeline: 36 hours from the determination. Not from discovery. Not from forensic confirmation. From the point at which the institution determines the incident meets the notification threshold.

What to file: The notification doesn’t require a full incident description — it’s a notice that an incident has occurred. Details follow in the subsequent examination response. The point is to get the regulator informed quickly.

Bank service provider extension: The rule also covers bank service providers — core processors, cloud vendors, BaaS platforms. If a service provider has experienced a computer-security incident that has materially disrupted or is reasonably likely to materially disrupt covered bank services for four or more hours, it must notify each affected bank customer’s designated point of contact as soon as possible. Fintechs operating as bank service providers should build this notification path into their incident response procedures.

Clock 2: NYDFS Part 500 — 72 Hours

For any entity licensed or chartered by NYDFS — banks, insurers, mortgage companies, fintechs with money transmitter licenses, and others — Part 500 requires notification within 72 hours of determining that a qualifying cybersecurity event has occurred.

Clock trigger: Determining that a cybersecurity event has occurred that has a reasonable likelihood of materially harming any material part of normal operations, or that requires reporting under any applicable law, rule, or regulation.

The second trigger is the cascading trigger: once you’ve determined the event requires notification to any other regulator — including the OCC 36-hour clock — the NYDFS notification obligation is independently activated. These are not sequential. The OCC notification at 36 hours does not trigger a 72-hour NYDFS window starting from that point. The NYDFS clock started running when you determined the qualifying event had occurred.

Special case — ransomware extortion payment: If a covered entity makes any extortion payment in connection with a ransomware attack, it must notify NYDFS within 24 hours of making the payment — separate from and faster than the 72-hour event notification.

The Delta Dental pattern: NYDFS’s April 2026 enforcement action against Delta Dental established the enforcement posture clearly: waiting for forensic investigation to conclude before notifying is not acceptable. The notification obligation triggers at the point of determination that a qualifying event occurred — not at the point where you have complete information about the event. Filing a preliminary notice and supplementing it as the investigation develops is the expected approach.

Clock 3: SEC Form 8-K Item 1.05 — 4 Business Days

The SEC’s cybersecurity disclosure rule applies to SEC-registered public companies only. Most fintechs are private and not directly subject to it. If your firm’s bank partner or sponsor bank is a public company, however, their 8-K obligations may be triggered by incidents originating at the fintech level.

Clock trigger: Determining that an incident is “material.”

What constitutes materiality: A substantial likelihood that a reasonable investor would consider the incident important in making an investment decision. This typically applies to incidents involving significant financial impact, large-scale data breach affecting customers, prolonged operational disruption, or reputational damage with potential financial consequence.

The critical distinction: The clock runs from materiality determination, not from incident discovery. A company that discovers a potential incident must conduct a materiality assessment — and the timing and documentation of that assessment will be examined by the SEC if enforcement follows. As detailed in our Flagstar analysis, the SEC’s enforcement pattern shows the agency will examine whether delayed materiality determinations were reasonable given the facts available at the time.

For private fintechs: The SEC 8-K rule doesn’t apply, but the discipline it requires does. GLBA Safeguards Rule requirements, OCC/FDIC notification requirements, and bank partner contractual expectations use similar documentation standards. Maintaining contemporaneous records of your incident assessment timeline — when you discovered the incident, when you determined its scope, when you determined it was a qualifying event — creates the same evidentiary record that a public company would use to justify its 8-K filing timeline.

Clock 4: GLBA Safeguards Rule — 30 Days

For GLBA-covered non-bank financial institutions (most fintechs), the FTC Safeguards Rule requires notifying affected customers within 30 days if a breach affects 500 or more customers’ nonpublic personal information. The FTC also requires notification of the FTC itself under its supplemental breach reporting rule.

Clock trigger: Discovery of a breach. Unlike the OCC and NYDFS rules, GLBA customer notification is triggered by discovery, not determination. The practical implication: the customer notification clock may start earlier than the regulatory clocks if your team identifies the breach before completing its qualification assessment.

30-day window: Notification must go to affected customers and the FTC (for breaches affecting 500 or more customers) within 30 days of discovery.

Clock 5: FinCEN SAR Filing — 30 to 60 Days

SAR filing obligations apply when a cyber incident involves — or reveals — suspicious financial activity: unauthorized transactions, fraudulent fund transfers, account takeover schemes, or evidence of financial crime conducted through the cyber intrusion.

Clock trigger: Initial detection of facts that may constitute suspicious activity requiring reporting. This is different from the regulatory notification triggers above — it’s the point at which your team identifies that the incident involved conduct that may be reportable as suspicious.

Timeline: 30 calendar days from initial detection of suspicious activity, or up to 60 days if no suspect has been identified at the 30-day mark.

What this means in practice: A ransomware attack that disrupts operations but doesn’t involve unauthorized transactions may not trigger a SAR at all. An account takeover or unauthorized wire transfer discovered during the same incident response process almost certainly does. These are separate determinations, tracked separately.

October 2025 FinCEN FAQs clarified that financial institutions are not required to conduct a separate manual review after filing an initial SAR — automated monitoring and risk-based internal controls satisfy the continuing activity obligation, provided they’re reasonably designed to detect and report ongoing suspicious activity.

Clock 6: Bank Partner Contractual Notification — 24 to 72 Hours Contractual

For fintechs operating under sponsor bank program agreements, the contract typically establishes a notification timeline of 24 to 72 hours from discovery (not determination) of any incident affecting the bank, its customers, or the shared program infrastructure.

These contractual timelines are often the fastest of all the notification obligations — and unlike the regulatory timelines, there’s no common standard. Read your program agreement. Some require immediate verbal notification followed by written notice within 24 hours; some require formal incident reports within 48 hours; some specify escalation paths through specific bank contacts.

The bank partner notification obligation is upstream from the bank’s own OCC 36-hour clock. If a breach at your fintech requires the bank to file an OCC notification at the 36-hour mark, the bank needs your information significantly before that deadline. Build the contractual notification timeline backward from the bank’s regulatory obligation.

The Full Notification Matrix

Where Programs Break Down

Using the Wrong Trigger

Most incident response teams train on “discovery” as the triggering event for all notifications. The OCC 36-hour and NYDFS 72-hour rules both use “determination,” not discovery — and the gap between discovery and determination is where late notifications happen.

The determination trigger does not mean “when forensic investigation is complete.” It means when your team has determined, based on the information available, that the incident meets the qualifying criteria. NYDFS’s enforcement record, reinforced by the Delta Dental action, makes this explicit: preliminary notification plus ongoing updates is the required approach, not full investigation before notification.

Clock Isolation

Incident response teams often work in functional silos — security handles the forensics, legal handles the SEC assessment, compliance handles the NYDFS filing. Each function tracks its own obligation. No one owns the coordination layer.

The consequence: OCC notification happens at hour 35, NYDFS notification happens at day three — both technically on time — but nobody checked whether the NYDFS 72-hour clock actually started at the same moment as the OCC clock, or whether completing the OCC notification activated the NYDFS cascading trigger.

The fix is a single notification coordinator role in your incident response plan — someone whose specific responsibility during a cyber incident is tracking all notification clocks, their triggers, their deadlines, and their status. This isn’t a new headcount; it’s a designated role that a compliance or legal team member takes on during an active incident.

Materiality Assessment Documentation Gaps

For public companies and their fintech partners, the undocumented materiality assessment is the highest-risk disclosure failure. The Flagstar enforcement and the SEC’s October 2024 batch of cases show a consistent pattern: the SEC examines the materiality assessment timeline, and companies that can’t demonstrate a documented, contemporaneous assessment face questions about whether delayed determinations were reasonable or engineered.

Document the materiality assessment from the moment a significant incident is identified. Date every conclusion and the facts that supported it. If you conclude an incident is not material on day three, document why. If you revise that conclusion on day seven, document the new facts.

Missing the SAR Connection

Ransomware incident response typically focuses on operational recovery and regulatory notification. The suspicious activity dimension — whether the incident involved financial crime requiring SAR filing — is handled by a separate BSA/AML team on a separate timeline. These workstreams need a connection point: a step in the IR process where the team’s findings are reviewed against SAR criteria, and the BSA/AML team is formally looped in when the incident involves financial account activity.

Building the Coordination Layer Into Your IR Plan

The solution to managing simultaneous notification clocks is a dedicated notification section in your incident response plan that:

1. Lists every applicable obligation: Your specific notification obligations depend on your regulatory status. An OCC-supervised bank with NYDFS licensure and SEC registration has different obligations than a private fintech with a money transmitter license. Map your applicable obligations before the incident.

2. Defines the trigger for each clock: For each obligation, specify the event that starts the clock — discovery, determination, detection, payment — in plain language your incident response team uses consistently.

3. Assigns a named owner: One person owns each notification stream. The notification coordinator role owns the matrix.

4. Includes pre-drafted notification templates: Regulators don’t need a full post-mortem in the initial notification. They need a notice that an incident has occurred and that investigation is ongoing. Pre-drafting these templates means the 36-hour OCC notification isn’t blocked by the question “what do we say?”

5. Specifies bank partner escalation paths: Include bank partner points of contact, contractual notification timelines, and the format the bank expects for incident notices.

The NYDFS Part 500 enforcement pattern in 2026 has established what regulators expect: timely preliminary notices, documented timelines, and supplemental updates as investigation progresses. The Incident Response & Breach Notification Kit includes a notification coordination matrix template, pre-drafted initial notification templates for OCC, NYDFS, and GLBA obligations, and a materiality assessment documentation log designed to create the contemporaneous record the SEC enforcement pattern requires.

The Core Discipline

Managing six notification clocks isn’t fundamentally a technology problem or a regulatory interpretation problem. It’s a coordination problem. The clocks start at different times, they run to different recipients, and they exist in different regulatory frameworks — but they all start running the moment a single qualifying event is determined.

For cyber insurance documentation purposes, the same notification timeline records that satisfy regulatory requirements also establish the documented incident response record that insurers require when evaluating claims. Late or inconsistent notifications across different regulatory obligations appear in claim reviews as evidence of an inadequate incident response program.

The time to build the coordination layer is before the incident. During a live event, no one has bandwidth to build the notification matrix from scratch.

The interagency computer-security incident notification requirements are codified at 12 CFR Part 53 (OCC), 12 CFR Part 304 (FDIC), and 12 CFR Part 225 (Federal Reserve). The Federal Register final rule provides the full text.