Fixing a Missing Data Breach Response Plan
A personal data breach is any security incident that leaves personal data lost, destroyed, changed, disclosed or accessed without permission. On a website that might be a hacked plugin, a form that emails enquiries to the wrong address, or a backup left public.
The UK GDPR gives you 72 hours from becoming aware of a reportable breach to tell the ICO, which is very little time to invent a process. This guide helps a small business write a short, practical plan in advance, so that on the day you know who does what, how to judge the risk and what to record.
- Before you start: this is not legal advice
- What counts as a personal data breach
- How the 72-hour clock works
- Judging the risk: report, tell people, or just record
- The fix, step by step
- Common website breaches and what to do first
- A breach log you can copy
- Making breaches less likely and easier to handle
- Questions and answers
Before you start: this is not legal advice
This guide explains the breach rules in the UK GDPR in plain English and suggests a practical way to prepare. It is not legal advice. If a breach involves health information, financial details, children, or a large number of people, or you are unsure whether you must report it, take advice from a solicitor or data protection specialist and read the ICO's current guidance on personal data breaches. The ICO also runs a helpline that small organisations can call.
The duties described here come from Articles 33 and 34 of the UK GDPR, read with the Data Protection Act 2018. The Data (Use and Access) Act 2025 amends parts of the UK regime and is being brought into force in stages; check the ICO's guidance for any change to breach handling that affects you rather than relying on older articles.
What counts as a personal data breach
A breach is not only a hacker stealing a database. The legal definition covers any breach of security that leads to personal data being accidentally or unlawfully destroyed, lost, altered, disclosed without authorisation, or accessed without authorisation. Security people often group these into three kinds.
| Kind | What it means | Website examples |
|---|---|---|
| Confidentiality | Someone sees data they should not. | A contact form sends enquiries to a former employee's mailbox; an order export is uploaded to a public folder; a newsletter goes out with every address in the To line. |
| Integrity | Data is changed without permission. | An attacker edits customer delivery addresses; a faulty import overwrites account details with another customer's. |
| Availability | Data is lost or cannot be reached. | Ransomware encrypts the server and there is no working backup; a hosting account is deleted and customer records go with it. |
An incident can be more than one kind at once. Ransomware often both locks the data and copies it out first. A breach also does not need a criminal: sending one customer's invoice to another customer is a breach, and so is losing an unencrypted laptop that holds a copy of the mailing list.
Not every security incident is a personal data breach. A denial-of-service attack that takes the site offline for an hour, with no data touched, is a security incident but may involve no personal data at all. Your plan should still log it, because what looked harmless on day one sometimes turns out to have exposed data later.
How the 72-hour clock works
The UK GDPR says you must report a personal data breach to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people's rights and freedoms. Several details trip people up.
- Hours, not working days. The 72 hours run through evenings, weekends and bank holidays. A breach you discover late on a Friday needs a decision before Monday evening.
- "Aware" means reasonably certain. The ICO's guidance treats you as aware once you have a reasonable degree of certainty that a security incident has led to personal data being compromised. A short initial investigation to establish that is expected, but you should not delay it on purpose.
- You can report in stages. If you do not yet know everything, report what you know within the deadline and send more information as your investigation continues. A late report must explain the reasons for the delay.
- Processors report to you, not the ICO. If your hosting company, email platform or developer suffers a breach involving your data, they must tell you without undue delay. Your clock then starts, so your contracts and contact details need to make that possible.
Judging the risk: report, tell people, or just record
The decision you make in the first day or two comes down to one question: how likely is it that the breach will harm the people whose data is involved, and how badly? The answer puts the breach into one of three outcomes.
| Risk to people | What you must do | Example |
|---|---|---|
| Unlikely to result in a risk | Record it in your breach log with your reasoning. No report. | An email with a single customer's name and order number goes to the wrong colleague inside the business, who deletes it straight away. |
| Likely to result in a risk | Record it and report to the ICO within 72 hours. | A compromised plugin exposes the names, email addresses and order histories of several hundred customers. |
| Likely to result in a high risk | Record it, report to the ICO, and tell the affected people without undue delay. | Passwords, full addresses and dates of birth are copied, or a card-skimming script runs on the checkout. |
Factors that push the risk up include: the type of data, especially health, financial details, identity documents, passwords or information about children; the number of people; how easy it is to identify them; whether the data went to someone known and trustworthy or to an unknown attacker; whether it was encrypted with a key that was not also taken; and what could realistically happen to the people, such as fraud, identity theft, embarrassment, discrimination or physical danger.
Encryption matters a great deal. If a laptop is stolen but its disk was encrypted and the password was not with it, the risk to people may be low. If the attacker also took the key, the encryption does not help.
The fix, step by step
Step 1
Define what counts as a breach for your business
Open a short document titled breach response plan and list the personal data your business actually holds: website form entries, customer orders, newsletter subscribers, staff records, invoices and anything in shared drives. Under that list, write six or seven realistic examples of how each could be exposed, lost or changed, such as a misdirected email, a hacked admin account or a public backup file, so that staff recognise a breach when they see one.
Step 2
Name who acts and who decides
Write down one person who leads a breach response, one deputy for holidays, and who makes the final decision on reporting. Add phone numbers that work out of hours, plus contacts for your hosting company, website developer, email platform, payment provider, insurer and any solicitor. Keep a printed or offline copy, because a hacked site or mailbox may be the very thing you cannot open during the incident.
Step 3
Write the first-hour containment checklist
List the actions that stop further harm: change admin and hosting passwords, revoke API keys, switch on two-factor authentication, take a public file offline, recall or ask recipients to delete a misdirected email, put the site into maintenance mode if needed, and ask the host to preserve logs. Add a line reminding people not to wipe or rebuild the server before logs and copies of the altered files have been saved as evidence.
Step 4
Set out how you will judge the risk
Add a short set of questions the lead answers in writing: what data was involved, how many people, whether it was encrypted, who now has it, whether it can be recovered, and what could realistically happen to those people. Finish with three outcomes, record only, report to the ICO, or report and tell people, and require the lead to note the outcome, the reasoning and the time the decision was made.
Step 5
Prepare the ICO report in advance
Visit the ICO's breach reporting pages now, not during an incident, and note how to report online or by phone. In the plan, keep a ready-made list of what the report must cover: what happened and when, the categories and approximate numbers of people and records, likely consequences, what you have done and will do, and a contact name. Note that an incomplete first report within 72 hours is better than a complete late one.
Step 6
Draft the message to affected people
Write a template email for breaches that carry a high risk to people. It should say in plain language what happened, what data was involved, what you have done, what they should do to protect themselves, such as changing a reused password or watching for phishing, and who to contact with questions. Avoid technical jargon and vague reassurance, and plan how you would reach people whose email address was part of the breach.
Step 7
Start a breach log and rehearse the plan
Create a spreadsheet with columns for the date found, what happened, data and people affected, the risk decision, the reasoning, whether the ICO and individuals were told, and the lessons learned. Every breach goes in, including ones you decide not to report. Then spend thirty minutes walking the team through a pretend incident, such as a leaked order export, and fix whatever gaps the rehearsal shows.
Common website breaches and what to do first
Most breaches at small businesses with websites fall into a handful of patterns. Knowing them makes both the plan and the first hour easier.
A hacked content management system
Outdated plugins, themes and reused admin passwords are common ways in. Check whether the attacker could reach the database, which on WordPress includes user accounts and, on shops, order and customer tables. Look for new admin users, changed files and unfamiliar scheduled tasks. Restore from a clean backup only after saving evidence, then update everything and reset every password.
Card-skimming code on a checkout
Injected JavaScript that copies card details as they are typed is high risk by nature. Remove the script, tell your payment provider straight away, because they have their own procedures, and assume you will need to tell customers who paid while it was live. Hosted payment pages, where the card form sits on the provider's domain, reduce this exposure considerably.
Forms and emails going to the wrong place
A form whose notification address was never updated after a staff change, or a mailing sent with addresses visible to everyone, are breaches of confidentiality. Many are low risk and only need recording, but an exposed list of patients or clients of a sensitive service is different, because the list itself reveals something about each person.
Public backups and exports
Database dumps left in a web folder, such as backup.sql or orders.csv, can
be found and downloaded. Check your access logs to see whether anyone actually fetched the file; that
evidence may change the risk assessment from likely to unlikely, or the other way round.
A supplier's breach
If your email marketing platform, form builder or hosting company tells you it has had a breach, you are usually the controller and the reporting decision is yours. Ask the supplier for the facts you need for the assessment, in writing, and log the time you first heard.
A breach log you can copy
Article 33(5) of the UK GDPR requires you to document every personal data breach, its effects and the remedial action taken, whether or not you report it. A simple spreadsheet is enough. The fields below cover what the ICO would expect to see if it asked.
Reference: BR-2026-003
Found: 2026-09-12 16:40, by shop manager
What happened: Order export orders-sept.csv left in /wp-content/uploads/
Data involved: Names, delivery addresses, emails, items bought
People affected: About 420 customers
Encrypted: No
Access evidence: Server log shows one download from an unknown IP address
Contained: 2026-09-12 16:55, file deleted, folder listing disabled
Risk decision: Likely risk; not high (no payment or password data)
Decided by / when: Operations lead, 2026-09-13 10:15
ICO reported: Yes, 2026-09-13 11:30 (within 72 hours)
People told: Not required; courtesy email sent 2026-09-14
Lessons: Exports now go to private storage; monthly check of uploadsThe log is also useful to you. A pattern of small misdirected emails, for example, points at a process problem that one training session or a mail setting could remove.
Making breaches less likely and easier to handle
- Collect less and keep it for less time. Data you deleted last year cannot be breached this year. Set retention periods for form entries and old orders and actually delete them.
- Protect every admin account. Unique passwords, a password manager, two-factor authentication and removing accounts for people who have left.
- Keep software current. Update the content management system, plugins and themes, and remove anything unused.
- Take backups you have tested. Store them away from the web root and away from the server itself, and check you can restore one.
- Keep logs long enough to be useful. Access and error logs are often the only way to know whether exposed data was actually taken.
- Put breach clauses in supplier contracts. Make sure every processor must tell you promptly, and that you know how they will contact you.
- Review the plan once a year and whenever you change host, add a new system that holds customer data, or someone named in the plan leaves.
For the other duties that sit around a breach plan, see the GDPR Guide and, if you run a shop, GDPR for online shops.
1. Do I have to report every data breach to the ICO?
No. You must report a personal data breach to the ICO when it is likely to result in a risk to people's rights and freedoms. If it is unlikely to cause any risk, for example a single email sent to the wrong colleague and deleted at once, you record it in your breach log with your reasoning instead. The decision is yours to make and justify, so write down why you reached it and when. If in doubt, the ICO's guidance and helpline can help you decide.
2. When does the 72-hour deadline start?
It starts when you become aware of the breach, which the ICO describes as having a reasonable degree of certainty that a security incident has compromised personal data. A short initial investigation to reach that point is acceptable. The 72 hours are clock hours and include nights, weekends and bank holidays. If you cannot give full details in time, report what you know within the deadline and send the rest in stages, explaining any delay.
3. What information does the ICO breach report ask for?
The UK GDPR says the report must describe the nature of the breach, including the categories and approximate number of people and records involved, give the name and contact details of a person who can answer questions, describe the likely consequences, and set out the measures you have taken or plan to take to deal with the breach and reduce its effects. Gather these in your plan beforehand so you are not hunting for them during an incident.
4. Do I need to tell customers about a breach?
You must tell the people affected without undue delay when the breach is likely to result in a high risk to them, for example where passwords, card details, identity documents or sensitive information were exposed. You may not need to if the data was properly encrypted and the key was safe, or if you have since taken steps that remove the high risk. Even when it is not required, a short honest message can help customers protect themselves.
5. Our hosting company was hacked. Is that our breach to report?
Usually, yes. If the host was acting as your processor and your customers' data was involved, you are normally the controller and the decision to report to the ICO is yours. The host must tell you without undue delay, and your 72 hours start when you become aware. Ask them in writing what data was affected, when, and what they have done, and record their answers and the time you received them in your breach log.
6. Is a hacked website always a personal data breach?
Not always. If the attacker only defaced a page, or used the server to send spam, and could not reach any personal data, it may be a security incident without a personal data breach. But many website hacks give access to the database, admin user accounts or form submissions, so check carefully before concluding nothing was exposed. Record the incident and your reasoning either way, because later evidence can change the picture.
7. How small a business needs a breach response plan?
Any business that holds personal data can suffer a breach, and the 72-hour deadline applies regardless of size. A sole trader does not need a long policy, but a page that lists the data you hold, who to call, how to contain common problems, how to judge risk and how to report will save hours when something goes wrong. It also shows the ICO that you took your responsibilities seriously before anything happened.
The GDPR Audit checks what a visitor can see, including the cookie banner, scripts that load before consent, the privacy policy and the routes people have to exercise their rights, and links each finding to the guide that fixes it.
Open GDPR Fixes →