Breach Notification

Companies used to keep leaks to themselves. Saying nothing looked like the cheaper option: a news story costs customers, while a quietly patched hole costs nothing visible. So most leaks surfaced months later, when someone noticed a stranger logged into their account and worked backwards from there.

The damage happened during those silent months. If usernames and passwords went out the door, every other service where that person reused the password falls next. If phone numbers went out, fake messages start arriving that name the company the person actually trusts. The people affected can't react, because the one fact they need — that their data is loose — is the fact only the company has. Every bit of that second-round damage was preventable while the company sat on the information.

Privacy regimes closed the gap by making disclosure a legal duty rather than a business decision. A clock starts when the company becomes aware of the incident, and missing the deadline is its own violation, separate from whatever caused the leak. A small leak reported on time now costs a company far less than a small leak reported late, which is exactly the incentive the rules were built to create.

The clock starts when you become aware, not when the leak happened. If something was breached three months ago and you find it today, today is hour zero. The reverse trick doesn't work either — you can't postpone awareness by saying nothing is certain yet. Reasonable suspicion that data got out is enough to start counting.

1. Detect and contain. Confirm the suspicious access or the file that went to the wrong place, then close the route before anything else. Revoke the open permission, rotate the exposed access key, and take the feature down for a while if that's what it takes.
2. Size it. Work out which fields went out and for how many people. An email address alone and a national ID number lead to different obligations, so this step decides most of what follows. When the logs aren't there, this is where days disappear.
3. Report to the regulator. File within 72 hours of becoming aware. You will not have the full cause by then, and you file anyway with what you have and supplement later. The 72 hours is time to disclose, not time to finish the investigation.
4. Notify the people. Tell each affected data subject — the person the data belongs to — what fields were exposed, when, what the company has already done, what they should do now, and where to ask questions. When you have no way to reach someone individually, post the same notice somewhere public.
5. Remediate and record. Force password resets or whatever else limits the harm, and write down what you knew at each hour and what you decided. The question a regulator asks later is not whether you were breached but when you knew and what you did that day.

Above a certain number of records, or when sensitive fields are involved, the procedure gets heavier and extra filings apply. That is why step 2 has to move fast.

No single person can run this, and the roles split cleanly by hour. The legal obligation itself sits with the data controller — the company that decided why the data was collected. Running the servers through a vendor doesn't move the duty anywhere.

1. Engineering, hour 0 to 24. Close the route, then read the logs and count what actually left. Every later decision rests on that count, so nothing else can start until it exists.
2. Legal, hour 24 to 48. Decide whether this meets the reporting threshold, which authority receives the filing, and what the notice has to say.
3. The founder or executive owner, by hour 48. Decide whether to take the service down and what the company says publicly. Leave it open and the working team stalls.
4. Customer support, from just before the notice goes out. The moment notification emails land, questions arrive in volume, so the answers have to be agreed in advance.

Assembling this lineup on the day of the incident burns the 72 hours in meetings. That's what an incident response plan is for — it names the owner of each step before anyone needs it.

"If we log awareness as yesterday afternoon, the 72-hour deadline is tomorrow night."

The clock is already running, so plan backwards from the deadline.

"Root cause isn't done. Let's file what we know now and supplement after."

Waiting for certainty blows the deadline, so a first filing goes out regardless.

"Are we sure it was only email addresses? We can't write that until the logs confirm it."

What goes in the notice has to be backed by records, not by a reasonable guess.

At Pagedeck the real incident wasn't an attack — it was a misconfiguration. During a change to link-sharing permissions, a set of documents was open to anyone with the URL for about an hour, and Theo spotted external requests in the access logs. Mia wrote down the exact time of discovery, and Theo pulled a list of which documents were exposed and which ones outsiders actually opened.

Grace started with whether this even counted as an incident. The deciding question was whether anyone outside had opened the documents, and because the logs showed they had, the team filed. Support questions spiked once the notification went out, but since the message led with what was exposed, when, and what the company had already changed, very few accounts cancelled.

The first assumption is that a breach means an attacker broke in. The word travels with hacking stories, so that reading comes naturally. In practice the trigger is that data became visible to someone without authorization, whatever the cause. Sending a customer list to the wrong company counts. Sending a bulk email without hiding the recipients, so everyone can read everyone else's address, counts. A former employee's account still working and still pulling records counts. Treating any of these as a simple mistake is how a company blows the deadline and then finds out months later from a customer question — at which point the silence is a bigger problem than the incident.

The second is the old instinct that disclosure only creates harm, so it's better to fix things quietly. It looks true on the day. But failing to report within the deadline is a separate ground for enforcement, and the regulator measures from when you knew, not from when you chose to speak. If the silence comes out later, the subject shifts from how you handled an incident to why you hid one, and at that point the gap between what your privacy policy promises and what you actually did gets examined too.