Four Months Late: What the NYDFS Healthplex $2M Penalty Says About When the Notification Clock Actually Starts

In November 2021, a 20-year employee at Healthplex, Inc. clicked a phishing email. The email requested credentials — a format that should have been caught by training but wasn’t. Attackers used those credentials to access an email environment containing sensitive consumer information. Over 100,000 emails were exposed.

NYDFS fined Healthplex $2 million in August 2025.

Not for the phishing attack itself. Not for insufficient technical controls, though the regulator cited those too. The primary enforcement finding was simpler: Healthplex failed to notify NYDFS within 72 hours of determining that a qualifying cybersecurity event had occurred. It notified more than four months after the incident.

That’s the enforcement pattern practitioners need to understand in 2026. The violation wasn’t inadequate technology. It was a misunderstanding of when the regulatory clock starts — and what it requires to satisfy it.

TL;DR

• NYDFS fined Healthplex $2 million (August 2025) for notifying 4+ months after a phishing breach — the core violation was notification delay, not the breach itself
• The 72-hour NYDFS clock and the 36-hour federal banking agency clock both start at determination, not at discovery or investigation completion — this distinction is enforced
• The most common institutional failure is treating forensic investigation completion as a prerequisite to notification; regulators explicitly permit early notification with incomplete facts, followed by supplements
• Incident response plans that don’t include a documented “determination decision” workflow — separate from the forensic investigation — are likely to produce the same failure mode under examination

The Notification Rule Healthplex Violated

NYDFS Part 500 §500.17(a) requires covered entities — any person licensed, registered, chartered, or authorized to operate under New York financial services law — to notify the NYDFS Superintendent within 72 hours of determining that a reportable cybersecurity event has occurred.

A reportable cybersecurity event, under Part 500, is one that: (1) impacts the covered entity and notice is required to any government body, self-regulatory organization, or other supervisory body; or (2) has a reasonable likelihood of materially affecting the normal operation of the covered entity; or (3) involves actual or potential unauthorized access to, disclosure of, or use of nonpublic information.

Healthplex’s 2021 phishing breach met criterion (3). Over 100,000 emails containing sensitive consumer data were exposed. The moment Healthplex determined that a qualifying cybersecurity event had occurred, the 72-hour window started. According to the NYDFS consent order, that determination happened — or reasonably should have happened — substantially earlier than four months after the incident.

The NYDFS’s November 2023 Second Amendment to Part 500 (fully effective November 1, 2025) added additional requirements, but the core notification obligation Healthplex violated was in place since 2017. This wasn’t a new rule.

What “Determination” Actually Means — and Why It’s the Enforcement Trigger

The central misunderstanding in most late-notification cases is conflating two separate phases of incident response:

Phase 1: Investigation. Determining what happened, how, and the full scope of impact. This is the forensic phase. It can take weeks or months.

Phase 2: Determination. Concluding whether the incident meets the regulatory definition of a reportable event. This is a legal and compliance decision. It can — and often must — be made with incomplete information.

Regulators have been explicit that Phase 1 is not a prerequisite for Phase 2. The OCC’s preamble to the federal banking agencies’ 36-hour rule states directly: “We do not expect that a banking organization will need to have completed a full investigation or determined the cause of a notification incident before it determines that it has experienced a notification incident.”

Translated for practitioners: once you have enough facts to conclude that a reportable event likely occurred, the clock has started. You do not need to know who did it, exactly how many records were affected, or whether you’ve fully contained the threat.

In Healthplex’s case, the breach involved a successful phishing attack on a privileged account that accessed a large email environment. It strains credibility to argue that the “determination” required four months. The circumstances of the attack — credential phishing, access to an email system, over 100,000 emails exposed — were knowable far earlier. The four-month gap appears to reflect waiting for the forensic investigation to complete before treating the notification obligation as triggered.

That’s the mistake.

The Same Principle in the Federal 36-Hour Rule

Banks subject to OCC, FDIC, or Federal Reserve supervision face the same principle with a shorter deadline.

The federal banking agencies’ computer-security incident notification rule (effective May 1, 2022) defines a “notification incident” as a computer-security incident that has materially disrupted or degraded — or is reasonably likely to disrupt or degrade — a banking organization’s ability to carry out banking operations, activities, or processes to a material portion of its customer base, or that impacts the stability of the financial sector.

The clock starts when the banking organization determines it has a notification incident. Not when it discovers an incident. Not when the investigation is complete. At determination.

The federal rule provides concrete examples of notification incidents: ransomware attacks encrypting core banking systems, large-scale DDoS attacks disrupting account access for more than four hours, failed system upgrades causing widespread user outages, and malware posing imminent threats to core business lines. These are incidents where the triggering nature is obvious from the start — waiting for a forensic investigation to confirm what the symptoms already indicate is not contemplated.

For banking organizations, the 36-hour clock is tighter than NYDFS’s 72-hour window. In a weekend incident discovered on Saturday morning, 36 hours from determination reaches Sunday evening — requiring incident response leadership to have a 24/7 notification process, not just a weekday workflow.

Comparing the Regimes (and Why Both Apply Simultaneously)

Many financial institutions are subject to both frameworks. A bank licensed in New York faces both the 36-hour federal requirement and the 72-hour NYDFS requirement for the same incident. An insurance company doing business in New York faces NYDFS Part 500 and potentially SEC obligations if it’s publicly traded.

These clocks run in parallel. They don’t consolidate, they don’t pause for each other, and they don’t reset when a new fact is discovered. The fastest clock in your obligation stack determines your most urgent deadline.

Why Organizations Wait — and Why the Reasons Don’t Hold Up

The four arguments organizations make for delaying notification are worth examining directly, because each one sounds reasonable and each one has been rejected by regulators.

“We don’t have enough information yet.” Regulators explicitly permit early notifications with incomplete information, followed by supplemental notifications as additional facts become available. The NYDFS has stated that early notification is preferred over late notification with complete information. Filing a partial notification is not a regulatory violation; missing the notification deadline is.

“We need to assess our legal exposure before notifying.” This reasoning inverts the risk calculus. Under NYDFS Part 500 and the federal banking rule, late notification is a regulatory violation that creates separate enforcement exposure. The question isn’t whether to notify — it’s how to notify in a way that preserves appropriate legal privilege while meeting the deadline. Privileged communications between counsel and the company about the incident are separate from the regulatory notification itself.

“We don’t know if this rises to the level of a reportable event.” This determination must be made, and the clock doesn’t pause during the analysis. The answer to this uncertainty is a documented determination process — who is responsible for evaluating whether an incident is reportable, what criteria they use, and when that evaluation must be completed. An undocumented determination process is what produces four-month delays.

“Our PR/communications team isn’t ready to go public.” Regulatory notification is not a public announcement. NYDFS notification goes to NYDFS; the federal banking notice goes to the primary federal regulator. Neither automatically triggers public disclosure. Public disclosure obligations (GLBA customer notices, SEC 8-K for public companies) have their own timelines and triggers — they’re separate from regulator notification.

What Your Incident Response Plan Is Missing

The Healthplex case, like Delta Dental’s 162-day notification delay before it, isn’t a forensics failure. It’s a workflow failure. The incident response plan either didn’t distinguish between the forensic investigation and the regulatory determination, or it assigned the determination to the investigation team rather than to compliance and legal.

A regulatory notification determination framework in your incident response plan should include:

A named decision-maker. Who has authority to declare that a regulatory determination has been made? It should be a compliance officer or general counsel, not the forensic investigator or IT team. The investigator answers questions of fact; the compliance officer answers questions of regulatory applicability.

A maximum evaluation timeline. The plan should specify that the determination must be made — or affirmatively deferred with documented reasoning — within a defined period after an incident is escalated. For federal banking organizations, 24 hours from escalation as a maximum evaluation window gives sufficient buffer before the 36-hour notification deadline.

A written determination record. Document the conclusion reached, the facts supporting it, and the time the determination was made. This record serves as your evidence that the notification clock was properly triggered when it was, and that the notification was timely.

A template for early notification. An incomplete notification that accurately reflects what is known at the time of determination is legally sound and regulatorily compliant. “We have determined that a computer-security incident has occurred that meets the definition of a notification incident. We are conducting a forensic investigation and will provide additional information as it becomes available.” That’s a timely notification.

A tracking mechanism for supplemental notifications. Once you’ve notified, the investigation continues. As new facts emerge — scope of exposure, affected customers, attacker identity, timeline — supplemental notifications update regulators. The plan should specify who monitors this and at what intervals.

So What?

The Healthplex case isn’t about a $2 million fine. It’s about what happens when incident response plans are built around the investigation rather than the notification obligation. Forensic teams optimize for accuracy; regulators require timeliness. When those objectives aren’t separated, the investigation timeline becomes the notification timeline — and that produces four-month delays.

Every financial institution with NYDFS exposure or federal banking regulator oversight needs to evaluate: is the regulatory determination step in our incident response plan clearly separated from the forensic investigation? Who makes the determination? On what timeline? And does that person know they don’t need the investigation to be complete before they can determine a reportable event has occurred?

If the answer to any of those questions is unclear, the incident response plan needs revision before the next incident — not after.

The Incident Response & Breach Notification Kit includes a regulatory notification determination framework, timeline tracking for simultaneous notification obligations, and an early-notification template designed for use before forensic investigation is complete.

For the broader context of managing multiple simultaneous notification obligations, see Three Clocks, One Incident: How to Manage the Overlapping Cyber Notification Timelines. For SEC-specific materiality determination, see the Flagstar incident response case study. And for how NYDFS Part 500 enforcement has escalated in 2026, see NYDFS Part 500 2026 enforcement and exam findings.