A data breach at your directory: what U.S. law actually requires you to do next
The breach is not the violation. The response is.
A database gets pulled, a misconfigured storage bucket gets found by a researcher, an employee's laptop with an unencrypted export goes missing. None of that alone is what turns into a regulatory case. What turns a breach into a case is what the operator does in the days after: how fast the affected people are told, what was promised to them before the breach happened, and whether the company can show it had reasonable safeguards in place. Regulators and plaintiffs' lawyers both read the response, not just the incident, because the response is where negligence either gets confirmed or ruled out.
This matters more for an adult classifieds directory than for most other small businesses, for a reason that has nothing to do with the platform's subject matter and everything to do with what it stores. A typical account record combines a real name, an email, a phone number, a payment method, and often a government ID scan collected for age or identity checks. Any one of those is a routine data element on its own. Together, tied to an account on a site whose purpose is not secret, they are the kind of dataset that turns a routine breach notice into a story, and turns state regulators from a formality into an active party.
The reputational risk and the legal risk are not the same thing, and conflating them leads to bad decisions in both directions. A breach that never triggers a legal notification requirement can still damage a directory badly if advertisers hear about it from a forum post instead of from the company. A breach that does trigger every notification requirement in the book can still leave the business standing, if it is handled the way the law expects. Planning for one of these risks without the other misses half the problem.
The operator who treats a breach as purely a technical incident, something for the hosting provider or the developer to patch and move on from, is the one who ends up explaining to a state attorney general six months later why nobody sent a notice. The legal clock does not wait for a root-cause analysis, and neither does the exposure it creates.
The clock starts before you are sure
Every U.S. state, plus the District of Columbia, has its own breach notification statute, and none of them wait for certainty. The trigger is not proof that data was misused, or even proof of exactly which records were taken. It is a reasonable belief that personal information was accessed or acquired by someone unauthorized to have it. Waiting for a forensic firm to produce a complete, defensible list of exactly which records were touched before telling anyone is the single most common way operators turn a bad week into a legal problem, because most state laws now put a hard number on how long that wait can last.
The trend since 2025 has been toward fixed deadlines, not vague ones. California's updated law, in effect from the start of 2026, requires notice to affected individuals within 30 calendar days, and a separate notice to the state attorney general within 15 days of that, once more than 500 California residents are involved. Colorado, Florida and Washington also hold operators to a 30-day clock. A cluster of other states, including Ohio, Arizona, Rhode Island and Wisconsin, allow 45. A smaller group stretches to 60. Roughly twenty states now use a specific number of days rather than the older, softer language of "without unreasonable delay," and that number keeps shrinking as states revise their statutes, not growing.
For a directory with advertisers in more than one state, and nearly every directory has that, each affected person's home state sets its own clock, and the shortest one that applies to your incident is the one that governs your actual deadline. There is no general federal breach law that overrides this for an ordinary business; healthcare and financial-services companies answer to their own federal regimes, but a classifieds operator is squarely inside the state-by-state system. The practical result is that a breach touching residents of five states means five sets of deadlines running at once, and the earliest one decides how much time there actually is.
Who gets told, and at what size it stops being optional
Individual notice is the baseline, but it is not the only notice most states require. Once the number of affected residents in a given state crosses a threshold, commonly 250, 500 or 1,000 depending on the state, the law also requires notifying that state's attorney general, and the notice usually has to describe what happened, what data was involved and what the company is doing about it. This is not a form that quietly disappears into a filing cabinet. State AG offices publish breach notices, several maintain searchable public databases of them, and journalists who cover the adult industry check those databases as a matter of routine.
A handful of states also require notifying consumer reporting agencies once the number of affected residents passes a set count, so that credit bureaus can flag accounts for extra scrutiny. That requirement exists independently of whether financial data was involved, because names, addresses and dates of birth are enough on their own to enable identity theft.
Building the notification list is its own operational problem, and it is worth solving before an incident rather than during one. An operator who has never mapped which states its advertiser base actually lives in finds out for the first time, mid-breach, that residents are spread across a dozen jurisdictions with different deadlines, different thresholds and different required content for the notice. A billing address on file is usually enough to sort users by state; the point is to have that sort ready to run in an afternoon, not to build it from scratch while the 30-day clock in the fastest state is already running.
None of this is a step an operator gets to skip by deciding the exposure was minor. The determination of what counts as personal information triggering notice is set by statute, not by the operator's own judgment about how bad the leak actually was. A directory that talks itself into treating a leak as "just emails" when the same dataset also included physical addresses or ID numbers is making a legal judgment it has no authority to make, and one that a regulator will re-make for it later, on worse terms.
What "reasonable security" cost one operator $1.6 million to learn
The clearest precedent for what happens when an adult platform gets breached and mishandles the response is Ashley Madison. After its 2015 breach exposed roughly 36 million user profiles, the FTC and a group of state attorneys general did not build their case only around the fact that a breach happened. Breaches happen to well-run companies too, and regulators know that. The case rested on two things a company can control: whether it had reasonable security safeguards for the sensitive data it collected, and whether what it told users about that security was true. The company had told users their data would be kept confidential and offered a paid feature promising to fully delete an account, claims the FTC alleged were false. The settlement, reached in December 2016, ran to $1.6 million plus a mandated, ongoing data security program with independent third-party assessments.
The lesson for a much smaller directory is not the dollar figure, which scales with the size of the company and the number of records. It is the theory. The FTC's authority to act on "reasonable security" is not limited to companies that suffered an unusually large breach, and it is not limited to industries with their own specific security statute. It is a general tool the FTC applies whenever a company's data practices don't match what it told users, or fall short of security a reasonable operator in that position should have had. A directory that promises anonymity, encryption, or "bank-level security" in its terms of service or its marketing, and then cannot show it actually had comparable protections in place, has built a deception claim into its own homepage before any breach even occurs.
Regulators also treat the category of data at stake as part of what "reasonable" means, not just the volume of it. Sexual behavior and orientation data sit in the same sensitive bracket as health and financial information in the FTC's own enforcement practice, and a directory's account records touch that bracket by definition, whether or not the listings themselves are explicit. A security lapse that would draw a warning letter at a general e-commerce site is more likely to draw an actual case at a site built around that category of information, because the harm a leak can cause the people in it is correspondingly higher.
The practical fix is not to stop making any promises. It is to make only the ones the platform can actually back up, and to treat every claim about privacy or security on the site as something a regulator might one day ask the operator to prove, not just advertise. The same discipline applies to how long identity documents collected during verification are kept; a leak of years-old ID scans nobody needed anymore is exactly the kind of unforced error that turns what happens to an ID scan after verification from an internal housekeeping question into the headline of the breach notice.
What has to exist before the breach, not after
An incident response plan is not a document that gets written the week something goes wrong; by then it is a symptom of the problem, not a fix for it. It has to exist in writing before an incident, naming who makes the call to notify, who drafts the notice, and which outside counsel gets the first call. Waiting until the breach to find an attorney who understands state notification timelines is how a 30-day clock loses a week to nothing but figuring out who to call.
Notification templates should exist in draft form for the states where the bulk of the advertiser base lives, built around the required elements each state's statute actually asks for: what happened, what categories of data were involved, what the company is doing in response, and what the recipient can do to protect themselves. Building that template during an active incident, under a deadline, is how avoidable mistakes make it into a document a regulator will read closely.
Cyber insurance is worth checking specifically for breach response coverage, not assumed to be included in a general liability or even a general cyber policy; the costs of notification, credit monitoring offers and forensic investigation are frequently excluded or capped in ways that surprise operators only when a claim is filed, and a standard policy leaves more gaps than most operators expect. The time to learn what a policy actually covers is during the renewal conversation, not during the incident.
The single worst response to a breach is silence followed by a quiet patch. Fixing the vulnerability without telling anyone does not stop the clock the law already started running, and if the breach becomes public through another channel first, a regulator's first question is no longer about the vulnerability. It is about why the company knew and said nothing. An operator who tells affected users promptly, accurately, and without overstating what was actually taken is the one who walks away from a bad week with a fine, if any, instead of a five-year case file.
