Data breach response and ICO notification - Bratby Law

Data Breach Response and Incident Notification

Containing, assessing and notifying personal data breaches

Crisis management, privileged forensic investigation and multi-regime regulatory notification for telecoms, payments and technology businesses

Rob Bratby, Managing Partner
Last updated: August 2026

A controller that discovers a personal data breach must contain the incident and preserve the evidence, and at the same time decide whether it must notify the ICO, another regulator or the individuals affected. Without a plan agreed in advance, those decisions fall to whoever is in the room when the breach is found. A controller that instructs its legal advisors at the point of discovery gives itself the best chance of protecting the legal analysis by privilege, and keeps its notifications to different regulators consistent with one another.

When a data breach triggers notification obligations

The practical trigger for notification is the moment a controller becomes aware of a breach. Under Article 33 of the UK General Data Protection Regulation (as retained in UK law), a controller must notify the Information Commissioner’s Office without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. The clock does not start when the breach occurred (which may be weeks or months earlier); it starts when the organisation first knows that personal data has been accessed, disclosed or lost. Awareness is not the same as certainty: if a controller suspects that a breach may have occurred, the clock starts even if the scope and impact remain unclear. The ICO accepts that factual details may be incomplete at the 72-hour mark; controllers may provide further information in phases “without undue delay” thereafter.

A controller may owe notifications to more than one regulator for the same incident. Controllers subject to UK GDPR and PECR (the Privacy and Electronic Communications Regulations 2003) face notification obligations to the ICO under both regimes. A provider of a public electronic communications network or a public electronic communications service must also inform Ofcom, as soon as reasonably practicable, of any security compromise that has a significant effect on the operation of the network or service, under section 105K of the Communications Act 2003, inserted by the Telecommunications (Security) Act 2021 and in force since 1 October 2022. Operators of essential services and relevant digital service providers fall within the Network and Information Systems Regulations 2018. Under regulation 11 an operator of an essential service must notify its designated competent authority of an incident that has a significant impact on the continuity of the service; under regulation 12 a relevant digital service provider must notify the Information Commissioner of an incident that has a substantial impact on the provision of its service. Each notification is due without undue delay and in any event no later than 72 hours after the operator or provider becomes aware of the incident. Financial services firms regulated by the FCA face additional operational incident reporting obligations, which change on 18 March 2027 when the rules made in FCA Policy Statement PS26/2, Operational incident and third party reporting, take effect. A single cyber incident can therefore trigger multiple notification regimes, each with different requirements as to recipients, timescales, content and privilege protections.

Why breach response capability matters now

When the ICO sets a penalty it weighs how the organisation responded to the breach, not only the breach itself. In October 2025 the ICO fined Capita plc and Capita Pension Solutions Limited a combined £14 million, made up of £8 million and £6 million, for a March 2023 breach affecting 6.6 million people. The ICO’s notice of intent had proposed a combined £45 million. The ICO reduced the figure because of what Capita did after the incident: improvements to its security controls, support for affected individuals including 12 months of free credit monitoring, cooperation with other regulators including the National Cyber Security Centre, and engagement with the ICO. The reduction was agreed as a voluntary settlement, under which Capita admitted liability and agreed not to appeal. The ICO has no published settlement framework: it consulted between 31 October 2025 and 23 January 2026 on draft procedural guidance containing a proposed settlement procedure, built on the Advanced Computer Software and Capita settlements, which would require an admission as to the nature, scope and duration of the infringement and an agreement not to appeal. Until that guidance is final, the discount available on a settlement is a matter for negotiation rather than a published tariff.

On 5 February 2026 Schedule 13 to the Data (Use and Access) Act 2025 substituted the PECR enforcement schedule, so that a breach of the principal PECR duties now attracts the higher maximum amount under section 157(5) of the Data Protection Act 2018: £17.5 million or 4% of total annual worldwide turnover, whichever is higher. That matches UK GDPR. The Data (Use and Access) Act 2025 gives the ICO two new investigative powers, both in force since 5 February 2026. Under sections 148A to 148C of the Data Protection Act 2018 the ICO may give an interview notice requiring an individual to attend at a specified place and answer questions relevant to its investigation; the individual may be the controller or processor, a current or former employee or worker, or anyone concerned in the management or control of the business, and in an urgent case the notice may require attendance after 24 hours. Under section 146A the ICO may require a controller or processor, through an assessment notice, to make arrangements for a report to be prepared by a person the ICO has approved. There is no caution and no obligation to incriminate oneself: an interview notice does not require an answer that would expose the individual to prosecution for an offence outside the Act, it does not reach communications protected by legal professional privilege, and a statement given in response may not generally be used against the individual on a prosecution under the Act. The practical point stands: a controller can no longer limit what the ICO sees by controlling which documents it produces.

Common breach response failures

A breach response plan names the person who takes charge, sets the escalation route to the board, lists the containment steps and holds a template notification for each regulator that may need one. Without it, the IT team contains the incident while the communications team drafts a public statement, and the lawyers are told late. Containment cannot wait for classification: establishing the precise number of individuals affected, the exact data accessed and the cause of the breach takes weeks, and the initial regulatory assessment is due in hours. Evidence has to be preserved before systems are restored, because the record of the attacker’s activity is overwritten when they are. Timing runs in both directions: a notification made before the facts are established produces a sequence of corrections, and one made after 72 hours must be accompanied by reasons for the delay under Article 33(1), which the ICO will test. The notifications must also tell the same story, because an ICO notification recording that the breach is not notifiable to individuals under Article 34 will be read against an Ofcom report under the Telecommunications (Security) Act that describes the same incident differently.

A public statement issued before the legal analysis is done fixes the version of events the regulator will investigate, and every later factual finding is measured against it. A controller must also keep a record of every breach, including those it does not notify to the ICO (Article 33(5)). That record is the controller’s own evidence of how it handles breaches, and it is disclosable in an enforcement investigation.

What effective breach response looks like

Effective breach response operates in three phases: pre-incident, during incident, and post-incident. Pre-incident preparation should include a breach response plan naming the incident commander, establishing clear escalation to the board, defining the roles of IT, legal, compliance and external advisors, and maintaining a template notification for each applicable regulatory regime. The template should identify which information must be included in notifications to the ICO, Ofcom, the FCA and other regulators, and which information may be updated after the initial notification. The plan itself will not usually be privileged: there is no litigation in contemplation when it is written, and an operational document is not a communication seeking legal advice. Legal advice on the plan is privileged; the plan should be written on the assumption that a regulator may read it.

During an incident, triage comes first. Within hours, not days, the organisation must decide whether a notifiable breach has occurred, which regulators it must notify, and whether the risk to individuals is high enough to require notification to them under Article 34. Triage does not need a completed forensic investigation; it needs enough fact to support a legal judgment. The incident commander establishes what personal data was accessible, whether an unauthorised person could have reached it, whether there is evidence that one did, and whether adverse effects on rights and freedoms are likely. Where any of the first three of those points is uncertain, the controller proceeds on the basis that a breach has occurred and that the notification clock has started.

Containment and evidence preservation run in parallel with triage. The incident commander should ensure that systems are isolated to prevent further unauthorised access, that forensic evidence is preserved (either on-site or by secure hand-over to a specialist forensic firm), and that no unauthorised deletion of logs or records occurs. Once evidence is secured, systems can be restored. Legal advisors should settle the notification to the ICO under UK GDPR, the notification to Ofcom under the Telecommunications (Security) Act and any notification to the FCA or another regulator together, so that the three tell a consistent story. Where regimes differ (for example, on the standard of proof required or the definition of “significant impact”), the notifications should reflect those differences transparently.

Post-incident, the organisation should conduct a root cause analysis with the assistance of forensic experts and security specialists. This analysis informs both the ICO engagement (demonstrating to the regulator that the organisation understands what happened and why) and remediation planning. Organisations should also conduct a lessons learned review to identify gaps in the pre-incident plan and update it. A controller that instructs specialist breach response counsel at the moment of discovery is in the best position to claim privilege over the legal analysis and the strategy for engaging the regulator. Sections 143 and 148B of the Data Protection Act 2018 put privileged communications outside the reach of an ICO information notice and an ICO interview notice, so a document that is genuinely privileged does not have to be produced. Whether the investigators’ own factual findings are privileged is a separate and harder question that turns on the facts of the engagement. An organisation that investigates without legal involvement has no claim to privilege over those findings at all, and must produce them if the ICO asks.

When to instruct specialist breach response counsel

Specialist breach response counsel should be instructed immediately upon discovery of a potentially notifiable breach. The threshold is low: where there is any reasonable possibility that personal data has been accessed or disclosed without authorisation, the controller instructs counsel before it investigates. The specific triggers for immediate instruction include any breach involving large volumes of personal data (more than 1,000 individuals), any breach involving special category data (health, genetic, biometric data), financial data, or children’s data; any breach likely to attract media attention, because a public statement fixes the account against which every later finding is measured; any incident where multiple notification regimes apply (requiring coordination across UK GDPR, PECR, Telecommunications (Security) Act, NIS Regulations or FCA rules); and any situation in which a regulator (the ICO, Ofcom, FCA) has already initiated contact.

A controller that instructs its advisors only after the internal investigation is complete loses privilege over that investigation. Once the IT team and internal business teams have conducted the investigation without legal involvement, their findings cannot be protected from the regulator. The order matters: the controller instructs its legal advisor on discovery, the advisor directs containment and evidence preservation, the IT team carries out those directions, and the investigative work then proceeds under privilege.

FAQs

What is the difference between the 72-hour clock for UK GDPR and the old PECR 24-hour requirement?

Until 5 February 2026, PECR required notification to the ICO within 24 hours of becoming aware of a breach. The Data Use and Access Act 2025 amended PECR to align the notification timescale with UK GDPR: 72 hours. This removes the dual requirement to notify PECR separately from UK GDPR and makes the process more manageable for organisations subject to both regimes.

Does legal privilege apply if we instruct an external forensic firm to investigate the breach?

Legal privilege applies to advice given by lawyers and work done by lawyers in conducting litigation or obtaining advice. Instructing the forensic firm through the lawyers, and having it report to them, improves the position but does not by itself secure privilege. Legal advice privilege covers communications between a lawyer and the client for the purpose of giving or obtaining legal advice; it does not extend to a third party’s factual investigation simply because a lawyer commissioned it. Litigation privilege can cover a forensic report, but only where adversarial proceedings are in reasonable contemplation and the dominant purpose of the report is those proceedings. Where the firm is instructed by the IT or business team, or reports to the business without legal involvement, no privilege arises. The scope of privilege over cyber investigations is contested and fact-sensitive, so the engagement should be structured with that in mind and the position on each document recorded when it is created. The forensic firm should be instructed by the legal advisor for the purpose of assisting with breach response advice.

Can we delay notification to the ICO if we need more time to investigate?

Article 33 allows information to be provided in phases. The initial notification must go to the ICO within 72 hours, but it may be incomplete. The organisation may state that further information will follow “without undue delay”. However, the initial notification must contain a reasonable assessment of what has happened, how many individuals may be affected, and what containment measures have been taken. Saying “we don’t know” is not a valid strategy for delay. The clock does not pause whilst investigation continues.

What should we do if we discover that we have breached the 72-hour deadline?

Article 33(1) provides that a notification not made within 72 hours must be accompanied by reasons for the delay, so a late notification is not automatically a breach. The reasons have to bear scrutiny: a delay that cannot be justified is a failure to notify without undue delay, and it will be read as evidence of poor incident response. If the deadline is missed, notify the ICO immediately and give the reasons. Legitimate reasons for delay include the complexity of the incident, the need to secure forensic evidence before full disclosure, or the scale of the investigation. Self-reporting a late notification is materially better for settlement negotiations than being discovered by the regulator through a complaint from affected individuals.

Must we notify affected individuals if we notify the ICO?

Not necessarily. Article 33 requires notification to the ICO. Article 34 requires notification to individuals only if the breach is likely to result in high risk of adversely affecting their rights and freedoms. High risk is a higher threshold than mere risk. Many breaches are notifiable to the ICO but not to individuals. A breach of payment card data from a secure payment processor may trigger high risk, requiring notification. A breach of a personnel file name and address from an HR system may not. The distinction requires legal judgment.

If a processor suffers the breach, is the controller still liable for the 72-hour notification?

Yes. Under Article 33, controllers are responsible for notifications even if the processor is responsible for the breach itself. A contract term stating that the processor will handle notification does not relieve the controller of this obligation. The controller must ensure that the processor notifies the controller immediately (the contract should require this as standard), and the controller then conducts triage and makes the decision on ICO notification.

Help responding to a data breach

Schedule an initial call

Representative experience

Recent and representative matters include:

Managed the breach response and ICO notification for a telecoms operator following a cyber-attack that compromised customer account data, coordinating technical forensics, legal assessment and regulatory engagement within the 72-hour notification window.
Advised a financial services firm on its Article 33 notification obligation after a third-party processor suffered a ransomware incident affecting client personal data, including the assessment of risk to individuals and the scope of the Article 34 communication duty.
Prepared and submitted ICO breach notifications for a technology company following the inadvertent disclosure of employee personal data, securing closure without enforcement action.
Designed a data breach response framework for a multinational, including escalation procedures, template ICO notifications, individual communications, and regulator engagement protocols across UK and EU jurisdictions.
Advised on the interaction between the UK GDPR breach notification obligations and Ofcom’s security incident reporting obligations under the Telecommunications (Security) Act 2021 for a dual-regulated operator.

Rob Bratby advises on data breach response and ICO engagement. He spent a year on secondment to Oftel, the predecessor of Ofcom, and holds fractional General Counsel appointments at regulated businesses. He is recognised in the Lexology Index as a Global Elite Thought Leader for telecoms and media, and as a Thought Leader for data privacy and protection.

Related data protection pages

See also our other data protection pages:

UK GDPR Compliance
Lawful Basis and Legitimate Interests
Data Protection Impact Assessments
Data Governance, Transfers and Accountability
UK/EU Data Protection Divergence
AI and Automated Decision-Making
The EU AI Act: what UK businesses need to know
Sector-Specific Data Protection
PECR and ePrivacy

Independent directory rankings

Our specialist expertise is recognised in major independent legal directories:

Chambers & Partners: Rob Bratby is ranked as a Band 2 lawyer in the UK Guide 2026 in the “Telecommunications” category: Chambers
The Legal 500: Rob Bratby is listed as a Leading Partner for Telecoms in London (TMT: IT and Telecoms). The Legal 500
Lexology: Rob Bratby is recognised in the Lexology Index as a Global Elite Thought Leader for telecoms and media, and as a Thought Leader for data privacy and protection: Lexology