We had a data breach: the email a small business owes its customers, and how many days it has

A breach notice is not the apology you write after the investigation. It is one of the things the investigation has to produce, on a clock that may already be running. For a small shop or app, that means two jobs at once: contain the incident, and work out which people and authorities have to hear about it.

There is no single US deadline. California, Florida, New York and Washington put a 30-day outer limit on many notices, Ohio uses 45 days and Texas uses 60. Each statute has its own trigger, exceptions and starting event. The EU's 72 hours is a clock for notifying the regulator, not a blanket deadline for emailing every customer.

Start the notice clock sheet the day you learn of the incident. Do not start it the day the forensic report arrives.

The first hour: make a clock sheet

Open one incident record and write down five times: when the incident may have started, when it ended, when anyone first detected it, when the business became aware, and when you determined that a legally defined breach occurred. Those words matter. GDPR counts from awareness; Washington counts from discovery; Florida and Texas use a determination. Your lawyer may decide which event starts each clock, but the evidence for that decision has to come from your timeline.

Beside the times, list where each affected person lives, which exact data fields were involved, whether the data was readable or encrypted and whether the key was exposed. A list of 800 customers can become several notice groups: Florida residents whose login credentials were accessed, Texans whose payment data was acquired, and EU residents for whom the incident presents a high risk. One generic deadline pasted over all of them is not a compliance plan.

Contain the breach and preserve evidence at the same time. Revoke sessions and stolen keys, close the exposed storage, force the affected credentials to change, keep logs and record every action. The FTC's business guide warns against destroying forensic evidence while fixing the problem. If a service provider holds the data, read the contract too: a processor or vendor may owe the business a faster notice than the business later owes customers.

30, 45 and 60 days are outer limits, not waiting periods

This is a planning table for an ordinary private business, checked against the linked official sources on 6 November 2026. It is not a complete 50-state chart. Health, finance, telecom, education and other regulated data can bring separate rules, and law-enforcement delays and statutory exceptions are specific.

A deadline stated as 30, 45 or 60 days does not give permission to sit on a finished notice. All six state statutes in the table combine their outer limits with faster language or allow only specified delays. If the customer can reduce harm today by changing a reused password or freezing credit, day 29 is not the sensible target.

The threshold is not simply 'any hacked database.' Each law defines the people, data and event it covers. California's statute, for example, speaks of unencrypted personal information acquired or reasonably believed acquired, starts its 30-day clock at discovery or notification and permits specified delays. Washington has a risk-of-harm exception and special wording for credentials. New York's definition includes access and an email address paired with a password or security answer, while its 30-day clock runs from discovery. This is the point for privacy counsel, even for a small business: ask for a written matrix of residents, fields, trigger, deadline, authority and delivery method.

GDPR has two different clocks

Under GDPR Article 33, the controller reports a personal-data breach to the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware, unless the breach is unlikely to result in a risk to people's rights and freedoms. A late report explains the delay. If facts are missing, Article 33 allows information in phases without undue further delay.

Article 34 is the customer side. When the breach is likely to result in a high risk, the controller tells the affected people without undue delay, in clear and plain language. It is not worded as 'within 72 hours.' The notice describes the nature of the breach and gives a contact, likely consequences, and the measures taken or proposed to address and mitigate it. Encryption that made the data unintelligible, later measures that removed the likely high risk, or disproportionate effort can change the direct-notice duty under Article 34, but they are not shortcuts to assume on your own.

The UK's ICO gives small organisations a useful operating rule even outside the UK: start a breach log immediately, report the initial facts before 72 hours if the regulator threshold is met, then follow up. Waiting for a polished root-cause report is how a manageable incident becomes a late notification.

The email needs six facts

1. What happened. Give the known incident and discovery dates, or an estimated range. Say 'an unauthorised person accessed' if access is what logs prove; say 'downloaded' only if you know that.

2. Which of this person's data was involved. Name the fields: email address, salted password hash, order address, last four card digits. Do not hide behind 'some information.' Do not list fields that were not in this person's record.

3. What could happen. Connect the data to the plausible harm: credential stuffing, phishing that knows an order number, account takeover or identity theft. Avoid both panic and 'there is no risk.'

4. What you did. State completed actions: revoked sessions, reset keys and closed an exposed bucket, plus the investigation still under way. An aspiration such as 'we take security seriously' is not an action.

5. What the person should do. Make it specific and ordered. If a password was involved, reset it here and anywhere it was reused, then review sessions. Our guides to the password-reset email and new-device alert show the safe link and account-event details people expect. If a Social Security number was involved, use the FTC's credit-freeze and IdentityTheft.gov guidance instead.

6. A real contact and update channel. Give a monitored email address or phone number, hours if relevant, and the page where dated updates will appear. Say how you will contact them next so a breach-themed phishing email is easier to spot.

A template that leaves room for facts

Subject: Notice about a data breach at [Company]

Hello [first name],

We are writing because an unauthorised person [accessed/downloaded] information in your [Company] account. We discovered this on [discovery date]. Our investigation indicates that the access happened between [start date/time] and [end date/time].

What information was involved
The information in your record was: [specific fields for this person]. [State clearly which sensitive fields were not involved, only if verified.]

What we have done
We [revoked sessions/changed keys/closed the exposed system] on [date/time]. We have [engaged an investigator/notified the relevant authority] and are continuing to investigate. As of [date/time], [state what is actually known about misuse, without promising that none can occur].

What you should do now
1. [First action, with a typed company-domain URL as well as any button.]
2. [Second action matched to the exposed data.]
3. [What activity to watch, and for how long if known.]

We will post dated updates at https://[your-domain]/security/[incident]. We will [say whether you will email, mail or call] about this incident; we will never ask for your password or one-time code.

Questions: [monitored email/phone], [hours and time zone].

[Named person]
[Role], [Company]

Have counsel adapt the template to each applicable law before sending it. Florida, for example, expressly asks for the date or estimated date range, a description of the personal information and a way to contact the business. Washington requires plain language, company contact information, the data types and the exposure time frame if known; credit-reporting-agency contacts are added when the covered personal information calls for them.

What not to write

- 'Out of an abundance of caution.' It wastes the first sentence and can make a required notice sound optional. Say why this person is receiving it.
- 'Your data may have been impacted.' Name the data and the proven event. 'Impacted' tells the reader nothing.
- 'We found no evidence of misuse' without a date and scope. Logs may show no misuse observed as of 4 p.m.; they cannot prove misuse will never happen.
- 'The issue is fully resolved' while access, copies or downstream risk remain unknown. Say what was closed and what is still being investigated.
- A password-reset link on a lookalike domain. Put the company-domain path in text so a cautious reader can type it. Never ask for the old password or a one-time code in reply.
- Legal argument and blame. Customers need facts and actions, not an essay about a vendor or a definition of liability.
- Every detail of the defence. Do not publish information that creates another security risk; the FTC specifically warns against that.

Send one email per person

Do not paste the affected list into To, CC or Bcc. One wrong click creates a second disclosure, and Bcc still forces every recipient into the same wording. Generate one message per person from the reviewed notice version and a per-person data list. That also lets you say 'your email address and password hash' to one customer and 'your delivery address' to another, instead of frightening both with a catalogue of everything in the database.

Before the full send, deliver test messages to accounts you control and check the From domain, Reply-To, links, mobile layout and plain-text part. Keep a send ledger with recipient ID, jurisdiction, notice version, channel, request timestamp, the API's returned id and status, and any retry. A 'sent' response records that the request was accepted; it is not a delivery or bounce report. Restrict the ledger like incident data so it does not become a convenient new breach list.

If the breached credentials belong to the email account itself, do not blindly send the warning to that compromised inbox. Washington expressly requires another permitted method in that situation. More generally, match the channel to the threat: postal mail, an in-app notice after a safe sign-in, or another verified address may be needed.

A worked 24-hour plan for a 900-person breach

Suppose a shop learns at 10:00 Monday that an exposed export contained 900 customer names, email addresses and password hashes: 220 Florida residents, 280 Texas residents, 80 Ohio residents, 70 Washington residents and 250 elsewhere, including 40 in the EU. By noon it closes the exposure and revokes sessions. At 14:00 it has reliable resident and field lists but does not yet know whether the file was downloaded.

- Monday 10:00: record awareness/discovery/determination candidates; preserve logs; start the resident/data matrix.
- Monday 12:00: contain access, revoke sessions and keys, force password resets for the affected accounts.
- Monday 14:00: counsel checks triggers. Florida is below its 500-person department threshold but its person-notice rule may still apply. Texas is at least 250, so its 30-day Attorney General clock matters even though its outer person-notice cap is 60 days. Washington is below the more-than-500 AG threshold, but affected-person notice can still apply. The 40 EU records require a rights-and-freedoms risk assessment; the authority report may be due within 72 hours even though the person notice uses the high-risk test.
- Monday 17:00: produce notice groups by fields, place and channel; legal review starts on the exact facts, not a blank template.
- Tuesday 10:00: send the initial GDPR authority report if required rather than waiting for the download question; supplement later. Test each person-notice version and prepare the send ledger.
- Tuesday 14:00: send to people as soon as the duty and facts are settled. The 30/45/60-day numbers are backstops, not target dates.

The short version

- Start a timestamped incident record immediately.
- Split affected people by residence and exact data fields.
- Treat 30 days in California, Florida, New York and Washington, 45 in Ohio and 60 in Texas as outer limits, never a universal US rule or a reason to wait.
- Under GDPR, 72 hours is the qualifying regulator report; high-risk notice to people is without undue delay.
- Tell each person what happened, their data, likely consequences, completed fixes, their next actions and a real contact.
- Send one reviewed message per person and keep a restricted delivery ledger.
- Use privacy counsel for the trigger and jurisdiction matrix; sector rules can be faster.

Sources

- GDPR Articles 33 and 34, official EUR-Lex text
- ICO: 72 hours: how to respond to a personal data breach
- FTC: Data Breach Response: A Guide for Business
- Florida Statutes § 501.171
- Washington RCW 19.255.010
- Ohio Revised Code § 1349.19
- Texas Business & Commerce Code § 521.053
- California Civil Code § 1798.82
- California SB 446, chaptered text
- California Attorney General: Data Security Breach Reporting
- New York General Business Law § 899-aa
- New York Attorney General: SHIELD Act
- NCSL map of US security-breach notification laws

Laws and guidance checked 6 November 2026. This article is a drafting and triage guide, not legal advice. Have a qualified lawyer apply the current laws and sector rules to the incident before deciding whether, when and how to notify.