Feature Incident Response
Breach Notification Letter Template: What the Law Requires, What Regulators Charge For, and Why Your Approval Process Fails Under Pressure
The content of a breach notification letter isn't optional — multiple regulatory frameworks specify exactly what must be in it, and enforcement actions from the FTC, SEC, and CFTC show how specific the mistakes regulators will charge you for. Here's what goes in the letter and how to build an approval process that holds up when the 30-day clock is running.
Table of Contents
TL;DR
- Breach notification letter content is legally mandated across multiple frameworks — what you say, what headings you use, and what you leave out all carry enforcement risk
- The most common enforcement targets aren’t companies that failed to send a letter; they’re companies that sent one with inaccurate, incomplete, or misleading content
- California SB 446 (effective January 1, 2026) now requires five specific section headings by statute; HIPAA mandates five content elements in plain language; the 2005 Interagency Guidance requires six elements for bank customers
- Pre-approved templates with fill-in-the-blank sections are the only way to meet 30-day deadlines without creating legal exposure in the process
There were two lawyers, a compliance officer, a communications director, and a CISO in the room. The breach had been confirmed at 9 a.m. California law gave them 30 days. The FTC’s 30-day regulator notification clock was already running. They had no draft to start from.
By the end of the first week, there were four versions of the customer letter, two of which contradicted each other on what data had been taken. By day 15, legal had added qualifications that rendered the description of the incident nearly unreadable. The final version went out on day 28 and said, among other things, that the attacker “may have accessed” certain information — which was technically true but omitted the fact that the investigation had already confirmed the data was taken.
That kind of hedge isn’t just legally imprecise. It’s the specific language that cost Pearson plc $1 million in an SEC enforcement action.
Why Notification Letter Content Is a Legal Requirement, Not a Communication Decision
Most organizations treat the breach notification letter as a communications exercise — legal reviews it for liability, PR shapes the tone, and someone approves the final draft. That framing is backward. The content of the letter is legally specified before the incident ever happens, by at least three separate regulatory frameworks that may apply to the same event simultaneously.
Getting the letter wrong isn’t just a reputational problem. The FTC, SEC, and CFTC have all brought enforcement actions based specifically on what the notification said — or didn’t say.
What Each Framework Requires
GLBA — The 2005 Interagency Guidance for Bank Customers
For banks supervised by the OCC, FDIC, or Federal Reserve, customer notification after a breach is governed by the “Interagency Guidance on Response Programs for Unauthorized Access to Customer Information and Customer Notice,” issued March 29, 2005 (70 FR 15736) under GLBA Section 501(b).
The guidance establishes a threshold and a content requirement. Notification is required when an institution determines that misuse of customer information “has occurred or is reasonably possible.” When that threshold is met, the notice must include:
- A general description of the incident
- The type of customer information subject to unauthorized access or use
- What the institution has done to protect customers from further unauthorized access
- A telephone number customers can call for further information and assistance
- A reminder to remain vigilant over the next 12 to 24 months
- Instructions to promptly report suspected identity theft to the institution
When the incident involves information that could enable identity theft or account fraud, five additional elements should be included: a recommendation to review account statements and report suspicious activity; information about placing fraud alerts on credit reports; a recommendation to obtain credit reports periodically; an explanation of how to get credit reports free of charge; and the FTC’s website address and toll-free number for identity theft guidance.
These are the content requirements for customer letters at regulated banks — established in 2005 and unchanged since. The FFIEC 36-hour computer-security incident notification rule governs a separate, parallel obligation to notify the institution’s primary federal regulator of certain incidents within 36 hours. These are two different notification pathways for two different recipients.
HIPAA — Breach Notification Rule (45 CFR § 164.404)
For covered entities and business associates, HIPAA’s Breach Notification Rule requires individual notice within 60 days of discovery. The rule specifies five required content elements, and requires them to be written in plain language:
- A brief description of what happened, including the approximate date of the breach and the date of discovery
- A description of the types of unsecured protected health information involved (for example: name, Social Security number, date of birth, home address, account number, diagnosis, disability code)
- Steps individuals should take to protect themselves from potential harm
- A brief description of what the covered entity is doing to investigate the breach, mitigate harm, and prevent future breaches
- Contact procedures: a toll-free phone number, email address, website, or postal address where individuals may ask questions or obtain additional information
The plain language requirement is enforced. A notice that accurately lists required elements but is written at a level that makes it difficult for a typical patient to understand creates its own compliance exposure.
California — § 1798.82 (SB 446, Effective January 1, 2026)
California’s breach notification law was amended by SB 446, which took effect January 1, 2026. For breaches affecting California residents, the law now requires notification within 30 days of discovery — down from the prior “expedient time” standard. It also mandates specific section headings in the notification letter.
Under § 1798.82, letters sent to California residents must use these headings:
- “What Happened”
- “What Information Was Involved”
- “What We Are Doing”
- “What You Can Do”
- “For More Information”
These aren’t suggested best practices. They are statutory requirements. A letter that covers the same information under different headings — or with no headings at all — does not comply with the 2026 amendment.
If 500 or more California residents are affected, the institution must also notify the California Attorney General within 15 days of the date residents are notified.
New York — GBL § 899-aa (Amended December 24, 2024)
New York’s SHIELD Act was amended in December 2024. Notification to affected New York residents is required within 30 days of discovery. The notice must include: contact information for the entity; information about New York state consumer resources (including the AG’s office and the FTC’s identity theft resources); a description of the category of data involved; and specification of the type of personal information accessed.
The December 2024 amendment added a requirement to notify the New York Department of Financial Services (NYDFS) for any breach involving a New York state regulated entity — a new channel alongside the existing AG notification requirement.
For a fuller state-by-state timeline comparison, the 50-state breach notification laws post includes the current deadline, threshold, and escalation requirements for every state.
SEC Regulation S-P — Investment Advisers and Broker-Dealers
The SEC’s amended Regulation S-P (finalized 2024) requires investment advisers and broker-dealers to notify affected individuals within 30 days of discovering unauthorized access to or use of covered data. The SEC Regulation S-P amendment post covers the specific applicability scope and the incident response program requirements the rule introduced alongside the notification obligation.
The FTC Safeguards Rule — What It Does and Doesn’t Require
A common misconception: the FTC Safeguards Rule (16 CFR Part 314, amended November 2023, effective May 13, 2024) does not require sending notification letters to affected customers. It requires non-bank financial institutions — mortgage brokers, auto dealers, tax preparers, payday lenders — to notify the FTC within 30 days of discovering a security event affecting 500 or more customers. The customer-facing notification obligation for those same institutions comes from state laws, not the Safeguards Rule itself.
For prudentially-regulated banks (OCC, FDIC, Federal Reserve), the FTC Safeguards Rule doesn’t apply at all — those institutions are governed by the 2005 Interagency Guidance and the 2021 Computer-Security Incident Notification Rule.
What Enforcement Tells You About What Goes Wrong
The most instructive body of guidance on notification letter content isn’t in the regulations — it’s in the enforcement record. These cases show exactly the errors that generate findings.
FTC vs. Blackbaud (2024) — The Inaccurate Initial Notice
Blackbaud, a cloud software provider, suffered a 2020 ransomware attack and paid the attacker. On July 16, 2020, it sent an initial breach notification to its customers stating that the attacker had not exfiltrated credit card numbers, bank account information, or Social Security numbers. By July 31 — two weeks later — Blackbaud’s internal investigation confirmed those data types had in fact been stolen. Blackbaud did not correct the initial notification until October 2020, more than three months after learning the original notice was false.
The FTC’s 2024 consent order made this the first standalone FTC enforcement action based solely on an inaccurate breach notification. The charge was that sending a materially false initial notice, and then failing to promptly correct it, was an unfair act or practice under Section 5 of the FTC Act.
Lesson: An inaccurate notice isn’t corrected by eventually sending a more accurate one. The gap between the false notice and the correction is itself an enforcement event.
SEC vs. Flagstar Bancorp (2024) — “Access” vs. “Theft”
Flagstar suffered a November 2021 ransomware attack that encrypted approximately 30% of its systems and resulted in theft of PII for approximately 1.5 million customers. The June 2022 customer notice described the incident as unauthorized “access” to its network and customer data — without disclosing that network systems had been disrupted or that PII had been stolen. The SEC’s December 2024 settlement ($3,550,000) specifically cited the customer notice as a materially misleading disclosure.
Lesson: “Unauthorized access” when data was actively exfiltrated and systems were disrupted is, in the SEC’s view, not a description — it’s a mischaracterization. The SEC also found that Flagstar’s internal disclosure policies lacked written guidance on what materiality factors to consider in drafting incident disclosures. That gap contributed directly to the inadequate letter.
SEC vs. Pearson plc (2021) — “May Have” When You Know
Pearson discovered a 2019 intrusion that resulted in theft of millions of student records. In a July 2019 media statement following press inquiry, Pearson said the breach “may have included” birth dates and email addresses — when the company already knew those data elements had been taken. The SEC’s August 2021 settlement ($1 million) found that using hedge language about data that was known to have been stolen was a materially false statement.
Lesson: “May have included” is a hedge. It is appropriate when the investigation is genuinely inconclusive. When the investigation has already confirmed the data was taken, that hedge becomes a false statement.
CFTC vs. Phillip Capital (2019) — The Phishing Warning Substitution
In February 2018, Phillip Capital, a registered futures commission merchant, suffered a cyberattack in which criminals compromised its email system and fraudulently wired $1 million of customer funds. Rather than notify customers of the actual breach, Phillip Capital sent a generic phishing warning to all customers — no disclosure that an actual breach had occurred, that the email system was compromised, or that customer funds had been stolen. A belated breach notification was sent nearly one year later, in February 2019.
The CFTC found that substituting a generic security reminder for an actual breach notification violated disclosure obligations under CFTC Advisory 14-21. The penalty was $1.5 million — $500,000 civil penalty plus $1 million restitution.
Lesson: A generic “be careful of phishing” email sent in response to a confirmed breach is not a breach notification. Regulators treat the substitution itself as an affirmative violation, not just a delay.
The pattern across these cases: the problem is almost never failure to send a letter. It’s the content of the letter — hedged language when facts were known, missing categories of stolen data, generic framing substituted for specific disclosure, and inaccuracies left uncorrected.
Building a Pre-Approved Template
The only way to draft a legally adequate breach notification letter under a 30-day clock is to have the template already approved before the incident. The 30 days is not enough time to draft from scratch, route to legal for substantive review, and distribute across multiple states — not without shortcuts that create exposure.
A compliant template has two layers: the structural elements required by law, and fill-in-the-blank sections that must be completed with incident-specific facts.
What the template pre-approves:
- Section headings required by California law
- The required elements from the 2005 Interagency Guidance, HIPAA, and applicable state laws
- Legal disclaimers reviewed for compliance with each framework
- Contact information format and the FTC identity theft resource block
- Credit monitoring offer terms (if the organization’s policy is to offer it)
What the template leaves blank for incident-specific completion:
- The specific dates (date of discovery, approximate date of breach)
- The data types involved (pulled directly from the incident investigation log)
- A description of the specific incident (reviewed by legal before any version goes out)
- The response actions taken (updated to reflect what was actually done)
The incident triage post covers how the incident severity and materiality assessment process should determine which notification frameworks apply — a breach affecting California residents, HIPAA-covered PHI, and customers of an SEC-registered investment adviser triggers three separate notification obligations with three different content standards, each potentially requiring a separately tailored letter.
The Approval Process That Holds Under Pressure
The Flagstar case is instructive not just for what was said in the letter — but for what the SEC found in the internal process. Flagstar’s disclosure policies lacked written guidance on what materiality factors to consider when drafting incident disclosures. In other words, there was no documented decision framework; whoever drafted the letter made a judgment call without written criteria.
A defensible approval process documents:
- Who has final sign-off authority for each notification type (customer, regulator, AG)
- What written criteria govern whether the investigation findings are “known” vs. “reasonably possible” vs. “inconclusive”
- The maximum time allowed for legal review before the draft goes out (to prevent delays that push against the deadline)
- Who owns updating the letter if investigation findings change after the initial draft is approved
- How versions are tracked so the final approved version is unambiguous
So What? A Breach Notification Letter Readiness Checklist
Before the next incident — not during it:
- Do you have a pre-approved notification letter template? If your draft process starts from scratch when an incident is confirmed, you will be editing under deadline pressure with legal, communications, and senior management all inserting changes simultaneously.
- Does your template include all five California headings? “What Happened,” “What Information Was Involved,” “What We Are Doing,” “What You Can Do,” and “For More Information” — required by statute as of January 1, 2026.
- Does your template include all five HIPAA elements in plain language? If you handle PHI and your template requires a legal team to decipher, you have a readability problem that HIPAA specifically targets.
- Have you mapped which frameworks apply to your customer base? A single incident can simultaneously trigger the 2005 Interagency Guidance (for bank customers), HIPAA (for covered PHI), California § 1798.82 (for California residents), NY GBL § 899-aa (for NY residents), and SEC Reg S-P (for investment advisory clients). Each may require a separately tailored letter.
- Does your draft process have written criteria for “known vs. possible”? If the answer to “was this data stolen?” is currently “it depends on whoever drafts the letter,” you have a Flagstar/Pearson problem waiting to happen.
- Who corrects the initial notice if the investigation findings change? Blackbaud knew its initial notice was wrong within two weeks. The mechanism for updating a sent letter needs to be part of the process, not an improvised decision.
The Incident Response & Breach Notification Kit includes pre-built notification letter templates formatted to satisfy the 2005 Interagency Guidance, HIPAA, and California’s required headings; a state matrix cross-referencing deadlines, AG notification thresholds, and content requirements; and an incident notification decision tree that maps which frameworks apply based on data type and customer location. The template gaps that generate enforcement exposure are almost always structural — they’re fixable before the incident, not during it.
The companies in the cases above weren’t bad actors. They were organizations that hadn’t pre-solved the question of what a correct letter looks like. Some sent letters that technically described an incident but omitted what they already knew. Others sent something that looked like a notification but wasn’t one. The pattern is consistent enough that regulators have made notification letter content an enforcement category in its own right — which means it belongs in your incident response planning, not your post-incident reaction.
External references: 2005 Interagency Guidance on Response Programs for Unauthorized Access to Customer Information (70 FR 15736); HIPAA Breach Notification Rule — 45 CFR § 164.404; California Civil Code § 1798.82 (SB 446); FTC vs. Blackbaud, Inc. — Consent Order (2024); SEC Administrative Proceeding In the Matter of Flagstar Bancorp (File No. 3-22285)
◆ 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 must a breach notification letter include under the 2005 Interagency Guidance for banks?
What must a HIPAA breach notification letter include?
What specific content does California law require in a breach notification letter?
Does the FTC Safeguards Rule require sending notification letters to affected customers?
What have regulators charged companies for getting wrong in breach notification letters?
What is the deadline for breach notification and how does it vary by regulator?
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
AI-Powered BEC Stole $3 Billion in 2025: What Your Incident Response Playbook Is Missing
The FBI's 2025 IC3 report logged $3.046 billion in BEC losses—86% via wire or ACH—with AI now generating the emails, cloning the voices, and running the deepfakes. Most financial institution IR playbooks were written before this threat existed. Here's the gap analysis and what to add before the next one hits.
Jul 8, 2026
Incident Response
KYC in the Deepfake Era: Why Document + Selfie Verification Is Failing and What Actually Works
FinCEN's November 2024 alert formally put financial institutions on notice that AI-generated deepfakes are bypassing KYC onboarding at scale. Here's what's failing in the document+selfie stack, what examiners expect, and which controls are working in 2026.
Jul 5, 2026
Incident Response
Supply Chain Cyber Incident Response for Financial Institutions: Lessons from Marquis, MOVEit, and CrowdStrike
Supply chain attacks are now the top global cyber threat. When Marquis Software ransomware hit 74+ banks and credit unions, those institutions owned the regulatory response even though their own systems were never touched. Here's the incident response playbook for incidents you didn't cause.
Jun 30, 2026