Data breach reporting: what HR must tell the regulator, and when

Someone in HR sends an appraisal file to the wrong Sarah. A payroll report goes home in a bag that does not come back. A leaver still has the shared drive on their phone three weeks after their last day. Each is a question with a clock attached, and the clock is usually running before anyone realises a decision is due.

This article covers what counts as a personal data breach, the deadline and when it starts, the two thresholds, what a notification must contain, and what to record when you decide not to report. It describes the position in the United Kingdom and is general information, not legal advice.

Breaches are found at handovers, not at decisions. See how New Dynamics workflows give each stage an owner, a due date and a reminder, so an escalation does not sit in one inbox while the 72 hours run.

What counts as a personal data breach

The definition is in Article 4(12) of the UK GDPR. A personal data breach means:

“a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”

Four of those five verbs have nothing to do with an attacker. Accidental loss counts. Unauthorised disclosure counts, including by your own staff to your own staff. So do destruction and alteration. The ICO's guide, Personal data breaches: a guide, draws the conclusion: “This includes breaches that are the result of both accidental and deliberate causes. It also means that a breach is more than just about losing personal data.” Its examples run from “sending personal data to an incorrect recipient” to loss of availability, so ransomware that locks your HR system without taking a record out of it still counts.

Two duties, two different thresholds

Confusion about data breach reporting comes from running two duties together. Their tests differ.

Telling the regulator. Article 33(1) requires notification “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, then exempts a breach that “is unlikely to result in a risk to the rights and freedoms of natural persons”. The ICO puts it positively: “If a risk is likely, you must notify the ICO; if a risk is unlikely, you don't have to report it.” Not every breach is reportable, and the deciding question is the likelihood of risk to people, not the size of the incident.

Telling the people affected. Article 34(1) changes one word: “When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.” The ICO confirms the gap in the same guide: “A ‘high risk’ means the requirement to inform individuals is higher than for notifying the ICO.”

So there are three honest outcomes: report and tell the people, report but do not tell them, or report nothing and write down why. Article 34(3) also lifts the second duty where you had applied measures “that render the personal data unintelligible to any person who is not authorised to access it, such as encryption”. An encrypted laptop and an unencrypted one give different answers to identical facts.

The 72 hours, and when they start

The deadline runs from awareness, not from the incident, and not in working days. The ICO's short guide, 72 hours: how to respond to a personal data breach, puts it in a line: “The clock starts from when you discovered the breach, not when it actually happened.”

Be careful what you lean on for “becoming aware”. Article 33 uses the phrase without defining it, and the ICO's guide does not define it either: it points to section II of the Article 29 Working Party guidelines, which the European Data Protection Board has endorsed and which the ICO says “continue to be relevant”. That is guidance the regulator points to, not UK legislation, so treat it as expectation rather than definition. What does follow from the ICO's own wording is that the time you spend confirming personal data is involved sits inside the 72 hours.

Article 33(3) then sets the minimum content: the nature of the breach, including where possible the categories and approximate number of data subjects and of records concerned; the data protection officer or other contact point; the likely consequences; and the measures taken or proposed to mitigate it.

You will often not have all of that in time, and the law expects it. Article 33(4) allows the information to be “provided in phases without undue further delay”. The ICO's page on data breach reporting is clear about which half matters: “you're legally required to meet this timeframe and you should provide whatever relevant information you have to us at this stage.” Its update of 28 May 2025 added emphasis to reporting early and updating later. An incomplete report filed inside the window is the intended behaviour; a complete one filed on day six is a late report for which Article 33(1) requires reasons.

The record of every breach, including the ones you do not report

Article 33(5) is the duty that gets forgotten, and it has no threshold: “The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken.” The ICO's checklist repeats it as “We document all breaches, even if they don't all need to be reported.”

The log is what makes a decision not to report a decision rather than an omission. In one of the ICO's personal data breach examples, a pharmacy correctly judged a breach unreportable, and the ICO notes that if asked why, it “would be able to refer to the rationale recorded on the internal breach log”. That same page states the second threshold flatly: “The threshold for informing data subjects is higher than for informing the ICO.” In another of its cases, the log let a controller “explain the delay in reporting the breach to the ICO, outside the required 72 hours” once new facts turned an unreportable incident into a reportable one.

So a usable HR breach log holds the discovery time separately from the incident date, the data and the numbers, the risk assessment, the decision and who made it. Our post on access levels for HR data covers permissions, and employee records retention covers how long the file should have existed at all.

Four HR incidents, read against the ICO's criteria

These are judgements on facts. What follows applies the regulator's published reasoning rather than ours.

An HR file emailed to the wrong person

The ICO's case study 2 is close. A file holding financial history and mental health information went to a colleague in another department, who deleted it at once and told the sender. The reporting decision was “Documenting the breach on internal breach log only”, because both worked to the same security measures and deletion was confirmed, so “it is very unlikely that there would be any risk of harm or detriment to the data subject, despite special category personal data being involved”.

The condition carries the answer, and the ICO says so next: “If the email had been sent to a member of the public, the risk to the data subject would have been higher.” An appraisal or grievance file sent outside, or to someone who will not confirm deletion, is typically reportable.

A payroll file left on a train

The ICO's case study 3 covers a lost briefcase holding an unencrypted laptop and unredacted paper files. The controller reported to both the ICO and the people affected, because “there was no way for the controller to know whether the data had been accessed. Therefore, they could not be certain that a risk to the data subjects would not occur.”

Payroll is identifiers plus financial data, which the ICO's risk guidance flags as likely high risk because it may lead to identity fraud. Unencrypted and unrecovered, this is typically reportable. Encrypted and remotely wiped, with the wipe confirmed, Article 34(3)(a) is in play for the second duty. Paper has no encryption, which is why it is the harder version. Our post on BYOD policy covers the device rules.

A leaver who still has access

The ICO's risk guidance names “staff taking personal information with them when they leave an organisation” among common breach types. Residual access becomes a breach once personal data has been accessed without authorisation, so the first question is what the logs show after the termination date. Nothing opened, access removed: a control failure to log and fix. HR or payroll records opened: unauthorised access, with reportability turning on what was opened and about whom. Either way it belongs in the log, and in employee offboarding as a step with a named owner.

A reference disclosed without authority

A reference, or an internal reference note, passed on outside what the employee has been told and without a lawful basis is unauthorised disclosure under Article 4(12). References carry judgements on conduct, capability and sometimes health, and Recital 85, quoted in the ICO's guide, names “damage to reputation” and “discrimination” among the harms that make a breach reportable. A reference with that content, given to someone with no right to it, will usually clear the likely risk threshold.

The penalties, and the scale

Human error dominates the reports. The ICO publishes the data behind its data security incident trends, last updated on 26 October 2026; counting distinct report references in that download for the third quarter of 2026 gives 4,604 reports, of which “Data emailed to incorrect recipient” is the largest single incident type at 801, with employees the recorded data subject type in 1,350. The ICO cautions that incident types “are allocated by the ICO and are assigned as a best fit”. More of the figures we use sit in our HR statistics hub.

On penalties the ICO states the position without embellishment: “Failing to notify the ICO of a breach when required to do so can result in a heavy fine of up to £8.7 million or 2 per cent of your global turnover.” That tracks the legislation. Article 83(4) puts infringements of Articles 25 to 39, which covers both reporting duties, at “up to £8,700,000, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher”. Section 157 of the Data Protection Act 2018 calls that the standard maximum amount and reserves the higher maximum of £17,500,000 or 4 per cent for other infringements, so the 4 per cent figure quoted in much breach training is not the one that applies here. The ceiling is not the expectation either: the ICO's first instruction to a small organisation that has just found a breach is “Don't panic”, followed by “Not every breach reported to us results in formal action.”

One wording change is worth knowing. Since 30 September 2026, under the Data (Use and Access) Act 2025 (Consequential Amendments and Transitional Provision) Regulations 2026, schedule 3 paragraph 41, Articles 33(1) and 33(5) and Article 34(4) read “the Commission”, defined in Article 4 as the Information Commission, where they read “the Commissioner” before. The ICO's guidance still says ICO and notes it “is under review”. Both are correct: the regulator confirmed on 30 September 2026 that “The governance transition does not change the Commission's core responsibilities”, and the route, the form and the 72 hours are unchanged.

Frequently asked questions

Do I have to report every data breach to the ICO?

No. Article 33(1) of the UK GDPR requires notification unless the breach “is unlikely to result in a risk to the rights and freedoms of natural persons”. The ICO states that if a risk is likely you must notify, and if it is unlikely you need not. You must still document it and justify the decision.

When do the 72 hours start?

From the moment you become aware. The ICO's guidance says the clock starts from when you discovered the breach, not when it actually happened. The 72 hours are not working hours, and they include the time spent confirming personal data is involved.

What if I do not have all the details within 72 hours?

Report anyway. Article 33(4) allows the required information to be provided in phases without undue further delay, and the ICO asks organisations to report early and update later. Waiting for a complete picture produces a late report that then needs reasons for the delay.

Do I have to tell the employees affected?

Only where the breach is likely to result in a high risk to their rights and freedoms. Article 34(1) sets that higher threshold, and the ICO confirms it is higher than the one for notifying the regulator. Article 34(3) removes the duty where the data was rendered unintelligible, for example by encryption.

Is an email sent to the wrong person a reportable breach?

It is a personal data breach, because the definition covers unauthorised disclosure and accidental loss rather than attacks alone. Whether it is reportable depends on who received it and what happened next. An ICO case study treats a misdirected internal file, deleted at once and confirmed, as log only.

How long should we keep a record of a breach we did not report?

The UK GDPR sets no period. Article 33(5) requires the facts, effects and remedial action to be documented for any personal data breach, and that the documentation let the regulator verify compliance with Article 33.

Your next step: make the first hour boring

1. Name the owner and a deputy for breach decisions, and publish the escalation route where payroll and HR administrators will see it.
2. Check your breach log records a discovery timestamp separately from the incident date. Without it the 72 hours cannot be evidenced.
3. Take the last three incidents you handled informally and write the Article 33 decision for each: risk likely or not, high risk or not, and why.
4. List which HR systems and devices holding employee data are encrypted, because that fact changes the answer on a lost device.
5. Add the leaver access check to offboarding with a date, and read the access log after the termination date.

For the policy this hangs from, read and download our employee data protection guide. The guide is free to read, and the PDF uses our short download form.

Want the owners and dates to exist before the incident rather than after it? Book a New Dynamics demo and bring your current breach log. You can also email contact@new-dynamics.com.