Feature Incident Response
NYDFS Fined Delta Dental $2.25M for an IR Plan That Couldn't Answer the Right Questions. Can Yours?
NYDFS's first cyber enforcement action of 2026 — a $2.25 million penalty against Delta Dental — wasn't about missing firewalls or unpatched servers. It was about an incident response plan that didn't address regulatory reporting obligations clearly. Here are the five gaps regulators consistently find in incident response programs at financial services firms, and how to close them before an examiner does.
Table of Contents
TL;DR
- NYDFS issued its first cyber enforcement action of 2026 against Delta Dental Insurance Company and Delta Dental of New York — a $2,250,000 penalty — for deficiencies arising from the 2023 MOVEit Transfer breach, citing an inadequate incident response plan and data minimization failures.
- The specific IR failure: the plan didn’t clearly establish when and how to notify NYDFS — not a technical gap, a documentation and process gap.
- Financial services firms consistently have the same five IR plan weaknesses: notification triggers that don’t map to regulatory standards, no data minimization/retention policy, no vendor-breach response track, missing CIRCIA notification workflows, and undocumented tabletop exercises.
- Closing these gaps is pre-incident work. Once a breach happens, the IR plan is the document your regulator reads first — and “we didn’t have that in writing” is not an answer that avoids a penalty.
In May 2026, NYDFS announced its first cyber enforcement action of the year. The target was Delta Dental Insurance Company and Delta Dental of New York, Inc. The penalty was $2,250,000. The underlying incident was the 2023 MOVEit Transfer breach — a mass exploitation event that hit hundreds of organizations globally, including Delta Dental.
Delta Dental’s security team did not cause the breach. The vulnerability was in Progress Software’s MOVEit file transfer product, which attackers exploited at scale in May and June 2023. But that defense — it was a vendor’s vulnerability, not ours — carries exactly zero weight with NYDFS when the investigation reveals that your incident response plan didn’t address how to handle that notification, or when your organization retained data that it didn’t need to retain, making the breach larger than it had to be.
The Debevoise Data Blog analysis of the consent order named two themes that NYDFS consistently emphasizes in cyber enforcement: dispose of data you no longer need, and notify the Department early. Both of those are IR plan problems, not firewall problems.
Why IR Enforcement Is About Process, Not Just Technology
The natural reaction to a MOVEit-style breach is to focus on the technical controls — patch management, software inventory, vendor security assessments. Those matter. But the NYDFS enforcement against Delta Dental demonstrates that when regulators look at how you responded, they’re reading your incident response plan.
They want to know: Did you have a documented process? Did that process specifically address how to evaluate whether a cybersecurity event requires regulatory notification? Did you notify on the required timeline? And did your data governance practices limit the scope of the breach to only what you legitimately needed to retain?
If those questions have clear, documented answers — and your organization actually followed them — enforcement risk drops substantially. If the answers are “sort of,” “not really,” or “the plan was a template we downloaded in 2022,” that’s where penalties come from.
After reviewing NYDFS enforcement patterns, OCC examination guidance, and the CIRCIA final rule requirements, five gaps show up in financial services IR programs consistently. Here’s what they are and how to close them.
Gap 1: Notification Triggers That Don’t Map to Regulatory Standards
The most commonly cited IR plan weakness in NYDFS enforcement actions is also the most basic: the plan doesn’t clearly define when and how to notify regulators.
An adequate notification trigger doesn’t just say “notify regulators when a breach occurs.” That’s not operational. Operational notification triggers answer: Which regulators? What specific event types trigger each obligation? Who makes the determination that notification is required? Within what timeframe does that determination need to be made?
NYDFS Part 500 requires notification within 72 hours of a “determination” that a covered cybersecurity event has occurred. The clock starts at determination, not at confirmation of full scope. Your IR plan must define what “determination” means — what information is sufficient to trigger the 72-hour obligation — and who has authority to make that call.
OCC-regulated institutions face an additional 36-hour bank notification requirement. SEC-reporting companies have a separate four-business-day Form 8-K Item 1.05 obligation. Starting in late 2026, CIRCIA adds a fifth track — notification to CISA within 72 hours of “reasonably believing” a substantial cyber incident has occurred, and within 24 hours of making any ransomware payment.
Each of these clocks has different triggers, different content requirements, and goes to a different agency. They are not the same clock. An IR plan that generically references “notify regulators” without explicitly addressing each obligation — and documenting who owns each notification — is going to fail examination when regulators compare it against the actual regulatory text.
The fix: Build a notification decision matrix into your IR plan. For each regulatory obligation, the matrix should answer: What event type triggers this obligation? What is the timeline? Who has authority to make the filing determination? What information is required in the initial notification? Who drafts the filing, and who approves it?
Gap 2: No Data Minimization Policy Linked to IR Scope Assessment
Delta Dental’s enforcement action didn’t just cite IR plan weaknesses — it cited data retention failures that increased the scope of the breach.
This is a gap that practitioners often miss because data minimization feels like a privacy program issue, not an IR issue. But when a breach occurs, the first question regulators ask is: what data was affected? If your organization retains data beyond its operational need — because “we might need it someday” or because cleaning up old records is low priority — you’ve artificially inflated the potential scope of any incident involving that data.
Under NYDFS Part 500, covered entities are required to address the secure disposal of data that is no longer needed for business operations. The Delta Dental enforcement makes explicit that NYDFS will cite data minimization failures as part of a cyber enforcement action — not just as a standalone data governance violation.
The fix: Your IR plan should reference your data retention and disposal policy. As part of incident scoping, responders should be asking: was the affected data appropriately retained, or should it have been disposed of? If data in scope for a breach was outside your retention schedule, that finding goes into your post-incident review and becomes a remediation action item. If your organization doesn’t have a data retention and disposal policy, that gap is now a known IR risk — and a documented one.
Gap 3: No Vendor/Third-Party Breach Response Track
The MOVEit breach wasn’t caused by Delta Dental’s internal systems. It was caused by a vulnerability in a third-party software product that an attacker exploited. Delta Dental is one of hundreds of organizations that were affected because they used the product.
This is increasingly the dominant breach pattern in financial services. The Citizens Bank, Frost Bank, and Everest ransomware vendor breach; the IDScan.net breach affecting 153 million identity records; the Synapse bankruptcy exposing embedded finance accounts — in case after case, the incident originates with a third-party vendor, not an internal failure. The NYDFS Part 500 third-party cybersecurity guidance is explicit that covered entities cannot delegate their Part 500 obligations to vendors — and that includes the obligation to have a plan for responding to vendor-triggered incidents.
But most IR plans are written from an inside-out perspective: a threat actor gets into our environment, we contain and eradicate, we notify. They don’t address the outside-in pattern: a vendor we use is compromised, our data is affected, we need to assess scope, determine reporting obligations, and manage the vendor response process — all without direct access to the vendor’s forensics.
A vendor breach response track needs to address at minimum: How do you learn about a vendor breach? (Monitoring vendor notifications, threat intelligence, direct outreach.) How do you assess whether your data was affected? Who owns vendor breach response communication? What do your vendor contracts require the vendor to provide you, and by when? What are your notification obligations if vendor data is involved?
The fix: Add a vendor/third-party breach trigger as a distinct scenario in your IR plan. Run a tabletop exercise with that scenario — an external vendor notifies you that your customer data may have been affected by their breach. Who does what, in what order, on what timeline? The answer to that question before an incident is the difference between a documented response and a $2.25 million enforcement action.
Gap 4: CIRCIA Notification Track Missing from Your Runbook
The CIRCIA final rule published in 2026 created a new mandatory notification obligation to CISA for covered entities — including financial services firms above the SBA small-business size threshold. The requirement: report a “substantial cyber incident” to CISA within 72 hours of “reasonably believing” one has occurred, and report any ransomware payment to CISA within 24 hours of payment.
CIRCIA’s 72-hour clock runs from a different trigger than NYDFS’s: “reasonably believing” a substantial incident has occurred, rather than “determining” one has. That distinction matters for how your response team classifies and escalates early-stage incidents — an event that doesn’t yet meet the NYDFS “determination” threshold may still meet CIRCIA’s “reasonably believes” threshold.
The content requirements also differ. CIRCIA’s initial notification to CISA can be incomplete — they expect supplemental updates as the investigation progresses — but it must be filed. An IR program that was built before CIRCIA exists and hasn’t been updated to add CISA as a notification recipient is an IR program with a compliance gap. It’s not a theoretical gap. CIRCIA’s enforcement provisions include penalties for failing to file required reports.
The fix: Add CISA to your regulatory notification matrix. Define what “reasonably believes a substantial cyber incident has occurred” means operationally for your IR team — what threshold of available information triggers the CIRCIA filing obligation? Assign a CIRCIA notification owner. Include the CISA CIRCIA reporting portal and filing guidance in your IR runbook. This is a new clock that doesn’t exist in most IR plans written before 2026 — and it needs to be in yours.
Gap 5: Undocumented Tabletop Exercises
NYDFS Part 500 requires covered entities to annually test their incident response plan. The FFIEC IT Examination Handbook calls for regular testing as well. But what examiners find — consistently — is that organizations have run exercises without creating records.
A tabletop exercise that nobody documented provides zero examination credit. Regulators aren’t asking whether you think your team could handle an incident. They’re asking whether you have evidence that you actually tested the plan, identified gaps, and addressed those gaps. That evidence is documentation: who participated, what scenario was used, what the exercise revealed, what actions were assigned afterward, and what the completion status of those actions is.
The documentation also matters because tabletop exercises generate the most valuable input your IR program can receive — a structured rehearsal that shows you exactly where the plan breaks down, where decision authority is unclear, and where notification timelines can’t actually be hit in practice. Organizations that don’t document this lose that institutional knowledge, and they can’t demonstrate to regulators that they learned from it.
The fix: Treat your tabletop exercise as a compliance deliverable, not a team event. Produce a short post-exercise report: scenario, participants, key findings, gap list, remediation actions, and owners. That report becomes part of your IR program evidence file — the same file your examiner will review. If your last documented tabletop is over 12 months old, that’s a gap that shows up in your next examination.
How to Test Your Own IRP Right Now
You don’t need to wait for an examiner to find these gaps. A self-assessment against the five areas above takes a morning and produces a clear remediation list.
Pull your current IR plan and check each gap:
-
Notification triggers: For each regulatory obligation (NYDFS, OCC, SEC, CIRCIA, state breach notification), does your plan identify the specific trigger, timeline, filing authority, and notification owner? Is the decision matrix explicit?
-
Data minimization: Does your plan reference your data retention schedule? Does your incident scoping procedure include a check for whether retained data was within its retention period?
-
Vendor breach track: Does your plan include a distinct scenario for a vendor-triggered incident? Does it identify how you learn about vendor breaches, who owns vendor communication, and what your contracts require?
-
CIRCIA track: Is CISA in your notification matrix? Have you defined the “reasonably believes” trigger for CIRCIA’s 72-hour clock?
-
Tabletop documentation: When was your last tabletop exercise? Is there a written record of it? Is there an open action list from it?
If you’re missing any of these, you now have a remediation list. The time to close these gaps is before the incident, when you have the luxury of deliberate process design. After the breach, your regulator reads the plan you had — not the one you intended to write.
The Incident Response & Breach Notification Kit includes step-by-step playbooks for the most common financial services incident types, an all-50-states breach notification matrix with timelines and AG notification requirements, internal escalation procedures with notification decision trees, and tabletop exercise scenarios with documentation templates. The regulatory notification matrix covers OCC 36-hour, NYDFS 72-hour, SEC Item 1.05, and CIRCIA — with the content requirements for each.
So What?
The Delta Dental enforcement action is a data point in a consistent regulatory pattern: NYDFS, OCC, and other financial services regulators have moved from examining whether you have an IR plan to examining whether the plan actually works. “We have an IR plan” is no longer the answer to the examination question. “Here is our documented plan, here are our tabletop exercise results, and here is evidence that we addressed the gaps we found” is the answer that closes the finding.
The five gaps above are not novel. They show up in enforcement actions and examination findings repeatedly. They’re the gaps that turn a recoverable incident into a regulatory penalty. And they’re all closable with deliberate, pre-incident process work.
Your examiner will show up after the incident and read your IR plan. The question is what they’ll find.
Sources: NYDFS First 2026 Cyber Enforcement Action — Debevoise Data Blog | NYDFS Regulated Entities Face Stronger Cybersecurity Regulations in 2026 — Ropes & Gray | CIRCIA Final Rule Expected 2026 — ComplianceHub.Wiki | NYDFS Cybersecurity Part 500 Requirements — FCI Cyber | Cost of NYDFS Cybersecurity Noncompliance — HYPR
◆ Need the working template?
Start with the source guide.
These answer-first guides summarize the required fields, evidence, and implementation steps behind the templates practitioners search for.
◆ Related template
Incident Response & Breach Notification Kit
Step-by-step incident response playbooks and breach notification templates for all 50 states.
◆ Immaterial Findings · Weekly
Sharp risk & compliance insights. No fluff.
◆ FAQ
Frequently asked questions.
What did NYDFS find wrong with Delta Dental's incident response plan?
Why does data minimization show up in an IR enforcement action?
When does the NYDFS 72-hour notification clock start?
What is a covered cybersecurity event under NYDFS Part 500?
Does CIRCIA replace my existing regulatory notification obligations?
How often should we run IR tabletop exercises, and what documentation do examiners want to see?
Author
Rebecca Leung
Rebecca Leung has 8+ years of risk and compliance experience across first and second line roles at commercial banks, asset managers, and fintechs. Former management consultant advising financial institutions on risk strategy. Founder of RiskTemplates.
◆ Related framework
Incident Response & Breach Notification Kit
Step-by-step incident response playbooks and breach notification templates for all 50 states.
◆ Keep reading
Related posts.
Incident Response
CISA's CIRCIA Is Finalizing This Month. Here's What the New 72-Hour Reporting Clock Means for Your Financial Services Incident Response Program.
CISA's CIRCIA final rule — requiring 72-hour cyber incident reporting to CISA and 24-hour ransomware payment disclosure — is expected to publish in September 2026. For financial services firms, it creates a fifth notification obligation running parallel to OCC/FDIC, SEC, NYDFS, and state breach notification clocks. Here's what your IR program needs to add before the effective date.
Sep 8, 2026
Incident Response
The 36-Hour Notification Clock Doesn't Wait for Your Investigation. Here's What the OCC's June 2026 Cybersecurity Report Means for Your Incident Response Program.
The OCC's June 2026 Cybersecurity Report and NYDFS's $144M+ enforcement record make one thing clear: incident response programs designed around investigating before notifying will fail the regulatory test. Here's what your program needs to do differently.
Sep 4, 2026
Incident Response
The FTC's 30-Day Breach Notification Requirement: What Non-Bank Fintechs Keep Getting Wrong
The FTC's Safeguards Rule amendment has required non-bank financial institutions to report data breaches to the FTC within 30 days since May 13, 2024. The clock starts when any employee discovers the breach — not when legal decides it's reportable. Here's what most fintech incident response plans still don't address.
Aug 30, 2026