
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
Data breach response is the controlled, structured process of managing a personal data breach from discovery to remediation. When a data breach occurs, organisations face two critical challenges: first, to contain the incident and preserve evidence whilst minimising harm; second, to determine whether, when and to whom notification obligations apply. Most organisations lack a pre-prepared breach response plan, which means critical decisions fall to whoever is in the room when the breach is discovered. In the absence of clear governance, paralysis sets in, regulators find evidence tampering, and notifications arrive too late or too inconsistent. Legal advisors instructed at the outset preserve privilege over the investigation and coordinate notification across multiple regulators. This section explains how breach response works, where organisations typically fail, and how specialist input protects both compliance and legal position.
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, controllers must notify the Information Commissioner’s Office without undue delay and no later than 72 hours from the point of awareness. 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. This distinction matters because many organisations spend weeks investigating before concluding that a breach has happened, and only then does the 72-hour clock begin. 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.
Breach notification obligations do not apply to one regulator. Controllers subject to UK GDPR and PECR (the Privacy and Electronic Communications Regulations 2003) face notification obligations to the ICO under both regimes. Communications providers (such as telecoms operators) must also notify Ofcom under the Telecommunications (Security) Act 2021 of any security compromise with a significant effect on the network. Operators of essential services and relevant digital service providers fall within the Network and Information Systems Regulations 2018, which requires notification to the competent authority (the ICO for relevant digital service providers) within 72 hours of becoming aware of an incident likely to have a significant impact. Financial services firms regulated by the FCA face additional operational incident reporting obligations which will be substantially strengthened from 18 March 2027. 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
Regulatory enforcement is increasingly focused on how organisations respond to breaches, not merely on the incident itself. The ICO’s enforcement activity shows a clear pattern: the penalty reduction in material settlements turns on evidence of improvement to incident response and containment procedures. The Capita case illustrates this. In October 2025, the ICO fined Capita £14 million for a March 2023 breach affecting 6.6 million individuals. The ICO’s initial proposed fine was £45 million. The reduction to £14 million reflected not the seriousness of the breach itself but Capita’s response to it: improvements made to security controls after the incident, support provided to affected individuals (including 12 months free credit monitoring), cooperation with other regulators including the National Cyber Security Centre, and engagement with the ICO. The settlement framework now applied across the ICO’s enforcement practice shows penalty reductions of 40 per cent for early settlement, 30 per cent for partial settlement, and 20 per cent for late settlement. This means that an organisation which detects a breach, immediately instructs legal advisors, notifies regulators truthfully and promptly, and works cooperatively through the investigation can reduce a potential £45 million fine to £14 million.
The regulatory environment is also becoming more complex. The Privacy and Electronic Communications Regulations (PECR) maximum penalty has increased to £17.5 million as of 5 February 2026, aligned with UK GDPR. The Data Use and Access Act 2025 gives the ICO new powers to compel interviews with staff (with as little as 24 hours notice in urgent cases) and to commission technical reports by approved experts. These new powers are now in force and are being actively used. The practical effect is that organisations can no longer avoid scrutiny by controlling which documents are produced: the ICO can now require named employees to attend interviews and answer questions under caution. Organisations without a documented breach response plan face both regulatory penalties and operational chaos when these interviews occur.
Where breach response goes wrong
Common failures cluster around five points. First, many organisations lack any pre-agreed breach response plan. This means there is no clear point of escalation, no designated incident commander, no pre-agreed checklist of containment steps, and no template notifications. The first hours of an incident are the most critical. Without a plan, the IT team contains the incident (correctly) whilst the PR team drafts a statement (incorrectly) and nobody notifies legal until legal finds out by accident. Second, assessment paralysis: organisations become stuck classifying and quantifying the breach instead of containing it. Determining the precise number of affected individuals, the exact scope of data accessed, and the true cause of the breach can take weeks. Containment cannot wait. Regulatory notification requires an initial assessment within hours, not a final answer within weeks. Third, forensic evidence is lost. Once an incident is contained, the impulse is to restore systems to normal operation. Evidence of the breach and the attacker’s activity is often overwritten in this process. Fourth, regulatory notification comes too early (before facts are established, leading to inconsistent updates) or too late (after 72 hours have passed, triggering enforcement action). Fifth, inconsistent notification across regimes: the ICO notification under UK GDPR may correctly state that the breach is not notifiable to individuals under Article 34, but the report to Ofcom under the Telecommunications (Security) Act may describe the incident differently, creating confusion and encouraging the ICO to investigate.
Two additional failures are common. Organisations often involve PR or external communications before conducting legal analysis. Once a public statement is issued, the regulator has a fixed version of events to investigate. Contradictions between the public statement and later factual findings become evidence of dishonesty. Finally, many organisations fail to document breaches that do not trigger Article 33 notification. The UK GDPR requires controllers to maintain a record of all breaches (Article 33(5)), even those not notified to the ICO. This record becomes critical evidence of the organisation’s breach handling processes during enforcement investigations.
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 set of template notifications 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. Legal privilege protects this planning if the plan is created by or at the direction of legal advisors with the dominant purpose of obtaining legal advice or conducting litigation.
During an incident, rapid triage is the critical first step. Within hours, not days, the organisation must determine three things: has a notifiable breach occurred; if so, to which regulators must notification be made; and what is the risk profile of the incident (high risk triggering individual notification under Article 34, or lower risk). This triage does not require a forensic investigation. It requires access to sufficient factual information to allow legal judgment. The incident commander should ask: what personal data was accessible; could an unauthorised person have accessed it; is there evidence that they did; and if so, is there high risk of adverse effects on rights and freedoms. If the answer to any of the first three questions is uncertain, the safest assumption is that a breach has occurred and 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. Multi-regime notification coordination is essential: legal advisors should ensure that the notification to the ICO under UK GDPR, the notification to Ofcom under the Telecommunications (Security) Act, and any notification to the FCA or other regulator 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. The key advantage of instructing specialist breach response counsel at the moment of discovery is that legal privilege attaches to the investigation from the outset. This means that the investigators’ findings, the legal advisors’ analysis, and the strategy for regulator engagement are all protected from disclosure to the ICO or other parties. An organisation which conducts an investigation without legal involvement cannot claim privilege over the findings, which then become discoverable to regulators during enforcement action.
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: if there is any reasonable possibility that personal data has been accessed or disclosed without authorisation, instruction should not be deferred pending internal investigation. 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 public disclosure by the organisation can trigger individual notification obligations under Article 34 even if the regulator might not otherwise require it); 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.
Instructing advisors after the internal investigation is complete destroys privilege over the 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 appropriate workflow is: discovery of breach triggers instruction of legal advisor; legal advisor directs containment and evidence preservation; IT team executes these directions; and only then does the investigative work proceed with legal privilege attached.
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. If an external forensic firm is instructed by lawyers as part of legal work, and the investigation findings are reported to the lawyers (not directly to the organisation), privilege over the forensic findings is protected. If the forensic firm is instructed by the IT department or business team, or if findings are reported directly to the business without passing through legal advisors, privilege is not established. The forensic firm should be instructed by the legal advisor with the purpose of assisting in 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?
Delay beyond 72 hours is a breach of Article 33 itself and constitutes evidence of poor incident response procedures. If notification is missed, the ICO should be notified immediately with an explanation for the delay. 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. Many contracts incorrectly state that the processor will handle notification. 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.
Need help responding to a data breach?
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 When must I notify the ICO of a data breach? and Ofcom’s security incident reporting obligations under the Telecommunications (Security) Act 2021 for a dual-regulated operator.
Rob Bratby has advised on data breach response and ICO engagement drawing on his regulatory background at Oftel and Ofcom and his General Counsel roles at regulated businesses. Bratby Law is recognised by Lexology as a Global Elite Thought Leader for data protection.
Related data protection pages
See also our other data protection pages:
- Data Protection Impact Assessments
- UK/EU Data Protection Divergence
- PECR and ePrivacy
- Data Governance, Transfers and Accountability
- UK GDPR Compliance
- AI and Automated Decision-Making
- Sector-Specific Data Protection
See also our related telecoms and payments regulation pages:
- Telecoms Security (TSA 2021, Ofcom security duties)
- Operational Resilience and DORA (FCA operational resilience, PS26/2)
- Complaints and Investigations (Ofcom enforcement)
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 – Telecoms” in London (TMT – IT & Telecoms): The Legal 500
- Lexology: Rob Bratby is featured on Lexology’s expert profiles as a Global Elite Thought Leader for data: Lexology



Ready to discuss your matter?
Primary sources
- UK GDPR, Article 33 — Notification of a personal data breach to the supervisory authority
- UK GDPR, Article 34 — Communication of a personal data breach to the data subject
- Data Protection Act 2018, section 67 — Notification of personal data breach to the Commissioner (Part 3, law enforcement)
- Data Protection Act 2018, section 68 — Communication of personal data breach to the data subject (Part 3, law enforcement)
- Network and Information Systems Regulations 2018 (SI 2018/506)
- Communications Act 2003, section 105K — Notification of security compromise
- ICO — Report a breach
