Breach Notification After a Website Hack

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Most hacked websites are a technical problem and nothing more. Some are a legal one as well, and the difference comes down to what the attacker could reach. This is an orientation to the questions that matter and the framework for thinking about them — it is not legal advice, and if the answer looks like yes, get some.

What turns a hack into a breach

Personal data being reachable. Not necessarily proven stolen — reachable. If the compromise gave someone access to your database and that database holds names, email addresses, physical addresses, phone numbers, account credentials or payment details, you are in the territory where notification rules apply.

A site with no user accounts, no customer records and no form submissions stored in the database is a much simpler situation: injected spam on a brochure site is a technical cleanup with no data dimension. The first question to answer, therefore, is not what was taken but what was there.

Reachable versus stolen

This distinction causes more confusion than anything else in the subject. People wait for proof that data was exfiltrated before considering notification, and that proof almost never arrives — copying a database leaves no trace, and typical shared hosting logs will not show you the contents of requests.

Regulatory frameworks generally recognize this and work from access rather than proof of exfiltration. If an attacker had database access, the working assumption is that the data was compromised. My guide on preserving evidence matters enormously here, because the logs and timestamps you keep are what let you establish scope and duration at all.

Who you may need to tell

Potentially several parties, and the obligations run in parallel rather than as alternatives. Regulators, where a supervisory authority governs data protection in your jurisdiction, frequently on a short clock measured in days. The individuals affected, where the risk to them is significant. Your payment processor and acquiring bank if card data was involved, which is usually contractual and immediate.

Also potentially: business customers whose data you hold as a processor on their behalf, your cyber insurer if you have a policy, and in some sectors a specific regulator with its own rules. My guides on telling customers after a hack and PCI compliance after a skimmer cover two of those in detail.

Timing and why it is tight

Notification deadlines are commonly short and they typically start from when you became aware, not from when you finished investigating. That has a practical consequence people miss: you may need to report before you fully understand what happened, with an initial notification followed by updates as you learn more.

So do not treat the investigation and the notification as sequential. Start establishing scope immediately — what data existed, when access began, how long it lasted — because those are exactly the facts a notification requires, and the clock does not pause while you work them out.

Why I cannot tell you the answer

Because it depends on where you are, where your customers are, what sector you operate in, what data you hold, and what contracts you have signed. European and UK data protection law, various US state laws, sector-specific rules and payment card requirements all differ in trigger, timing and content.

What is consistent is the structure: identify what data was reachable, establish the window, determine the risk to individuals, and check your obligations against that. If personal data was in scope, spend the money on an hour of qualified legal advice — it is cheap relative to getting this wrong, and the answer is genuinely jurisdiction-specific.

What to do now

Preserve everything before you clean, because you cannot reconstruct the timeline afterwards and the timeline is what the notification depends on. Establish what data the compromised system held. Determine when access began and how long it lasted, using your access logs and file timestamps.

Then get advice if personal data was reachable, and do not delay the technical cleanup while you sort out the legal side — they run in parallel. Getting the cleanup done properly, with a clear record of what was found and when, is what my malware removal service provides, and that record is exactly what the rest of the process needs.

Common questions

Does every hacked website need to be reported?

No. A site with no personal data — no user accounts, no customer records, no stored form submissions — that gets spam injected is a technical problem with no notification dimension. The obligations attach to personal data being reachable, not to the fact of a compromise.

Do I need proof that data was actually stolen?

Generally not, and waiting for it is a mistake. Copying a database leaves no trace, so that proof rarely exists. Regulatory frameworks tend to work from whether data was accessible, which means an attacker with database access is usually treated as having compromised the data.

How long do I have to report?

It varies by jurisdiction and is often short — days rather than weeks — and typically runs from when you became aware rather than when you finished investigating. That is why establishing scope quickly matters, and why an initial report followed by updates is a normal pattern.

Who do I have to notify?

Potentially a data protection regulator, the affected individuals, your payment processor and acquiring bank if card data was involved, any business customers whose data you hold on their behalf, and your insurer. These run in parallel, and which apply depends on your jurisdiction and sector.

Should I wait until the cleanup is finished before reporting?

No. The technical cleanup and the notification process run in parallel, and notification clocks generally do not pause while you investigate. Start establishing the facts a notification needs — what data, when, how long — as part of the response rather than after it.