Deprecated: mb_convert_encoding(): Handling HTML entities via mbstring is deprecated; use htmlspecialchars, htmlentities, or mb_encode_numericentity/mb_decode_numericentity instead in /home/cardenitservices/public_html/wp-content/themes/hello-elementor-child/functions.php on line 128
General guidance only – consult a solicitor for advice specific to your business.
If your business suffered a cyber incident tomorrow, would you know whether you had to report it to the ICO within 72 hours?
Many UK SME owners know GDPR exists, but far fewer are clear on what actually happens after a breach. That becomes a serious problem during a cyber incident, when decisions need to be made quickly, facts are still emerging, and the clock is already ticking.
The key point is this. Not every cyber incident is a reportable GDPR breach, but some are, and the reporting threshold is based on risk to people, not just disruption to your business.
If you wait too long to work that out, or if you have no process for assessing and documenting the incident properly, you can make a bad situation harder to manage.
What Counts as a Reportable Breach Under UK GDPR?
Under UK GDPR, a personal data breach is not limited to stolen files or hacked email accounts. It covers a breach of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
In practical terms, that could include:
- a cyber attacker accessing customer records
- staff emailing personal data to the wrong recipient
- a laptop containing personal data being lost or stolen
- files being encrypted or made unavailable in a ransomware incident
- data being altered or corrupted without authorisation
What makes a breach reportable to the ICO is not simply that something went wrong. The test is whether the breach is likely to result in a risk to the rights and freedoms of individuals.
That means your first assessment should focus on the people affected. Could they face identity theft, fraud, financial loss, loss of confidentiality, distress, safeguarding concerns, or other meaningful harm? If the answer is yes, the breach may well be reportable.
| Question | Why it matters |
|---|---|
| Was personal data involved? | If not, UK GDPR breach reporting may not apply |
| Was there loss, unauthorised access, disclosure, alteration, or unavailability? | These are all possible personal data breach scenarios |
| Are individuals likely to face risk? | If yes, ICO notification may be required |
| Is the risk high? | If yes, affected individuals may also need to be told |
The 72-Hour ICO Notification Requirement
If the breach is notifiable, you must report it to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it.
That timing point matters. The clock starts when your organisation becomes aware of the breach, not when the attack first happened. In many cases, businesses discover an incident hours or days after the original compromise. Once you are aware, the timeline becomes critical.
You do not need to have every technical detail confirmed before making the initial report. If the breach is reportable, it is usually better to notify within the deadline and then provide further information as your investigation develops.
A late report is still possible, but you must explain the delay. That is not a position most businesses want to be in unless there is a very good reason.
Your ICO notification should usually cover:
- what happened and when
- the types of personal data involved
- the categories and approximate number of people affected, where possible
- the likely consequences
- what containment and mitigation steps have been taken
- who the ICO can contact for more information
When Do You Need to Notify Affected Individuals?
The threshold for informing affected individuals is higher than the threshold for notifying the ICO.
You must tell affected individuals without undue delay if the breach is likely to result in a high risk to their rights and freedoms. In plain English, that means the likely impact on them could be serious enough that they need to know quickly so they can protect themselves.
This might apply where exposed information could realistically lead to identity theft, fraud, account compromise, or serious confidentiality concerns.
When you notify people, the message should be clear, direct, and practical. Tell them what happened, what it may mean for them, what steps you have taken, and what steps they should take now. Depending on the incident, that could include changing passwords, being alert to phishing, or watching for suspicious account activity.
If, after assessment, you conclude the risk is not high, you may not need to notify individuals. But that decision still needs to be documented properly.
What Documentation Should You Have in Place Before an Incident?
This is where many SMEs fall short. Businesses often focus on technical controls but forget the paperwork, roles, and decision-making process needed when something actually happens.
Before an incident occurs, you should have:
- a clear breach response plan
- a breach log template
- named internal decision-makers and escalation contacts
- details of who handles legal, technical, and communications input
- an overview of where personal data sits across systems
- processor contracts that require prompt breach notification
- draft communications templates for staff, customers, and regulators
You should also be recording all breaches, even those that do not end up being reported to the ICO. That record should include the facts, the likely effects, and the remedial action taken.
If your business uses third-party processors, this becomes even more important. If a processor suffers a personal data breach, it must inform you without undue delay so you can decide whether ICO notification is required.
Why an Incident Response Plan Can Reduce Regulatory Risk
An incident response plan will not guarantee that the ICO takes no action. But it can put your business in a much stronger position.
Why? Because the ICO expects organisations to assess breaches properly, log decisions, act without undue delay, and show accountability. A business with no response process is far more likely to miss deadlines, lose evidence, make inconsistent decisions, or fail to protect affected people quickly enough.
A good incident response plan helps you:
- identify whether personal data is involved
- contain the incident faster
- assess risk to individuals consistently
- capture the facts while they are still fresh
- decide whether ICO and individual notification is required
- show that your business acted responsibly and methodically
It also helps from a wider business resilience perspective. Your incident response plan should work alongside business continuity, disaster recovery, and communications planning, not sit in isolation.
Do Not Wait Until the Clock Is Already Running
The worst time to work out your GDPR breach process is during a live cyber incident.
If your business stores customer data, staff data, or any other personal information, you should already know who makes the reporting decision, how risk is assessed, how breaches are logged, and how quickly the right people can be brought together.
That does not mean every incident will be reportable. It means your business will be in a far better position to make the right call, quickly, and back it up properly if questioned later.
