When Do UK Businesses Need to Report a Data Breach to the ICO?

A data breach can put a business under pressure fast. Founders often lose time asking the wrong question, not whether there was a personal data breach, but whether it is serious enough to report to the Information Commissioner's Office, and how quickly they need to act. Two common mistakes are waiting for every fact before doing anything, and assuming only hacking incidents count. Another frequent problem is treating an internal email mistake or lost device as an IT issue only, instead of a privacy incident with legal deadlines attached.

The key rule in the UK is not that every breach must be reported. The question is whether the breach is likely to result in a risk to the rights and freedoms of individuals. If the answer is yes, your business may need to report to ICO within 72 hours of becoming aware of it. This guide explains what that means in practice, when the issue comes up for SMEs, what to record even if you do not report, and the practical steps that help you respond before the situation gets worse.

Overview

UK businesses do not need to notify the ICO about every personal data breach, but they do need a clear process for assessing incidents quickly. The legal test focuses on risk to individuals, not just inconvenience to the business, and the reporting window can be short.

• Confirm whether personal data was involved at all.
• Work out whether there has been a confidentiality, integrity or availability breach.
• Assess the likely risk to the rights and freedoms of affected people.
• Decide whether the incident should be reported to the ICO within 72 hours.
• Consider whether affected individuals also need to be told.
• Keep an internal record of the breach, even if you decide not to report it.
• Contain the issue, preserve evidence and review what failed.

What Report to ICO Means For UK Businesses

Reporting to the ICO means formally notifying the UK regulator that your business has suffered a personal data breach that is likely to put individuals at risk. It is not a general complaint form, and it is not limited to cyber attacks.

Under UK data protection law, a personal data breach is a security breach leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That definition is wider than many founders expect.

For example, a reportable breach could arise where:

• a spreadsheet containing customer details is emailed to the wrong recipient
• an employee laptop with unencrypted personal data is stolen
• payroll records are exposed to staff who should not see them
• a cloud storage folder is left publicly accessible
• your system outage means you cannot access health or care data when needed

The last point matters because breaches are not only about secrecy. A breach can affect confidentiality, integrity or availability. If data is altered, deleted or made unavailable in a way that harms people, the legal issue may still be serious even if nobody outside the business saw the information.

The legal threshold for notifying the ICO

You generally need to report to ICO if the personal data breach is likely to result in a risk to the rights and freedoms of natural persons. In plain English, ask whether real people could suffer harm because of what happened.

That harm might include:

• identity theft or fraud
• financial loss
• discrimination
• damage to reputation
• loss of confidentiality, especially for sensitive information
• loss of control over personal data
• physical or emotional harm

Not every low-level incident reaches that threshold. If an employee briefly accesses a customer record they were authorised to see for another task, and no further disclosure or misuse occurs, the risk may be low. But if special category data, financial information, passport details, children's data or login credentials are involved, the risk can rise quickly.

The 72-hour reporting window

The deadline is short. If you decide the breach is reportable, you should notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it.

"Becoming aware" does not mean knowing every technical detail. It usually means you have a reasonable degree of certainty that a security incident has occurred and that personal data has been compromised. This is where businesses often get caught. They spend a day or two investigating before anyone starts the legal assessment.

If you miss the 72-hour window, you may still need to report, but you should explain the delay. Waiting until your internal investigation is perfect is usually the wrong approach. An initial report can be followed by further information as the picture becomes clearer.

Do you need to tell affected individuals too?

If the breach is likely to result in a high risk to the rights and freedoms of individuals, your business may also need to tell the affected people without undue delay. That is a separate question from whether you report to the ICO.

A high-risk case might include exposure of bank details, medical information, identity documents or account credentials. Your message to individuals should be clear and useful, not defensive. People need to know what happened, the likely consequences and what steps they can take to protect themselves.

There are limited situations where direct notification to individuals may not be required, such as where strong security measures made the exposed data unintelligible, or where later steps removed the likely high risk. Those exceptions need careful handling.

Why this matters beyond the regulator

For startups and SMEs, the main risk is not only regulatory scrutiny. A poor breach response can damage customer trust, trigger contractual issues with partners, create employment problems and expose weak privacy practices that should have been fixed before you signed supplier terms or launched online.

This is why data breach response should sit alongside your wider privacy setup, including:

• privacy notices
• internal data handling policies
• employee confidentiality expectations
• processor agreements with service providers
• incident response procedures
• access controls and retention rules

When This Issue Comes Up

Businesses usually face this question in ordinary operational moments, not only during dramatic cyber incidents. The issue often appears when a team member spots a mistake, a supplier reports unusual activity, or a customer says they received someone else's information.

Misdirected emails and attachments

This is one of the most common SME incidents. A sales team member sends a price list with customer names and addresses to the wrong mailing list, or payroll sends salary data to the wrong employee.

These incidents can be easy to underestimate because they feel administrative rather than technical. But if personal data was disclosed to an unauthorised person, there may be a personal data breach that needs immediate assessment.

Lost devices and poor access control

A missing laptop, phone or USB stick can become a reportable breach if it contains personal data and is not adequately protected. Shared logins, former staff retaining system access, and broad permission settings create similar problems.

Before you spend money on new software, check whether the real issue is basic access control. Founders sometimes focus on buying tools after a scare, when the main fix should have been tighter internal permissions and offboarding.

Third-party supplier incidents

Many businesses store or process personal data through payroll providers, CRMs, marketing platforms, cloud hosts and outsourced support teams. If one of those providers suffers a breach, your business may still have reporting obligations depending on your role and the facts.

If you are the controller, you cannot assume the processor will make every legal decision for you. Your contract with the supplier should set out incident notification duties, timing and cooperation requirements, often in a data processing agreement. This is exactly the kind of point that causes trouble after the fact, when the agreement was signed without enough detail.

Ransomware and system outages

A ransomware event can affect access to personal data even if you cannot yet confirm exfiltration. If customer files, appointment records or employee data become unavailable, the incident may still amount to a personal data breach.

For sectors handling sensitive data, such as healthcare, education, recruitment or financial services, availability problems can create real harm. Delayed access can affect people in ways that make reporting more likely.

Internal misuse or accidental snooping

Not every breach comes from outside the business. An employee looking at records out of curiosity, downloading customer lists before resigning, or sharing staff data internally without a need to know can all trigger reportability questions.

Here, the legal issue often overlaps with employment contracts, confidentiality obligations and disciplinary processes. You need to preserve evidence and respond proportionately, rather than treating it as only a HR matter.

Mergers, onboarding and messy data migrations

Growing businesses often discover problems during platform changes, acquisitions or rapid hiring. Data may be copied into new systems, uploaded to test environments, or shared with contractors before roles and permissions are settled.

This is where founders often get caught before launch or expansion. The pressure to move quickly can mean privacy checks are skipped, records are duplicated and no one is sure who has access to what.

Practical Steps And Common Mistakes

The best response is a structured one: contain the breach, assess legal risk quickly, document your reasoning and decide on notifications without waiting for perfect information. A calm process matters more than a dramatic one.

Step 1: Confirm the facts fast

Start with a basic incident log as soon as the issue is raised. Record what happened, when it happened, who discovered it, what systems are involved and what types of personal data may be affected.

At this stage, you should identify:

• whether personal data is involved
• whose data is affected, such as customers, staff, contractors or users
• how many individuals may be affected
• whether the data includes special category information, financial details or identity documents
• whether the data was encrypted, pseudonymised or otherwise protected
• whether the issue is ongoing or has been contained

Do not wait for a perfect technical report before capturing these basics. Your legal assessment depends on them.

Step 2: Contain and recover

Take practical steps to stop further loss or disclosure. That could include recalling an email, resetting credentials, disabling accounts, removing public access, isolating systems or contacting a supplier urgently.

Containment should happen alongside assessment, not after it. A business that spends hours debating legal wording while the exposed folder remains public is creating a bigger problem.

Step 3: Assess the risk to individuals

The reporting decision turns on the likely risk to people's rights and freedoms. Focus on the real-world impact on affected individuals, not only the embarrassment or cost to your business.

Questions to ask include:

• Could someone be identified from the data?
• Could the information be used for fraud, impersonation or account takeover?
• Is the data sensitive, confidential or likely to cause distress if exposed?
• Are vulnerable people or children affected?
• Could someone suffer financial, professional, physical or emotional harm?
• Has the information reached a trusted recipient who deleted it, or an unknown party who may misuse it?

The context matters. A wrongly sent document to your external accountant, who immediately confirms deletion, may present a lower risk than the same document posted in a public online folder.

Step 4: Decide whether to report to the ICO

If the breach is likely to result in a risk to individuals, your business should report it. If the risk is unlikely, you may decide not to notify, but you should still keep an internal record explaining why.

Your notification should usually include:

• the nature of the personal data breach
• categories and approximate number of affected individuals
• categories and approximate number of personal data records concerned
• the likely consequences of the breach
• measures taken or proposed to address it
• the contact point for follow-up

If you do not yet know all of that, provide what you can and update later. The law allows for phased reporting where full details are not immediately available.

Step 5: Consider notifying individuals

If the risk is high, tell the affected people promptly and in plain language. This communication should help them protect themselves, for example by changing passwords, watching for scams or contacting their bank.

Common mistakes here include vague wording, over-reassuring language and long delays while teams argue about brand impact. The message should be useful and honest.

Step 6: Keep records and review what failed

Even non-reportable breaches should be documented. The ICO expects organisations to keep records of personal data breaches, the facts relating to them, their effects and the action taken.

A good record can help if the regulator later asks questions. It also helps your business spot patterns, such as repeated email errors, weak approval processes or poor staff training.

Common mistakes SMEs make

The most common error is assuming the problem belongs only to IT. Data breaches cut across operations, HR, customer support, contracts and privacy compliance.

Other frequent mistakes include:

• treating only hacking as a breach and ignoring accidental disclosures
• failing to record incidents that were not reported
• missing the 72-hour window because internal approval chains are too slow
• having no clear owner for breach decisions
• using suppliers without clear contractual breach-notification clauses
• keeping more personal data than necessary, which increases exposure
• sending unclear notices to affected individuals

What founders should have ready before a breach happens

The businesses that handle incidents best usually sorted the basics earlier. You do not need a huge governance programme, but you do need practical documents and assigned responsibility.

Useful groundwork includes:

• a privacy notice that reflects your actual data use
• staff policies on data handling, confidentiality and device use
• employment contracts with suitable confidentiality obligations
• processor contracts covering security and incident reporting
• an internal incident response process with decision-makers named
• access controls, offboarding steps and retention rules
• training for staff who handle customer or employee data

If you are launching online, onboarding a new CRM, changing payroll systems or signing a data-heavy supplier contract, that is the right time to fix these points. Waiting until after an incident usually costs more.

FAQs

Do all data breaches need to be reported to the ICO?

No. You generally report only if the personal data breach is likely to result in a risk to the rights and freedoms of individuals. You should still keep an internal record of any breach, even where you decide notification is not required.

What counts as becoming aware of a breach?

It usually means your business has a reasonable degree of certainty that a security incident has happened and that personal data has been compromised. You do not need every detail before the 72-hour clock starts.

Is a misdirected email a reportable data breach?

Sometimes, yes. If the email contains personal data and was sent to someone not authorised to receive it, there may be a personal data breach. Whether you need to report depends on the likely risk to affected individuals.

What if the breach happened at one of our suppliers?

Your obligations may still apply, especially if your business is the controller. Check the contract, gather the facts quickly and assess whether the incident creates a reportable risk for the people whose data is involved.

Can we wait until the investigation is finished before we report?

Usually not. If the breach is reportable, you should notify without undue delay and, where feasible, within 72 hours of becoming aware. You can provide further information in stages if your investigation is still ongoing.

Key Takeaways

• A personal data breach is wider than hacking and can include loss, unauthorised access, accidental disclosure, alteration or unavailability of personal data.
• Your business generally needs to report to ICO if the breach is likely to result in a risk to the rights and freedoms of individuals.
• If the risk to individuals is high, you may also need to tell the affected people without undue delay.
• The 72-hour window starts when you become aware of a reportable-type incident, not when every fact is confirmed.
• Even if you decide not to report, you should keep a clear internal record of the breach, its impact and your reasoning.
• Good preparation matters, including supplier contracts, staff policies, privacy documents, access controls and a practical incident response process.

If your business is dealing with report to ico and wants help with data breach assessments, privacy policies, supplier contracts, employee confidentiality terms, you can reach us on 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.