Feature Incident Response
The Flagstar Blueprint: What the SEC's $3.5M Fine Teaches Every Financial Institution About Cyber Incident Disclosure
In December 2024, Flagstar Bancorp paid $3.5M to settle SEC charges that it made misleading statements about a 2021 cyberattack — including disclosures that said no customer data was compromised when the company already knew 1.5 million records had been stolen. Here's what the SEC's growing cyber enforcement record means for your incident response program.
Table of Contents
When Flagstar Bancorp settled with the SEC in December 2024 for $3.5 million, the case was easy to read as a large-bank story — a regulated depository institution with a compliance department getting penalized for disclosure decisions made at the executive level. The details, though, describe failures that happen in companies of every size: an incident that wasn’t properly routed to the people responsible for disclosures, risk factor language drafted to describe forward-looking threats that got left standing after a past event, and customer notifications that understated what the company already knew.
The Flagstar settlement is the clearest single illustration of what the SEC expects from cyber incident disclosure — and of the specific ways organizations fail at it.
TL;DR
- In December 2024, Flagstar Bancorp paid a $3.5M SEC penalty for misleading disclosures about a 2021 Citrix ransomware breach that stole ~1.5 million customer records
- The SEC found: misleading 10-K risk factor framing, misleading breach notification scope statements, and inadequate disclosure controls that let material information bypass the people responsible for securities filings
- From December 2023 through January 2025, 54 companies filed 80 Form 8-K disclosures under the SEC’s cybersecurity rule — enforcement has followed companies that minimized, delayed, or misdescribed what happened
- The SEC launched the Cyber and Emerging Technologies Unit in February 2025, signaling this is a sustained enforcement area, not a one-cycle initiative
- Private fintechs don’t have 8-K obligations, but the disclosure discipline the SEC is enforcing maps directly to GLBA, OCC/FDIC 36-hour notification requirements, and what your bank partner’s compliance team will ask for after your next incident
What Flagstar Actually Did Wrong
The Citrix breach ran from November 22 to December 25, 2021. Ransomware encrypted approximately 30 percent of Flagstar’s workstations and servers, disrupted the bank’s mortgage origination business, and resulted in the theft of approximately 1.5 million individuals’ personally identifiable information.
That’s material — both quantitatively (1.5M records, a major business line disrupted) and qualitatively (regulatory exposure, litigation risk, customer harm). By any reasonable standard, a material cybersecurity incident.
What followed is where the compliance failures began.
The 10-K risk factor problem: In its 2021 Form 10-K, filed March 1, 2022, Flagstar described cyberattack risk using forward-looking language — “cyberattacks may interrupt our business or compromise the sensitive data of our customers.” At the time this was filed, the bank had already experienced a cyberattack that had interrupted its business and compromised sensitive customer data. Using hypothetical future-tense risk factor language to describe a past event is a disclosure failure regardless of whether it was intentional.
The misleading notification scope: In a June 17, 2022 customer notice and an August 9, 2022 securities filing, Flagstar made statements about the scope of the Citrix breach that the SEC found misleading — understating the nature and extent of the data affected relative to what the company already knew at the time.
The disclosure control failure: The SEC found that Flagstar failed to maintain disclosure controls and procedures that would have ensured material cyber information was available to the people responsible for required disclosures. This is the structural finding — the breach happened, the information about its scope was known internally, and it didn’t reliably reach the disclosure decision-makers who needed it.
The result was $3.5 million, a cease-and-desist order, and a public enforcement record that’s now cited in every analysis of SEC cyber enforcement.
The First Year of Item 1.05: What the Data Showed
The SEC’s cybersecurity disclosure rule took effect December 18, 2023. In the 13 months that followed, 54 companies filed 80 Form 8-K disclosures related to cybersecurity incidents. According to Debevoise’s analysis, only 26 of those filings were under Item 1.05 (material incidents requiring disclosure). The remainder were voluntary disclosures under Item 8.01 (other events) or similar provisions.
That distribution tells a story: companies were being deliberately conservative about what they labeled as “material” under Item 1.05. The SEC noticed.
In May 2024, SEC Director of Corporation Finance Eric Gerding issued a clarifying statement making the intended structure explicit: Item 1.05 is for incidents a company has determined are material. Companies that have not yet completed their materiality assessment, or that are disclosing voluntarily for non-material incidents, should use Item 8.01 — not Item 1.05. The directional message from the SEC was: don’t use Item 1.05 as a voluntary disclosure catch-all, and don’t game materiality assessments to delay the four-day clock.
The SEC then backed this up with enforcement. In October 2024, the agency settled with four companies over cyber disclosure failures, with penalties ranging from $990,000 to $4 million and total penalties exceeding $8 million. At least one company was found to have “negligently made materially misleading misstatements” in its Form 8-K — specifically, characterizing an attack in a way that omitted key facts about what was actually exfiltrated. The Flagstar settlement followed in December 2024.
The pattern across all of these cases is consistent: the SEC is not primarily targeting companies that were attacked. It’s targeting companies that described what happened in ways that understated the severity or misrepresented what was known at the time.
SolarWinds and What It Means for Enforcement Going Forward
The SEC’s case against SolarWinds and its CISO — the most aggressive cyber enforcement action in the agency’s history — was largely dismissed in July 2024 by U.S. District Judge Paul Engelmayer, who rejected the SEC’s novel theory that cybersecurity control deficiencies violated securities law’s internal accounting controls provisions. The SEC agreed to dismiss the remaining claims against SolarWinds with prejudice in November 2025.
The SolarWinds dismissal is sometimes read as a signal that SEC cyber enforcement has limits. That reading is partially correct — the specific theory the SEC used against SolarWinds (cybersecurity controls as accounting controls) didn’t survive judicial scrutiny. The narrower theory that straightforwardly applies to Flagstar — you made affirmatively misleading statements in your disclosures — is not under the same legal cloud.
The enforcement pattern post-SolarWinds has confirmed the narrower read: cases that are grounded in “you said X, you knew not-X” have held up. Cases that required novel legal theories have been at greater risk. CETU’s 2025 mandate appears to reflect exactly this calibration: focus on fraudulent disclosure — affirmative misstatements and omissions — rather than attempting to regulate cybersecurity controls through securities law.
For companies managing disclosure risk, the practical implication is clear: the question is not whether you got hacked. It’s whether you described what happened accurately, in the right filing, at the right time.
What This Means for Private Fintechs
Most fintechs are private. They don’t file 10-Ks or 8-Ks. The SEC’s Item 1.05 rule doesn’t apply to them directly.
But the disclosure discipline it enforces does.
Bank partner exposure: Your bank partner is likely a public company or has public-company affiliates. If a cybersecurity incident at your fintech triggers a material disclosure obligation at your bank partner, their disclosure timeline is affected by how quickly and accurately you provide incident information to them. Bank partners’ compliance teams are increasingly incorporating this timeline into their third-party risk management expectations. As discussed in our analysis of self-disclosure obligations under the Fed’s revised supervisory principles, the regulatory self-disclosure culture that the Fed is building for banks extends to their partner ecosystem.
OCC/FDIC 36-hour notification requirement: Under the federal banking agencies’ computer-security incident notification rule (effective 2022), when a bank-fintech relationship involves a reportable computer-security incident, the notification runs upward quickly — the bank notifies its primary regulator within 36 hours, which means the bank needs to know within a fraction of that window. The discipline around knowing what happened, assessing its scope, and communicating it accurately is identical to what the SEC is enforcing against public companies. The difference is the regulator, not the underlying standard.
GLBA and state notification: GLBA’s Safeguards Rule requires notifying affected customers within 30 days if a breach affects 500 or more customers. All 50 states have breach notification laws, with timelines running from 30 to 90 days (some requiring “expedient” notification). Getting notifications right — not over-broad, not misleading, not understating the scope — is the same problem Flagstar had, at a different regulatory layer.
NYDFS Part 500 72-hour notification: For NYDFS-regulated entities, the 72-hour notification obligation for cybersecurity events runs independently of any SEC or GLBA timeline. The NYDFS Part 500 enforcement pattern in 2026 includes cases where the notification substance was as much at issue as the timing.
The Disclosure Control Problem
The most under-discussed finding in the Flagstar case is the disclosure controls failure. It’s technically a procedural finding — you didn’t have processes to get material information to the right people — but operationally it describes something that happens constantly at companies that handle incidents in operational silos.
The incident response team knows what happened. Legal knows some of what happened. The communications team is drafting customer notifications. The compliance officer might be looped in or might not be. The executive responsible for securities disclosures is relying on what they’re told in a summary brief.
If the incident response, legal, and disclosure processes are not connected — if the people drafting the 10-K risk factor section don’t have access to the live incident scope, or if the customer notification team is working from a partial picture — the result is exactly what happened at Flagstar: multiple documents that say different things because different people had different information.
The fix is not a technology investment. It’s an incident response process that includes an explicit disclosure review step — a defined point in the response timeline where legal and compliance review the current disclosure posture against what the incident team now knows, and update accordingly. For public companies, this step feeds into the 8-K materiality assessment. For private fintechs, it feeds into the bank partner notification, the state breach notification, and the GLBA notice.
As covered in our cyber insurance documentation analysis, the same documentation gaps that produce disclosure failures also produce claim disputes — when your insurance carrier’s understanding of the incident scope differs from what your notifications said.
The Action Checklist
After the Flagstar settlement, the Cyber and Emerging Technologies Unit has a clear enforcement playbook. Here’s what your incident response program should have in place before the next incident:
| Gap | The Fix |
|---|---|
| Risk factor language not updated after incidents | Add a disclosure review checkpoint to your IR process — someone reviews whether any existing public disclosures need updating given current incident facts |
| Materiality assessment not documented | Every significant incident needs a written materiality assessment, even if the conclusion is “not material” — the process of reaching the conclusion needs to be documented |
| Incident scope communicated inconsistently across channels | Single source of truth for incident facts — the notification team, legal, and disclosure team should be working from the same incident documentation |
| Disclosure controls that don’t route to decision-makers | Map who is responsible for securities disclosures (or bank partner notification) and confirm that incident information reaches them before notifications go out |
| No timeline tracking | Every incident notification should have a documented timeline: discovery, initial scope assessment, updated scope assessment, notification drafting, notification sent |
So What?
The SEC’s cybersecurity enforcement record is now two years of consistent signal: the agency will pursue companies that describe incidents inaccurately — whether the error runs toward minimizing, delaying, or framing past events as future risks.
For private fintechs, the specific SEC mechanism doesn’t apply. But the underlying principle — that what you say about a breach needs to be accurate, consistent, and complete relative to what you knew at the time — applies to every notification obligation you have, whether it’s the bank partner call at 2am, the NYDFS 72-hour notice, or the state breach notification letter.
The Flagstar blueprint for failure is not a large-bank story. It’s a process story: the incident response team knew what happened, but the information didn’t reliably reach the people drafting the disclosures. That’s a gap that exists at organizations of every size.
The Incident Response & Breach Notification Kit includes step-by-step incident response playbooks, the all-50-states notification matrix, breach notification letter templates, and a disclosure review checkpoint built into the response workflow — so the Flagstar scenario doesn’t happen because the process made it possible.
Sources: SEC Charges Flagstar for Misleading Investors About Cyber Breach | Flagstar Fined $3.5M for Misleading After 2021 Cyberattack — Banking Dive | Lessons Learned: One Year of Form 8-K Material Cybersecurity Incident Reporting — NYU Compliance and Enforcement | Debevoise Form 8-K Tracker — Two-Year Update | SolarWinds Dismissed — Harvard Law Governance
◆ 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 is the SEC's Form 8-K Item 1.05 cybersecurity disclosure requirement?
What did Flagstar do wrong in its cybersecurity disclosures?
Does the SEC cybersecurity disclosure rule apply to private fintechs?
What is the SEC's Cyber and Emerging Technologies Unit (CETU)?
What are the most common mistakes companies make in cybersecurity incident disclosures?
What notification requirements apply to private fintechs after a cybersecurity incident?
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
Incident Response Decision Log: Document Why a Notification Clock Did—or Did Not—Start
When a cyber event hits, every regulator wants the same thing: proof you made a good-faith materiality determination without unreasonable delay. Here's the decision log structure that creates that proof—whether the clock started or not.
Jul 24, 2026
Incident Response
Four Months Late: What the NYDFS Healthplex $2M Penalty Says About When the Notification Clock Actually Starts
NYDFS fined Healthplex $2 million in August 2025 for notifying 4+ months after a breach. The failure wasn't forensics — it was a misunderstanding of when the 72-hour clock starts. The same mistake trips up banks under the FDIC's 36-hour rule.
Jul 23, 2026
Incident Response
Three Clocks, One Incident: How to Manage the Overlapping Cyber Notification Timelines Under OCC, NYDFS, and SEC Rules
When a cyber incident hits, you're not managing one notification obligation — you're managing six, with different triggers, different recipients, and different clocks. The OCC's 36-hour rule, NYDFS's 72-hour requirement, the SEC's 4-business-day materiality window, GLBA customer notices, FinCEN SAR filing, and bank partner contractual obligations all run simultaneously. Here's how to track them without missing one.
Jul 18, 2026