Your Website Was Hacked. Do You Have to Tell Your Customers?
By Glenn Lyvers · Updated · 6 min read
The honest answer is: it depends on what the attackers reached, not on the fact that you were hacked. A large share of website hacks — spam page injections, redirect schemes, defacements — never touch a byte of customer data, and cleaning them up quietly is both normal and fine. But if personal information your site held was exposed, notification stops being a judgment call: nearly every jurisdiction has laws requiring it, on deadlines measured in days.
I should say plainly that I'm not a lawyer and this isn't legal advice — when real customer data is involved, one conversation with a privacy attorney in your jurisdiction is worth more than anything on this page. What I can give you is the half I do professionally: how to work out, technically, which situation you're actually in. That's the part most owners get stuck on, and it's the part every legal obligation hinges on.
The question isn't "was I hacked" — it's "what did they reach"
Notification laws don't care about malware; they care about personal data. So the first job after any hack is an honest inventory of two things: what data your site collects and stores, and what the specific infection you had was capable of touching. A hack that rewrote your .htaccess to redirect Google visitors lives in a different universe from a hack that sat on your checkout page for two months. Same word, "hacked" — completely different obligations.
Hacks that usually aren't breaches
Most of what I clean falls here. SEO spam injections that stuff your site with pharmacy or gambling pages are after your search rankings, not your database. Redirect hacks monetise your traffic by bouncing it elsewhere. Defacements are vandalism for an audience. If your site is a brochure site — no accounts, no checkout, no stored form submissions — there is usually nobody to notify, because there was nothing personal to take. You still owe your visitors a clean site, and Google a prompt cleanup, but a public confession isn't part of the repair.
Two caveats keep this honest. First, "usually" is doing real work in that heading — an attacker who got in for spam purposes still had access, and if credentials or a customer table sat within reach, you can't assume they averted their eyes. Second, plenty of "brochure" sites quietly store more than their owners remember: form plugins that keep every submission in the database, newsletter lists, an abandoned WooCommerce install from a shop experiment two years ago.
Hacks that usually are
Some infections exist precisely to take customer data, and finding one changes the conversation immediately. A card skimmer on your checkout has one purpose, and if it ran for any length of time you should assume it succeeded. Phishing pages hosted on your site mean your server was used to steal from other people, some of whom may also be your customers. Database malware means the attacker was inside the store of record itself — and your database is where WordPress keeps every user account, order, and saved form submission. Malware that captures what visitors type into your forms rounds out the set. With any of these, work on the assumption that data was exposed and let the investigation talk you down, rather than the reverse.
Working out what was actually exposed
Four questions, answered honestly, settle most cases. What does the site collect — accounts, orders, form submissions, and crucially payment details, which on a well-built shop are held by Stripe or PayPal rather than by you, a distinction that dramatically narrows what a hack of your site can leak. Where does that data live, and did the malware's access overlap with it? What do the server logs show — bulk database exports and mass reads leave traces that a competent cleanup can find. And how long was the infection there, since a skimmer that lived on checkout for one afternoon and one that lived there for a quarter imply very different exposure? Establishing that timeline is a standard part of a professional cleanup, and it's precisely the evidence a lawyer will ask you for.
When the evidence is genuinely ambiguous — logs rotated away, infection date unknowable — the conservative reading is the defensible one. "We couldn't prove they took it" is a weak public position if the data later surfaces.
The rules, in broad strokes
In the United States, all fifty states have breach notification laws, each keyed to its own definition of personal information — typically a name combined with something sensitive like a card number, SSN or login credentials — with deadlines and thresholds that vary by state, and your customers' locations mattering as much as yours. If you serve people in Europe or the UK, GDPR expects a report to the regulator within 72 hours of discovering a qualifying breach, and notice to the affected individuals when the risk to them is high. If cards were skimmed, your agreement with your payment processor obliges you to report it to them promptly — and telling your processor is how the card networks limit the damage, so it protects your customers too. None of this is exotic, but the details are jurisdictional, which is exactly why the one-hour conversation with a privacy lawyer is the best money in this entire process.
If you do have to tell people, how to say it
Write like a person. Say what happened, when, what was and wasn't exposed, what you've done about it, and what — specifically — the recipient should do: change this password, watch that card statement. Resist the two temptations of breach letters: minimising ("out of an abundance of caution…") and boilerplate ("we take your security very seriously"), both of which customers have learned to read as their opposite. And don't announce before you've actually closed the hole; a notification followed by a second breach is the worst outcome available.
The cost of staying quiet
Owners who ask me whether they have to tell anyone are often really asking whether they can get away with silence. Set aside the ethics and it's still a bad bet: card fraud gets traced back to a common merchant by the banks' own pattern analysis, browser warnings and blacklists announce the hack to every visitor anyway, and regulators everywhere punish concealment far more harshly than they punish the breach itself. Customers, meanwhile, mostly forgive an honest "here's what happened and here's what we did". What they don't forgive is finding out from their bank.
If you're facing this decision right now, get the facts first — my first-hour guide covers preserving the evidence you'll need. The forensic half of the question, what the malware was and what it could see, is work I can do for you; a straight answer about what was actually exposed turns an anxious guess into a decision you can defend.
Common questions
My site was defaced but stores no customer data. Do I have to notify anyone?
Generally no. Breach notification laws are triggered by exposure of personal information, not by the hack itself. A defaced brochure site with no accounts, orders, or stored form submissions typically creates no notification duty — your job is to clean the site, close the entry point, and clear any browser warnings. Do double-check the "no stored data" assumption first, though: form plugins that keep submissions in the database catch many owners out.
Do contact-form emails count as personal data?
Names and email addresses are personal information under laws like GDPR, so stored form submissions are in scope in principle. Whether their exposure requires notification depends on the jurisdiction and the risk involved — an email list leak is treated less severely than card numbers or passwords, and many US state laws would not reach it at all. This is squarely a question for a privacy lawyer once you know, technically, what was actually accessible.
How quickly does GDPR require me to report a breach?
Within 72 hours of becoming aware of a qualifying breach, you must report to the relevant supervisory authority — and if the breach poses a high risk to the people affected, you must also inform them without undue delay. The clock starts at discovery, not at the intrusion, which is one reason establishing an honest infection timeline quickly matters so much.
Do I have to report a hacked website to the police?
You are usually not legally required to, and for ordinary website malware, police involvement rarely changes anything. In the US you can file with the FBI's IC3 (and in the UK, Action Fraud), which is worth doing if money was stolen or extortion is involved, and some insurers require a report as a claim condition. Regulatory notification and customer notification are separate obligations and are the ones with deadlines.
Will telling customers about a hack destroy their trust?
The evidence runs the other way: customers largely forgive a prompt, specific, honest notification, especially one that tells them exactly what to do next. What destroys trust is silence followed by discovery — fraud on their card traced back to your shop, or a browser warning on your checkout page. If notification is legally required, concealment also converts a survivable incident into regulatory penalties.