Website Hacks and UK GDPR: When a Hack Becomes a Reportable Breach

A website hack is a personal data breach under UK GDPR when it leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Theft is not required. If an attacker could read your customer table, change order records or lock you out of them, that is a breach.

Many website owners assume that "no data was downloaded" means "no breach". The ICO's definition is broader. A breach covers three kinds of failure:

• Confidentiality breaches: personal data is disclosed to, or accessed by, someone who should not see it. A webshell with database access usually falls here.
• Integrity breaches: personal data is altered without authorisation, for example an attacker editing customer email addresses or injecting records.
• Availability breaches: personal data is lost or cannot be accessed, for example after ransomware or a wiped database with no usable backup.

By contrast, some hacks genuinely do not touch personal data. A brochure site with no forms, no user accounts and no logged personal data, defaced with SEO spam, may be a security incident without being a personal data breach. The point is that you have to establish which it is, with evidence, rather than assume.

The 72-hour rule comes from Article 33 of UK GDPR: a controller must report a personal data breach to the ICO without undue delay and, where feasible, no later than 72 hours after becoming aware of it. It applies unless the breach is unlikely to result in a risk to people's rights and freedoms. The clock includes weekends.

Three details matter in practice:

1. "Becoming aware" is the trigger. ICO guidance treats you as aware when you have a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. A brief initial investigation to establish that is expected, but you cannot delay the investigation to delay the clock.
2. You can report in phases. If you do not yet have the full picture, you can make an initial report within 72 hours and provide further information as your investigation progresses. If you report late, you must explain the delay.
3. Processors report to controllers. If you are a web agency or host processing data on a client's behalf, your duty is to tell the client (the controller) without undue delay, so that they can decide whether to report.

The ICO accepts breach reports through its online reporting service, and you can also call its helpline during opening hours. Check the ICO website for the current reporting routes before you need them, not during the incident.

You decide by assessing the likely risk to the people whose data was involved. If the breach is unlikely to result in any risk to their rights and freedoms, you record it but do not report it. If there is a risk, you report it to the ICO. If the risk is high, you also tell the individuals directly.

The assessment should consider the type of data, how sensitive it is, how many people are affected, whether the data was encrypted or otherwise unintelligible, and what harm could follow, such as fraud, identity theft, distress or financial loss. The table below shows how common website incidents often fall. Every case still needs its own assessment.

An ICO breach report needs a description of what happened, the categories and approximate number of people and records affected, the likely consequences, the measures you have taken or propose to take, and a contact point for more information. If you do not have everything within 72 hours, report what you know and follow up.

For a hacked website, that usually translates to:

• When the compromise started (the earliest indicator, not the day you noticed it) and when you became aware.
• The entry point, if known: vulnerable plugin, stolen credentials, compromised hosting account.
• Which systems and databases the attacker could reach, and whether there is evidence of access or exfiltration.
• The categories of data: names, emails, addresses, order history, hashed passwords, payment details.
• Containment steps: access revoked, malware removed, passwords rotated, vulnerable code patched.
• Whether you have told, or intend to tell, the affected individuals.

Answering these confidently depends almost entirely on the quality of your forensic evidence. That is why the order of your first actions matters.

Keep a copy of the compromised files, the web server and access logs, the database, and a timestamped record of every action you take. Take the snapshot before you start deleting things. Evidence lets you establish when the attack began, what the attacker touched, and whether personal data was actually accessed.

A rushed clean-up that deletes the webshell and restores an old backup often destroys the one log line that would have shown the database was never queried. That can push you towards reporting a breach as higher risk than it was, simply because you can no longer rule anything out. A minimal evidence capture on a Linux server looks like this:

# Snapshot the web root and logs before changing anything
tar -czf /root/evidence-$(date +%F-%H%M).tar.gz /var/www/example.co.uk /var/log/nginx /var/log/apache2 2>/dev/null
# Record file hashes so the evidence can be verified later
sha256sum /root/evidence-*.tar.gz > /root/evidence.sha256
# Look for requests to a suspected webshell
grep "wp-content/uploads/2026/07/cache.php" /var/log/nginx/access.log
198.51.100.23 - - [14/Aug/2026:02:11:09 +0100] "POST /wp-content/uploads/2026/07/cache.php HTTP/1.1" 200 5120
# Export the database for later comparison
mysqldump --single-transaction wp_example > /root/wp_example-$(date +%F).sql

PatientZero keeps this kind of record as standard. Every Forensic scan produces timestamped findings, removed files go into an evidence vault with their hashes, and the Reports and Activity log give you a plain-English timeline alongside the technical detail, which is the material you need when you are completing or updating an ICO report.

In the first 72 hours, contain the attack, preserve evidence, establish whether personal data was affected, decide whether the breach is reportable, and report it if so. Clean-up and root-cause work continue in parallel. Do not wait for a perfect investigation before making an initial report.

1. Contain. Put the site into maintenance, revoke unknown admin accounts and SSH keys, and change hosting, database and admin passwords from a clean device.
2. Preserve. Take a snapshot of files, logs and the database before removing anything.
3. Scope. Run a server-side forensic scan to find every webshell, backdoor and persistence mechanism, and identify what data the attacker could reach.
4. Assess. Decide the likely risk to individuals and whether the incident is reportable. Record your reasoning either way.
5. Report. If reportable, submit to the ICO within 72 hours of awareness, even if some details are still to follow.
6. Tell people if the risk is high. Explain in plain language what happened and what they should do, such as changing reused passwords or watching for phishing.
7. Clean and harden. Remove the malware, fix the entry point and harden the site so the same attack cannot repeat.

If you are dealing with this right now, our emergency team can start triage as soon as you get in touch, and our first-hour guide covers the immediate steps in more detail. For the clean-up itself, see hacked website repair.