A single missed deadline after a data breach can cost a small company more than the incident itself. Regulators can levy fines that dwarf the ransom, customers churn, and enterprise contracts pause. And the founder, still trying to figure out what got stolen, now has a legal clock running that most people misread from the first hour.
Founders don’t ignore breach-notification rules. They operate on a version of those rules assembled from headlines, vendor marketing, and half-remembered advice.
Four assumptions do most of the damage – let’s take a closer look at them.
Assumption: The 72-Hour Clock Starts When the Breach Happens
This one sinks companies before they’ve opened a ticket. The clock does not start when the attacker got in. It starts when your organization becomes aware that a personal data breach has occurred. Under Article 33, a controller must notify the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of the incident, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms.
Awareness here means a reasonable degree of certainty that personal data has been compromised, which is a different moment from the intrusion itself and from the day the full forensic report lands.
That distinction has a practical edge. The hours a founder spends huddled with an incident-response vendor, deciding whether the alert is real, are not free hours. Once the team has enough to say “yes, personal data was likely exposed,” the countdown is live, even if the scope is still fuzzy.
Assumption: You Have to Know Exactly What Happened Before You Notify
Waiting for a clean forensic picture is a common and expensive mistake. The rules were written on the assumption that you won’t know everything in 72 hours. That’s why phased notification exists: submit what you know, flag what you don’t, and update the regulator as the investigation matures.
A founder’s first notification can be genuinely thin. Approximate number of records, categories of data, what you’ve done so far to contain it, and who to contact for follow-up.
Regulators would rather see an honest, incomplete filing on time than a polished one that arrives late, and small companies that lean on outside counsel early tend to file cleaner first notices. If you need a starting point for the legal side, working with a law firm that handles business matters can help you triage whether the incident is reportable, and to whom, before the clock burns down.
Assumption: One Notification Covers Everything
The 72-hour rule people quote is the European one. It is not the only clock, and for most small companies, it will not be the only filing. A single breach can trigger overlapping obligations across:
-
State breach-notification statutes. Every U.S. state has its own law, with its own definition of personal information, its own timing, and its own rules about when the attorney general or credit bureaus have to be looped in.
-
Sector regulators. Health data, financial data, and children’s data each carry separate reporting regimes on top of general breach law. A HIPAA-covered vendor and a payment processor will not share deadlines.
-
Contractual obligations. Enterprise customers routinely require notice within 24 or 48 hours in their data-processing addenda. Miss that and the regulatory fine is the smaller problem; the indemnification clause is where the pain lives.
-
Public-company disclosure. Founders selling into public companies should know their customers may face their own SEC timelines the moment they learn the incident is material.
Map these before an incident, not during. That’s the difference between a coordinated response and five people writing conflicting emails at midnight.
Assumption: If You Don’t Have to Notify, You’re Done
Not every security incident triggers a notification requirement. The problem is that “we decided it wasn’t reportable” can be difficult to defend months later if nobody documented how the company reached that conclusion.
Keep a written record of what the team knew, when it knew it, what types of data were potentially involved, and why counsel or the response team concluded that a particular notification rule did or didn’t apply.
Under the GDPR, for example, controllers are required to document personal data breaches, including the facts surrounding the breach, its effects, and the remedial action taken. That record allows a supervisory authority to verify compliance even when notification wasn’t required.
The same discipline is useful outside Europe. An incident that looks minor on day one can change as forensic work uncovers additional systems, records, or affected individuals. A documented decision trail gives the team something concrete to revisit instead of reconstructing the first 72 hours from memory.
That means the incident file shouldn’t contain only the notifications that went out. It should also preserve the reasoning behind the ones that didn’t. Record the applicable rule, the facts available at the time, who made the decision, and when it was made. If the facts change, update the analysis along with them.
Assumption: The Founder Should Run the Response
In a five- or fifty-person company, the founder’s instinct is to grab the wheel. Do the opposite. The FTC’s breach response guide walks through the standard playbook (secure operations, assemble a team of forensic, legal, IT, and communications leads, fix the vulnerability, then handle notifications), and founders who try to do all of it personally miss steps that later show up in a regulator’s questions.
The founder’s job in the first 72 hours is smaller and more important: pick the incident commander, approve the notification decisions, keep a written log of what was decided and when, and stay off Slack channels where speculation will later be discoverable. Everything else belongs to someone whose full-time job is handling exactly this.
None of this is theoretical for a small company. The fines, the contract clawbacks, and the customer-notification postage add up long before the lawsuit does. Founders who come through a breach with their business intact are almost always the ones who understood, before the incident, that the clock was shorter and stranger than they thought.
