Website Hacked? UK Incident Response in the First 72 Hours
Steven | TrustYourWebsite · 15 May 2026 · Last updated: May 2026
The hours after discovering a website has been hacked are the most consequential. UK GDPR Article 33 puts the ICO notification clock at 72 hours from awareness. Article 34 may require direct notification of affected users. The technical work of removing the attacker, restoring service and preventing recurrence overlaps with the regulatory work of notifying, documenting and learning. This guide covers the first 72 hours of a UK SME website incident in order: triage, contain, notify, recover, document.
For a scan that detects residual compromise after cleanup, run a free check at /uk/en/scan.
Has the attack actually been cleaned up?
Our scanner checks for residual malware, unauthorised scripts, leftover admin accounts and security headers.
I understand this is a technical scan, not legal advice, and I accept the Terms.
Hour 0: confirm and triage
A reported compromise is not always a compromise. Before any external notification, confirm what actually happened.
Common confusion sources include browser warnings (often a TLS certificate issue, not an active hack), customer reports of unfamiliar charges (often credential stuffing against the customer's own reused password, not a breach of your site) and Google Search Console alerts (often a hosting-platform-wide issue rather than a single-site compromise).
Confirm using one of three signals. Direct evidence in your access logs of admin actions you did not authorise. Files on the server that you did not upload (PHP files in upload directories, modified theme files, foreign scripts in HTML). Unauthorised database changes (new admin users, modified pages, injected outbound links).
Once at least one of these is confirmed, the clock on Article 33 has not yet started, Article 33 starts when you become aware. "Aware" in ICO guidance means a reasonable degree of certainty that a security incident occurred that compromised personal data. A confirmed compromise that does not touch personal data does not start Article 33.
Hours 0-4: contain
The technical work in the first four hours has three goals: stop ongoing exfiltration, preserve evidence, restore the site to a clean state.
Take the site offline if needed. A maintenance page is preferable to leaving compromised pages serving customer requests. The maintenance page should not link to or include any third-party scripts that may also be compromised.
Rotate credentials. Every admin password, every API key, every database credential, every CDN account, every email-platform credential. Treat all of them as potentially exposed. Use a password manager to generate strong, unique replacements. MFA on every admin account that supports it.
Preserve evidence before deleting. Take a full snapshot of the server filesystem and database before any cleanup. Export access logs covering at least the 90 days before discovery. Note the timestamps and IP addresses of any unauthorised admin actions. The evidence pack will be needed for the ICO file, the insurance claim and Action Fraud.
Remove obvious attacker presence. Delete unauthorised files, remove unauthorised admin accounts, revert unauthorised page edits. This is triage not full recovery, assume the attacker has multiple footholds and that re-infection from a backdoor is possible.
Pull a clean backup. Identify the most recent backup that pre-dates the compromise. Verify the backup itself was not also compromised (timestamps, file integrity).
Hours 4-24: assess Article 33 scope
The Article 33 notification needs to describe: the nature of the breach, the categories and approximate number of data subjects affected, the categories and approximate number of personal data records affected, the likely consequences and the measures taken or proposed.
A holding notification with what is known so far is acceptable and common practice. The ICO does not expect a complete investigation within 72 hours. The holding notification typically covers:
What happened: when discovered, what is known about how access was obtained, what systems were affected. What personal data was exposed: customer records, order data, account credentials, special category data. Approximate numbers: even a rough range (1,000-10,000 records) is more useful than "unknown". What has been done: containment steps already taken, evidence preserved, third-party support engaged. What will be done: next investigation steps, expected timeline.
The ICO accepts notification via its online reporting form or by phone for urgent cases. Telephone notifications are followed up by the ICO with a written request for detail.
Hours 24-72: assess Article 34 scope
If the breach is likely to result in a high risk to the rights and freedoms of affected individuals, Article 34 requires direct notification of those individuals without undue delay.
<div className="my-6 overflow-x-auto"> <table className="w-full border-collapse text-sm"> <thead> <tr className="bg-slate-100 text-left"> <th className="border border-slate-300 px-3 py-2 font-semibold">Data exposed</th> <th className="border border-slate-300 px-3 py-2 font-semibold">Art 33 notification (ICO)</th> <th className="border border-slate-300 px-3 py-2 font-semibold">Art 34 notification (users)</th> </tr> </thead> <tbody> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Names and email addresses only</td> <td className="border border-slate-300 px-3 py-2">Usually required (risk of phishing)</td> <td className="border border-slate-300 px-3 py-2">Not usually required</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Hashed passwords (modern hashing)</td> <td className="border border-slate-300 px-3 py-2">Required</td> <td className="border border-slate-300 px-3 py-2">Recommended (password reset prompt)</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Hashed passwords (weak hash) or plaintext</td> <td className="border border-slate-300 px-3 py-2">Required</td> <td className="border border-slate-300 px-3 py-2"><strong>Required</strong>. Treat as credential exposure.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Payment-card data</td> <td className="border border-slate-300 px-3 py-2">Required</td> <td className="border border-slate-300 px-3 py-2"><strong>Required</strong>. PCI-DSS forensic investigation also triggered.</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Special category data (Art 9)</td> <td className="border border-slate-300 px-3 py-2">Required</td> <td className="border border-slate-300 px-3 py-2"><strong>Required</strong>. Likely high-risk under Art 34.</td> </tr> <tr className="bg-slate-50"> <td className="border border-slate-300 px-3 py-2 font-semibold">Children's data</td> <td className="border border-slate-300 px-3 py-2">Required</td> <td className="border border-slate-300 px-3 py-2"><strong>Required</strong>.</td> </tr> <tr> <td className="border border-slate-300 px-3 py-2 font-semibold">Defacement only, no data access</td> <td className="border border-slate-300 px-3 py-2">Not required (no personal data breach)</td> <td className="border border-slate-300 px-3 py-2">Not required</td> </tr> </tbody> </table> </div>Article 34(3) lets the controller omit direct user notification if appropriate technical measures (such as encryption) render the data unintelligible to the attacker. Encrypted data at rest where the key was not also compromised typically qualifies. The ICO can require notification under Article 34(4) even if the controller decides it is not required.
Action Fraud and police reporting
Action Fraud is the UK national reporting centre for fraud and cybercrime. Online reporting at actionfraud.police.uk generates a crime reference number. In Scotland the equivalent is direct reporting to Police Scotland.
Reasons to report alongside the ICO notification: the crime reference number is evidence for the insurance file, the report contributes to UK cybercrime intelligence, ransomware attacks (where decryption-key payment is being demanded) involve specific legal considerations the police can advise on and serious compromises sometimes attract direct law-enforcement support through the NCSC.
Action Fraud reporting does not replace the ICO Article 33 notification. The two are separate and parallel.
Hours 24-72: recovery, not just removal
Removal of the attacker is not enough. A compromised site needs full recovery before being trusted again.
Rebuild from a known-clean baseline. The cleanest recovery is a full reinstall from official sources (CMS core, themes, plugins) onto a fresh server, with database content restored from a verified pre-compromise backup. Patching a compromised live system is rarely sufficient because attacker persistence mechanisms are designed to survive cleanup.
Verify every account. Some attackers create dormant admin accounts as fallback. Audit every administrator, contributor and editor account. Disable any unrecognised account and require password reset plus MFA for every account that remains.
Audit every plugin and theme. Remove anything unused. For everything that remains, confirm the version is current and that the install came from the official source (not a re-uploaded copy from the compromised site).
Update all software. CMS core, plugins, themes, server-side language runtimes. Patch every CVE published before the discovery date.
Reissue all secrets. Every API key (Stripe, Mailchimp, Cloudflare, hosting), every database password, every SMTP credential. Treat as if every credential was leaked.
Re-deploy MFA on admin access. If MFA was not in place on admin accounts before the incident, it must be in place after. The absence of MFA on admin access is one of the most frequently cited Article 32 failings in ICO reprimands following a breach.
Hours 48-72: documenting for the ICO file
The ICO follow-up after a breach notification will ask for documentation. The controller's record of processing under Article 30 plus the incident-response timeline together form the file.
The incident-response timeline includes the timestamp of discovery, the timestamps of containment steps, the timestamp of the holding notification to the ICO, the timestamps of subsequent ICO communications and the timestamps of Article 34 notifications if relevant. Each step has the name of the person who took the action and the supporting evidence (screenshots, log extracts, communications).
The ICO is materially more lenient with controllers who can produce this record promptly than with those who cannot. Documenting in real time during the incident is the practical way to satisfy this.
After 72 hours: what the ICO actually does
Most SME-tier breach notifications result in an acknowledgment, follow-up questions and a closing letter. The ICO's published statistics show that the substantial majority of personal-data breach notifications close without formal enforcement action.
The breach files that escalate share three features: the underlying Article 32 security failing was elementary (unpatched plugin from 2018, no MFA, shared admin password), the notification was late or attempted to minimise the scope or the controller failed to engage promptly with the ICO's follow-up questions.
For the four-stage ICO investigation procedure that may follow, see the ICO investigation process.
Twelve-month follow-up
A serious breach has follow-on tasks beyond the initial 72-hour window.
Re-issue or refresh Article 30 records of processing for any system affected. Update the breach register required under Article 33(5). Review and update the data protection impact assessment (DPIA) if one existed for the affected processing. Refresh staff training on incident response. Re-test the recovery procedure (the breach is often the first real test of the backup-and-restore plan).
If the breach was material in customer terms, brand recovery work follows. Plain communication about what happened, what data was affected and what the business has done about it is the most consistent approach. Reputation damage from a breach is mostly proportional to how it was handled, not to whether it occurred.
For the underlying security baseline that the ICO expects, see UK GDPR Article 32: Website Security the ICO Expects. For UK GDPR fines that may follow, see UK GDPR fines under the ICO. For the broader compliance picture, see GDPR compliance for UK businesses.
This is technical analysis, not legal advice. If you are currently inside the first 72 hours of a breach, prioritise containment and ICO notification over reading further. Take advice from a UK data-protection specialist before sending any external communication about the breach.
Website Guides
UK GDPR Article 32: Website Security the ICO Expects
UK GDPR Article 32 explained. What ICO security expectations look like, NCSC technical guidance, encryption, access controls and the patch-timing rules.
ICO Investigation Process: What to Expect When the ICO Contacts Your Business
What happens when the ICO investigates your business. Information notices, 30-day response deadlines, formal investigations, fine decisions and appeal routes explained.
UK GDPR Fines Under the ICO: What Penalties Look Like in 2026
ICO fine bands under UK GDPR: up to £17.5M or 4% of global turnover. Marriott, BA and TikTok cases explained. What SMBs realistically face.