The malware is gone, or nearly gone, and a harder question arrives: do you have to tell anyone? Your customers, a regulator, your payment provider? Most small-business owners have never had to think about this, and the first search usually turns up legal language written for large companies with compliance teams.
This post is a plain-English map of who you may need to tell and why, written for owners in India, the USA, the UK and Europe. It is general information, not legal advice. The rules depend on where you are, where your customers are, and what data was involved, so for any real decision, speak to a lawyer who practises in that area.
First, work out whether personal data was touched
Notification duties are almost always about personal data, not about the website as such. A defaced homepage or a spam redirect is damaging and embarrassing, but if the attacker never reached information about people, many notification laws may not apply at all. That is not a reason to skip the question. It is a reason to answer it carefully.
Start with an honest inventory of what the site holds:
- Contact form entries. Many form plugins store every submission in the database: names, emails, phone numbers and whatever people typed in the message box.
- Customer accounts. A WooCommerce store or membership site keeps names, addresses, emails, order histories and hashed passwords.
- Payment details. Most small stores never store card numbers, because the payment gateway handles them. A checkout skimmer changes that, because it captures cards as they are typed, before they ever reach the gateway.
- Newsletter lists, booking records, job applications and uploaded documents. These are easy to forget and can be the most sensitive items on the server.
Then ask what the attacker could reach. An attacker with admin access to WordPress or access to the database could, in principle, read all of it. Someone who only planted a spam page through a file upload flaw may never have touched the database. Proving which is true is often hard. It usually takes a careful look at server logs, changed files and database records to say with any confidence how they got in, when, and what they could see. If the site is still being cleaned, the steps on our hacked website repair page come first, because evidence should be copied before anything is deleted.
Write things down from the start
Whatever the law turns out to require, keep a dated record as you go. Note when you first noticed the problem, what you saw, who you told, what was changed and when the site was cleaned. Keep copies of host emails, scan reports and screenshots.
Under several laws, the clock starts when you become aware of a breach, and regulators can ask how you reached your decisions. A simple running document written at the time is far more convincing than a reconstruction weeks later.
If you have customers in the EU or UK: GDPR
The EU’s General Data Protection Regulation applies to organisations in the EU, and it can also apply to businesses outside the EU that offer goods or services to people there. The UK has its own version, usually called the UK GDPR, which follows a very similar approach to breaches.
In broad terms, GDPR asks two separate questions after a personal data breach.
Telling the supervisory authority
The organisation in charge of the data (the controller) must notify the relevant supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach. If the notice comes later than that, it has to be accompanied by reasons for the delay. There is an exception where the breach is unlikely to result in a risk to people’s rights and freedoms, but you need to be able to justify relying on it, and keeping a record of the breach is still expected either way.
The supervisory authority is usually the data protection authority in the relevant country. In the UK, that is the Information Commissioner’s Office.
Telling the people affected
Where a breach is likely to result in a high risk to individuals, GDPR also requires telling those individuals without undue delay, in clear language. Exposed passwords, payment information or sensitive details usually push a breach towards the high-risk end. A list of email addresses from a newsletter sign-up form may be judged differently. The judgement belongs to the controller, which is why advice is worth getting.
If an agency or developer manages your site for you, they are typically acting on your behalf for this purpose and should tell you promptly about a breach they find. The decision to notify then sits with you.
If you have customers in the USA: state laws
The United States does not have one national data breach law for most businesses. Instead, every state has its own breach notification law, and they differ in what counts as personal information, when notice is required, who must be told and how quickly.
A few general patterns are common across many of them:
- The laws tend to focus on specific data, such as a name combined with a Social Security number, a driver’s licence number, or a financial account or card number with its security code. Some states include more categories, such as login credentials or health information.
- The rules generally follow where the affected person lives, not where your business is. A small shop in one state with customers across the country may have to consider several sets of rules at once.
- Some states also expect notice to the state attorney general or another agency, particularly when many residents are affected.
- Encrypted data is often treated differently, provided the key was not taken as well.
Industry rules can sit on top of state law. Health providers, financial firms and businesses with government contracts have their own obligations.
For a US business working with an outside technical team, it helps to separate the roles clearly. The technicians find and fix the problem and document what they saw. Your lawyer decides what that means under the laws that apply to you.
If you are in India: the DPDP Act and CERT-In
India’s Digital Personal Data Protection Act, 2023 sets out duties for organisations that decide how personal data is processed, which the Act calls data fiduciaries. Among them is a duty, when a personal data breach happens, to inform the Data Protection Board of India and each affected person, which the Act calls a data principal. The detail of how and when these notices are given is set out in rules made under the Act, so check the current position with an adviser rather than relying on a blog post.
India also has CERT-In, the Indian Computer Emergency Response Team, the national agency that handles cyber security incidents. It has issued directions on reporting incidents, and some organisations are required to report certain incidents to it. Whether and how that applies to a small business website is a question for your adviser.
If you are an Indian business that keeps a privacy policy on your site, read it again after a breach. What you promised customers about how you protect and handle their data matters here. Our article on keeping a website privacy policy current in India covers that page.
Card data: tell your payment provider
If there is any chance card details were captured, for example because a skimming script was found on your checkout page, contact your payment gateway or acquiring bank promptly. Card payments are governed by the card industry’s PCI DSS standard, and the businesses that accept cards agree to follow it through their contract with the payment provider.
The provider will tell you what it needs from you. It may also already know something, because banks sometimes spot a pattern of fraud on cards that were all used at one shop. Do not try to work out on your own which cards were affected and contact those customers directly before speaking to the provider. They may have a process you are expected to follow.
Skimmers are a specific problem with their own signs. If that is what you found, our credit card skimmer removal page explains what we check and why a store can look completely normal while one is running.
Other people who may need to know
- Your hosting company. They may have found the problem first. If not, telling them helps, because other sites on the same server may be at risk.
- Your insurer, if you have a cyber or business policy. Many policies expect early notice and may have their own requirements for how the incident is handled.
- Your own staff, particularly anyone whose WordPress or email login may have been taken.
- The police or a cyber crime cell, where money has been stolen, there is extortion, or your adviser recommends a report.
Writing to customers, if you decide to
If you do notify customers, a short, honest message works better than a long, defensive one. Whatever the law requires in your case, a good notice usually covers:
- What happened, in one or two plain sentences, without technical jargon.
- When it happened, or the period it may have covered, as far as you know.
- What kind of information was involved, and what was not.
- What you have done since: cleaning the site, closing the entry point, changing credentials.
- What they should do: change a password they reused elsewhere, watch their card statements, be careful of emails claiming to be from you.
- How to contact you with questions, through a channel you actually monitor.
That fifth point deserves care. After a breach, criminals sometimes send fake follow-up emails pretending to be the affected business. Tell customers you will never ask for their password or card number by email, and keep to that.
Avoid saying more than you know. “We have no evidence that card details were taken” is very different from “no card details were taken”, and only the first may be true. If the investigation is ongoing, say so, and promise an update.
Close the hole before you announce
Announcing a breach while the site is still compromised invites a second wave, both from the original attacker and from others who read the news. Cleaning, patching the entry point and changing credentials should normally be under way before customer notices go out, although that should not become a reason to miss any legal deadline that applies to you.
For a store, this is also when to check that orders, customer accounts and payment settings are intact, and that no one has changed the payout details in your gateway plugin. A store owner who skips this check can find that payments went somewhere else for days after the visible hack was cleaned.
Plan for it before it happens
The businesses that handle a breach calmly are usually the ones that thought about it beforehand. Knowing what data your site stores, where it lives, who your adviser would be and how you would reach customers takes an afternoon to work out. A short website security incident plan written in advance turns a frightening week into a list of steps.
Collecting less data also helps. Form entries kept for years, old customer accounts and unused plugins that log visitor details all add to what can be exposed. Deleting what you do not need is one of the few security measures that costs nothing, and it sits comfortably alongside the everyday security habits for small business sites that make a breach less likely in the first place.
If you are not sure whether customer data was reached, that is the question to answer before anything else, because every notification decision depends on it. Our hack investigation service produces a written account of what we find, which you can share with your lawyer, insurer or payment provider.
Next in this series: SEO Recovery After a Website Hack: Getting Traffic Back
