Adrien Herbert, Commercial Partner at Excello, explains when UK organisations must report personal data breaches to the Information Commissioner under UK GDPR, using real-world examples to illustrate the importance of documenting breach decisions.
As a data privacy lawyer, one of the questions which vexes most of my clients is whether and when to report a personal information breach (including leaks) to the regulator.
“Personal data” as defined by the UK GDPR means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
Breach takes place whenever such data is subjected to accidental or unlawful destruction, loss or alteration or made available to someone without the right to access that personal data in a controlled, or more frequently, an uncontrolled way.
Personal data is collected, held and otherwise processed by organisations for limited and specific purposes, although controllers and processors are wont to argue that purposes are legitimate and limited in order to meet their objectives (or the agreement they have in place) as opposed to limiting their processing activities in order to unequivocally fall within the legislative bounds.
How the government has changed data protection law
Taking a leaf from the book of such controllers, the UK Government recently legislated to extend the right of certain ministers of state to share personal data with corporate third parties who provide what are perceived to be “desirable” data processing services, subject to complying with a newly created list of ‘recognised legitimate interests’ without first obtaining the consent of the data subjects.
Under new legislation such sharing of personal data is extremely difficult to prevent or challenge. Breach, including leaks is still an issue for government and for us all, and it is the role of the regulator, the Information Commission (renamed under the Data Use and Access Act 2025) to assist controllers and processors to treat data securely and with respect to the interests of the data subjects, sanctioning those who fail.
Common data breach examples
Take for example a situation in which an employee in your human resources team, before you have signed a data processing agreement with an insurance broker, attaches a spreadsheet to an email to that broker. It contains the address details of all the members of a department on it; breach may occur as soon as the employee sends the .xlsx file attached to the email because the HR person does not have the authority to process the personal information in that way (i.e. authorised processing activity may be limited to sharing internally with the individual data subjects or with other members of the human resources team).
Sending the file might cause breach to occur unless the company’s employment contracts give the human resources team the right to share the necessary personal data of any employee with insurance brokers / providers.
Once an email is sent then the data on that email is stored electronically on your company’s email server (for most businesses this is a cloud located, Exchange server). From here the data can be accessed by a number of individuals within your business in an uncontrolled way. It is also open to other forms of unauthorised processing (hacking for example).
Documents remain attached to the email which delivered them. Should the data file remain attached to emails for considerable periods, without proper controls to remove attachments after a given period, this is breach because personal data is stored on a server which does not “serve” the purpose for which the personal information was provided and the data can, by such automation (or lack thereof) be retained for far longer than is reasonable for the original purpose.
Then there is the sometimes reported upon circumstance in which an employee leaves their laptop in a public place. Should any laptop belonging to your company suffer such a fate, whether it is lost, never to return or swiftly returned to its holder, this should be dealt with by your cyber security team and data protection officer as an immediate and serious systems security risk / breach as well as a breach and leak of personal data.
Businesses which use SSO (Single Sign On) access to systems are perhaps at the greatest risk, as bypassing the SSO gateway once gives access to everything which the laptop holder accesses in the normal course of business and in some instances to systems which the holder has no need or reason to access (depending on the vigilance of your systems security team and the extent to which your system has been segmented and tailored to specific roles). In such instances, immediate responses should include closing down the account and blocking its access and, wherever possible, removing data from locations on your network to which the holder had had access.
When should breaches be reported?
So when must you report a breach to the regulator and what should you consider before so doing?
Under Art 33(1) UK GDPR you must notify the IC unless the breach is ‘unlikely to result in a risk to the rights and freedoms of natural persons’.
In making that assessment a number of factors should be considered:
1) Do you know the extent of the breach? If, as in the first example, data is shared with third parties who have no legitimate cause or reason to access it, then do you know whether the data file was removed as soon as received or have multiple recipients received and emailed the data file onwards to contacts of theirs? Even returning the email, if names have been added in the “To” or “cc” lists then this creates additional breaches.
2) Do you know when the breach took place and, if you do, then for how long it lasted? At any point were controls put in place?
3) Was any “Special” category data which is data requiring a greater amount of protection (e.g. medical records or racial or ethnic origins) lost, accessed or made available to those with no apparent right to process those data?
4) How much data has been lost, accessed or made available to those with no apparent right to process those data?
The onus is on the controller when first notified of a breach to notify the IC of any “reportable” breach without undue delay but in any event within 72 hours of first being on notice (notified or aware) of the breach, whether or not at that stage the reporting organisation is in full possession of the facts of the breach. If the controller notifies the IC later than 72 hours after they themselves were first notified then they will be requested to provide reasons for the delayed notification. Now if, in my second example, a laptop, giving access to swathes of personal data, is left on a train … even if the systems security team has taken every precaution to ensure that such data is properly secured … there would seem to be a fairly obvious need to notify the IC as quickly as possible and certainly “without undue delay”. A processor must notify the controller “without undue delay” but the burden of notifying the IC within 72 hours only applies to the controller. This said, the clock only begins to run once the controller is notified and does not start when its processor is first aware of the loss, damage, or access gained.
If in your assessment to determine that the risk to the rights and freedoms of the data subjects is high then the controller also has a duty to notify those data subjects once notification of the regulator has occurred.
Going back to the first example if the human resources personnel member notifies their superior as soon as they become aware of their mistake and if together they then notify the Data Protection Officer (or the legal team in the absence of a designated DPO) then the DPO or legal team on behalf of the business shall consider the factors above as part of its decision-making process as to whether or not the breach is to be reported. If the department that is the subject of the leak is small (if for example the emailed data identifies fewer than a handful of your colleagues [or such as the DPO / legal team determine is less than consequential]) and contains no Special category data then they may decide that the breach is insufficiently grave to warrant being reported. If this is the decision then the reasoning as to why that decision was reached should be recorded and added to the file on the breach event. Whether or not the controller reports a breach to the IC, the controller has an obligation to record the breach and the reasons why the controller decided to notify the IC (or conversely why it determined that no action in that regard was necessary. Should any question arise (should for example a data subject raise the breach in a complaint to the company via a formal process, or to the regulator themself) then the IC will come straight to the company (be that the controller or a processor … or both) and as a first step demand to know why the 72 hour reporting window was missed or ignored.
Key takeaways for organisations
If there is a single message to be delivered on this subject specifically and on the subject of data breaches and protection in general then it is document all of the decisions you as controller reach in respect of any set of data and ensure that any processor you engage follows suit.
You make the job of the regulator easier if you keep proper records of the whats, whys and wherefores and doing so will result in the IC treating you with respect for your professionalism and for your responsible approach to compliance. Even if it ultimately determines that mistakes have been made in your company’s adherence to data protection regulations, the sanctions it imposes on your business for its mistakes will be mitigated by the fact that you have a process and you have followed it with diligence.
In a climate in which the government sees fit to share vast quantities of personal (and in many cases Special category data) with international corporations whose bona fides may in certain respects be questioned, controlling personal data (or indeed, processing it on behalf of the controller) gets no less complex. By honouring the regulatory environment yourselves and playing by the rules laid down by the regulations or by the regulator’s guidance you can do everything within your powers to ensure that a drama never becomes a crisis.
For further assistance or advice, please contact Excello Law and ask to be referred to myself, or to any of our specialist data protection lawyers.
