United Kingdom — Breach Notification

A controller that becomes aware of a personal data breach must notify the Information Commissioner's Office (ICO) without undue delay and, where feasible, not later than 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The obligation is set out in UK GDPR Article 33(1), which mirrors EU GDPR Article 33 with one key post-Brexit modification: the supervisory authority is now "the Commissioner" (the ICO) rather than the member-state authority determined under Article 55 EU GDPR. Where the ICO notification is not made within 72 hours, it must be accompanied by reasons for the delay.

"Personal data breach" — the Article 4(12) definition

Under UK GDPR Article 4(12), 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." The definition is technology-neutral and encompasses confidentiality breaches (unauthorised disclosure or access), integrity breaches (unauthorised alteration), and availability breaches (loss or destruction, including ransomware encryption that renders data inaccessible to the controller). The ICO has noted that a breach is not limited to external cyberattacks—internal incidents such as an employee emailing personal data to the wrong recipient, or accidentally deleting a database, trigger the same notification analysis.

The "unlikely to result in a risk" carve-out

Article 33(1) UK GDPR creates a narrow exception: no notification is required if the controller determines, after assessment, that the breach is unlikely to result in a risk to the rights and freedoms of natural persons. ICO guidance states that controllers must document the reasons for non-notification, and the ICO can challenge the assessment during an audit or investigation. Factors relevant to the risk assessment include the categories of personal data involved (special-category data under Article 9, financial data, credentials), the volume of affected individuals, whether technical protection measures such as encryption were in place at the time of the breach, and the identity and likely intent of any unauthorised recipient. A breach affecting even a small number of individuals can cross the risk threshold if the data is sensitive or the consequences are severe (e.g., domestic-abuse victim address disclosed to alleged abuser).

The 72-hour clock — when does "becoming aware" start?

The clock starts when the controller has become aware that a breach has in fact occurred—not when the controller first suspects an incident or receives an alert. The ICO's breach guidance adopts the Article 29 Working Party's interpretation: a controller has "become aware" when it has a reasonable degree of certainty that a security incident has led to personal data being compromised. A security-information-and-event-management (SIEM) alert flagging anomalous access does not alone start the clock; confirmation that personal data was accessed or exfiltrated does. If the controller cannot establish all details within 72 hours—for example, the precise number of affected individuals or the full scope of exfiltrated records—the UK GDPR permits phased notification. Article 33(4) UK GDPR states that where it is not possible to provide all the required information at the same time, the information may be provided "in phases without undue further delay" after the initial report, provided the initial notification is timely and includes the information available at that stage.

Required content under Article 33(3)

The notification to the ICO must include, at minimum:

• Nature of the breach: a description including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned (Article 33(3)(a));
• Contact point: the name and contact details of the data protection officer (if appointed) or other point of contact where more information can be obtained (Article 33(3)(b));
• Likely consequences: a description of the likely consequences of the breach (Article 33(3)(c));
• Remedial measures: a description of the measures taken or proposed to be taken by the controller to address the breach, including, where appropriate, measures to mitigate possible adverse effects (Article 33(3)(d)).

The ICO provides an online breach-reporting form at ico.org.uk/for-organisations/report-a-breach/ that operationalises these statutory fields. The ICO has stated that it is preferable to submit an initial report within 72 hours with the information available and follow up with additional detail, rather than delay the initial report in an attempt to gather complete information.

Processor notification to controller — Article 33(2) UK GDPR

A processor that becomes aware of a personal data breach must notify the controller without undue delay. There is no statutory 72-hour outer limit for processor-to-controller notification, but the ICO expects "without undue delay" to mean notification within hours, not days, so that the controller has time to assess the breach and notify the ICO within its own 72-hour window. Article 28(3)(f) UK GDPR requires processor contracts to specify that the processor will "assist the controller … in ensuring compliance with the obligations … to notify the supervisory authority and … the data subject of a personal data breach"; many standard processor agreements therefore include an explicit 24- or 48-hour processor-to-controller notification deadline.

Documentation obligation — Article 33(5) UK GDPR

Controllers must document all personal data breaches—comprising the facts relating to the breach, its effects, and the remedial action taken—regardless of whether the breach was notified to the ICO. This internal breach log enables the ICO to verify compliance with Article 33. ICO guidance confirms that the log must be sufficiently detailed to demonstrate why a breach was or was not reported (i.e., the risk assessment and the reasoning supporting the controller's decision).

Relationship to EU GDPR for cross-border processing

Where a breach affects individuals in both the UK and EEA member states, the controller will typically need to report under both the UK GDPR (to the ICO) and the EU GDPR (to the lead supervisory authority under Articles 55/56 EU GDPR, applying the one-stop-shop mechanism). The ICO guidance reminds controllers to identify their EU lead supervisory authority as part of breach-response planning. The EU Commission's adequacy decision recognising the UK (Decision (EU) 2021/1772, extended by Decision (EU) 2024/1758) does not create a notification bridge—controllers must file separate notifications to the ICO and to the relevant EU supervisory authority.

Source: UK GDPR Art. 33, as retained and amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (S.I. 2019/419) (legislation.gov.uk) Source: Data Protection Act 2018, s. 67 (legislation.gov.uk) Source: ICO, Personal data breaches: a guide (ico.org.uk) Source: ICO, UK GDPR data breach reporting (DPA 2018) (ico.org.uk)

When a personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller must communicate the breach to the affected data subjects without undue delay. This obligation is set out in UK GDPR Article 34(1), which mirrors EU GDPR Article 34 with the same post-Brexit modification seen in Article 33: references to "the supervisory authority" have been replaced with "the Commissioner" (the ICO) by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (S.I. 2019/419). The high-risk trigger is a higher threshold than the "risk to rights and freedoms" standard that triggers ICO notification under Article 33—the ICO guidance states that "a 'high risk' means the threshold for informing individuals is higher than for notifying the ICO."

The "high risk" threshold and risk-assessment framework

Article 34(1) UK GDPR requires controllers to assess both the severity of the potential or actual impact on individuals and the likelihood of that impact materialising. ICO guidance confirms that if the impact is more severe, the risk is higher; if the likelihood of consequences is greater, the risk is again higher. Even a breach affecting a small number of individuals can cross the high-risk threshold if the data is sensitive or the consequences are severe. The ICO's breach-examples guidance illustrates this principle: a data controller who disclosed adoptive parents' names and address to birth parents should have notified the adoptive parents immediately, because the breach presented a high risk to their safety—the birth parents visited the address and had to be removed by police, forcing the adoptive parents and children to relocate.

Factors relevant to the high-risk assessment include the categories of personal data involved (special-category data under Article 9, financial data that may lead to identity fraud, or credentials), the volume of affected individuals, whether technical protection measures such as encryption were in place at the time of breach, the identity and likely intent of any unauthorised recipient, and the potential for discrimination, identity theft, fraud, financial loss, damage to reputation, or other significant social or economic disadvantage. ICO guidance emphasises that sensitive personal information of vulnerable people and financial information that may lead to identity fraud are both "likely to be high risk situations."

Content requirements — Article 34(2) UK GDPR

The communication to affected data subjects must describe in clear and plain language the nature of the breach and contain at least the information and measures set out in Article 33(3)(b), (c) and (d):

• Contact point: the name and contact details of the data protection officer (if appointed) or other contact point where more information can be obtained (Article 33(3)(b));
• Likely consequences: a description of the likely consequences of the personal data breach (Article 33(3)(c));
• Remedial measures: a description of the measures taken or proposed to be taken by the controller to address the breach, including, where appropriate, measures to mitigate its possible adverse effects (Article 33(3)(d)).

Unlike the Article 33 notification to the ICO, the data-subject communication under Article 34 does not require the controller to specify the categories and approximate number of data subjects and records concerned. The emphasis is on enabling individuals to understand the breach and take protective steps, not on quantifying the breach for regulatory oversight.

Three statutory exceptions to data-subject notification — Article 34(3) UK GDPR

Article 34(3) UK GDPR provides that the controller need not communicate the breach to data subjects if any of the following conditions are met:

1. Encryption or equivalent protection (Article 34(3)(a)): The controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the breach, in particular measures that render the data unintelligible to any person who is not authorised to access it, such as encryption. If the breached data was encrypted with a strong key that remains uncompromised, the data remains unintelligible to the unauthorised recipient and notification is not required. The ICO has confirmed that this exception applies where encryption or equivalent measures render the data "unintelligible" at the time of the breach.

1. Subsequent measures eliminating high risk (Article 34(3)(b)): The controller has taken subsequent measures which ensure that the high risk to the rights and freedoms of data subjects is no longer likely to materialise. For example, if a controller immediately reset all compromised credentials or successfully recovered all exfiltrated data before it could be misused, the residual risk may no longer be high. The controller must document the basis for concluding that the high risk has been eliminated.

1. Disproportionate effort (Article 34(3)(c)): Notifying each affected data subject individually would involve disproportionate effort. In such cases, the controller must instead make a public communication or take a similar measure whereby the data subjects are informed in an equally effective manner. The ICO guidance notes that this exception is narrow—controllers must still inform data subjects, but may do so via public announcement, website notice, or press release rather than individual emails or letters. Article 34(3)(c) does not permit silence; it permits an alternative communication method when direct contact is impracticable.

Article 34(4) UK GDPR provides that if the controller has not already notified the data subjects (for example, because one of the Article 34(3) exceptions applied or because the controller concluded that the breach did not present high risk), but the ICO considers that the breach is likely to result in a high risk, the ICO may require the controller to notify the data subjects or may issue a public statement itself. This supervisory override ensures that controllers' risk assessments remain subject to ICO review.

"Without undue delay" — timing and urgency

Article 34(1) requires communication "without undue delay." The ICO has stated that "this should take place as soon as possible," particularly if individuals need to take immediate steps to protect themselves (for example, changing passwords, monitoring bank accounts, or applying for fraud alerts). Unlike the Article 33 notification to the ICO, there is no explicit 72-hour outer deadline for data-subject notification, but the ICO expects controllers to prioritise urgency: the sooner individuals are informed, the sooner they can mitigate harm.

Where it is not possible to provide all required information at the same time—for example, because the full scope of the breach or the recommended mitigation steps are still under investigation—the controller may provide the information in phases, provided the initial communication is timely and includes the information available at that stage. This phased approach mirrors the Article 33(4) provision for ICO notifications.

Documentation and ICO oversight

Controllers must document all personal data breaches (whether reported to the ICO or notified to data subjects or neither) under Article 33(5) UK GDPR. The internal breach log must record the facts, effects, and remedial action, and must capture the controller's risk assessment and reasoning for each decision—including why a breach was assessed as not presenting high risk to data subjects, or why one of the Article 34(3) exceptions applied. The ICO can audit this documentation to verify compliance.

Relationship to EU GDPR for cross-border breaches

Where a breach affects individuals in both the UK and EEA member states, the controller will typically need to communicate under both UK GDPR Article 34 (to UK data subjects) and EU GDPR Article 34 (to EEA data subjects). The substantive rules are identical post-Brexit, but the controller must ensure that communication content and timing comply with both regimes and may need to coordinate with both the ICO and the relevant EU lead supervisory authority.

Source: UK GDPR Art. 34, as retained and amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (S.I. 2019/419) (legislation.gov.uk) Source: Data Protection Act 2018, s. 26 (legislation.gov.uk) Source: ICO, Personal data breaches: a guide (ico.org.uk)

A controller that fails to notify the Information Commissioner's Office (ICO) of a personal data breach when required under UK GDPR Article 33, or that fails to communicate a breach to affected data subjects when required under Article 34, is subject to administrative fines under the UK GDPR's two-tier penalty framework. The statutory maximum penalty for breach notification violations is governed by Article 83(4) UK GDPR, as retained and amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (S.I. 2019/419). The ICO has confirmed in published guidance that "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," whichever is higher.

The two-tier penalty structure — Article 83(4) and Article 83(5) UK GDPR

UK GDPR Article 83 establishes a graduated penalty framework with two discrete fine ceilings. Infringements of the breach notification obligations fall into the lower tier under Article 83(4), which covers violations of Articles 33 and 34 (notification to the supervisory authority and communication to data subjects), as well as certain other obligations including controller and processor duties under Article 28, conditions for consent under Articles 12–22, and data protection by design requirements under Article 25. The maximum fine for Article 83(4) infringements is £8.7 million or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher.

By contrast, the higher tier under Article 83(5) covers infringements of the core data protection principles under Article 5, lawful-basis requirements under Articles 6–9, data-subject rights under Articles 12–22, and international data-transfer restrictions under Articles 44–49. The Article 83(5) ceiling is £17.5 million or 4% of total worldwide annual turnover, whichever is higher. Article 83(6) creates a third category for non-compliance with an ICO order issued under Article 58(2), which carries the same £17.5 million / 4% ceiling as Article 83(5).

The Data Protection Act 2018 section 157 implements the UK GDPR's fine regime domestically. Section 157(1) confirms that the maximum penalty for a GDPR infringement is the amount specified in Article 83 of the UK GDPR. The ICO exercises its penalty powers under Part 6 of the Data Protection Act 2018, which sets out the procedures for issuing penalty notices and the criteria the Commissioner must consider when determining whether to impose a fine and, if so, the amount.

Article 83(1) and Article 83(2) — effective, proportionate, and dissuasive fines and the mandatory assessment factors

Article 83(1) UK GDPR requires the ICO to ensure that any administrative fine imposed is "effective, proportionate and dissuasive" in each individual case. Article 83(2) UK GDPR lists eleven factors the ICO must assess when deciding whether to impose a fine and when determining the amount. These factors apply to all infringements, including breach notification failures, and include:

• Nature, gravity, and duration (Article 83(2)(a)): The nature of the infringement (whether it concerns processing operations, the categories and number of data subjects, or data records), the seriousness of the infringement, and how long it persisted. A one-off late notification may be treated less severely than a systemic failure to report breaches over months or years.

• Intentional or negligent character (Article 83(2)(b)): Whether the controller's or processor's failure to notify was intentional or merely negligent. A deliberate decision to withhold notification to avoid regulatory scrutiny is an aggravating factor; a good-faith error or organisational oversight may be mitigating.

• Actions taken to mitigate damage (Article 83(2)(c)): Any measures the controller implemented to mitigate harm to data subjects. Prompt remedial action—such as immediately notifying the ICO upon discovering a late notification, implementing new breach-detection systems, or enhancing staff training—can reduce the penalty.

• Degree of responsibility (Article 83(2)(d)): The extent to which the controller or processor met its obligations under Article 32 (security of processing) and Article 25 (data protection by design and by default). A controller with robust security measures and a mature breach-response plan that nonetheless experienced a notification delay may receive more lenient treatment than one with weak security posture.

• Relevant previous infringements (Article 83(2)(e)): Whether the controller or processor has a history of data protection violations, particularly breach notification failures. Repeat offenders face higher fines.

• Degree of cooperation with the ICO (Article 83(2)(f)): The controller's willingness to engage with the ICO, provide requested information, and remedy the failure. Controllers that proactively disclose late notifications and cooperate fully with the ICO's investigation are likely to receive reduced penalties compared to those that obstruct or delay cooperation.

• Categories of personal data affected (Article 83(2)(g)): Whether the unreported breach involved special-category data under Article 9 (e.g., health data, biometric data, data revealing racial or ethnic origin), financial data, or credentials. A failure to notify a breach affecting sensitive data of vulnerable individuals is an aggravating factor.

• Manner in which the infringement became known to the ICO (Article 83(2)(h)): Whether the controller notified the breach voluntarily (even if late), or whether the ICO learned of it through a third-party complaint, media report, or audit. Self-reporting—particularly proactive late notification with a full explanation—is a significant mitigating factor. Article 83(2)(h) explicitly references "whether, and if so to what extent, the controller or processor notified the infringement."

• Compliance with prior ICO measures (Article 83(2)(i)): Whether the controller had previously been subject to an ICO enforcement notice, warning, or reprimand concerning the same subject-matter and whether it complied. Non-compliance with a prior order under Article 58(2) is an aggravating factor and may trigger the higher Article 83(6) penalty.

• Adherence to approved codes of conduct or certification mechanisms (Article 83(2)(j)): Whether the controller participates in an approved code of conduct under Article 40 or holds a data protection certification under Article 42. Participation may be a mitigating factor.

• Any other aggravating or mitigating factor (Article 83(2)(k)): Including financial benefits gained or losses avoided from the infringement (for example, by delaying breach notification to avoid immediate reputational harm or regulatory costs), the controller's size and resources, and any other circumstances relevant to the individual case.

The ICO's enforcement posture — warnings, reprimands, enforcement notices, and penalty notices

Article 58(2) UK GDPR grants the ICO a menu of corrective powers in addition to fines, including issuing warnings (Article 58(2)(a)), reprimands (Article 58(2)(b)), enforcement notices requiring the controller to bring processing into compliance (Article 58(2)(d)), and temporary or definitive limitations on processing (Article 58(2)(f)). Article 83(2) UK GDPR provides that fines "shall, depending on the circumstances of each individual case, be imposed in addition to, or instead of" these other measures. The ICO has published an Accountability Framework and Regulatory Action Policy stating that it prefers to work with organisations to achieve compliance and that fines are typically reserved for serious, persistent, or aggravated failures. For breach notification violations, the ICO may issue a reprimand or enforcement notice in cases of first-time late notification by a smaller controller with a strong compliance record, reserving monetary penalties for cases involving deliberate non-compliance, repeat violations, or significant harm to data subjects.

Interaction with other infringements — Article 83(3) UK GDPR

Article 83(3) UK GDPR provides that if a controller or processor "intentionally or negligently, for the same or linked processing operations, infringes several provisions" of the UK GDPR, the total fine shall not exceed the amount specified for the gravest infringement. In practice, a breach notification failure is often accompanied by a security-of-processing failure under Article 32 (a higher-tier Article 83(4) infringement, though with the same £8.7 million / 2% ceiling as breach notification), and in some cases by a violation of the security principle under Article 5(1)(f) (a higher-tier Article 83(5) infringement with the £17.5 million / 4% ceiling). Where the ICO finds multiple infringements arising from a single incident—for example, a controller failed to implement appropriate security measures, suffered a breach, and then failed to notify the ICO within 72 hours—the ICO will typically calculate a single fine under the highest applicable tier (in that scenario, Article 83(5) for the Article 5(1)(f) security principle violation), taking all infringements into account under the Article 83(2) assessment.

UK-specific modifications post-Brexit — sterling fine caps and references to "the Commissioner"

The retained UK GDPR differs from the EU GDPR in two respects relevant to penalties. First, all fine amounts are expressed in pounds sterling rather than euros. The £8.7 million cap under Article 83(4) UK GDPR was set by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (S.I. 2019/419) to approximate the €10 million cap in the EU GDPR at the time of Brexit. Similarly, the £17.5 million cap under Article 83(5) and (6) UK GDPR corresponds to the EU GDPR's €20 million. These amounts are fixed in domestic law and do not fluctuate with the EUR/GBP exchange rate. Second, all references to "the supervisory authority" or "the lead supervisory authority" in EU GDPR Article 83 have been replaced with "the Commissioner" (i.e., the ICO) in the UK GDPR, reflecting the UK's single-supervisory-authority regime and the end of the EU's one-stop-shop mechanism.

ICO enforcement decisions and examples

The ICO publishes penalty notices and enforcement notices on its website under the "Enforcement action" portal. As of 2026, the majority of published penalty notices for data protection failures involve security-of-processing violations under Article 32 or principle violations under Article 5(1)(f), often combined with late or absent breach notification. The ICO has confirmed in enforcement decisions that a controller's failure to notify a breach within the Article 33 72-hour window can result in a penalty even where the controller eventually notified late, particularly where the delay was substantial (weeks or months) or where the controller provided no adequate justification. The ICO guidance states that controllers should prioritise timely initial notification and provide further information in phases if necessary, rather than delay the notification in an attempt to gather complete details.

Under the Data Protection Act 2018 section 157 and Article 83 UK GDPR, the ICO may also issue a penalty for failure to notify a breach under Part 3 (law enforcement processing) or Part 4 (intelligence services processing) of the DPA 2018. For law enforcement processing under DPA 2018 Part 3, the higher maximum penalty is £17.5 million or 4% of total worldwide annual turnover for serious infringements including breach notification failures under section 67 DPA 2018 (which mirrors Article 33 UK GDPR). For intelligence services processing under Part 4, a failure to notify a "serious personal data breach" under section 108 DPA 2018 carries the same penalty framework.

Source: UK GDPR Art. 83, as retained and amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (S.I. 2019/419) (legislation.gov.uk) Source: Data Protection Act 2018, s. 157 (legislation.gov.uk) Source: ICO, Personal data breaches: a guide (ico.org.uk)

Controllers must document all personal data breaches—regardless of whether the breach was notified to the Information Commissioner's Office (ICO) or to data subjects—under UK GDPR Article 33(5), which provides that "the controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken." This documentation obligation applies equally to notifiable breaches (those presenting a risk to rights and freedoms under Article 33(1)), high-risk breaches requiring data-subject communication under Article 34(1), and sub-threshold incidents that the controller determined did not meet the notification criteria. The purpose is to enable the ICO to verify compliance with the breach notification regime during audits, investigations, and enforcement actions. Article 33(5) states explicitly that "that documentation shall enable the Commissioner to verify compliance with this Article."

Scope of the documentation obligation — capturing all breaches and near-misses

The Article 33(5) requirement is technology- and sector-neutral and applies to every controller subject to UK GDPR. The ICO's breach guidance confirms that controllers must keep a record of any personal data breaches regardless of whether notification is required. The ICO's audit framework guidance goes further, recommending that controllers also log "near misses"—security incidents that had the potential to become a personal data breach but were contained before data was compromised. While near-miss logging is not a statutory requirement under Article 33(5), the ICO treats it as a best-practice indicator of a mature breach-detection and response capability, and many organisations incorporate near-miss tracking into the same breach log for trend analysis and root-cause identification.

Minimum content requirements — facts, effects, and remedial action

Article 33(5) UK GDPR specifies three mandatory categories of information that the breach log must capture:

1. The facts relating to the personal data breach: This includes the nature of the breach (confidentiality, integrity, or availability incident), the date and time the breach occurred (if known) and the date and time the controller became aware of it, the cause of the breach (e.g., ransomware attack, phishing, employee error, third-party processor failure, lost device), the categories and approximate number of affected data subjects, the categories and approximate number of personal data records compromised, and a description of the personal data involved (including whether it includes special-category data under Article 9, financial data, credentials, or other sensitive information).

1. Its effects: The breach log must document the actual or likely consequences of the breach for affected individuals and for the controller. This includes whether data subjects have experienced or are likely to experience harm (identity theft, financial loss, reputational damage, emotional distress, physical harm), whether the breach resulted in unauthorised access, disclosure, loss, or destruction of data, and whether technical protection measures such as encryption or pseudonymisation were in place and effective at the time of the breach.

1. The remedial action taken: The log must record the measures the controller implemented to contain and mitigate the breach, including immediate containment steps (e.g., disabling compromised accounts, isolating affected systems, revoking access credentials), notification actions (whether the breach was reported to the ICO, whether data subjects were informed, whether the controller notified any other parties such as processors, the police, or financial institutions), technical and organisational measures adopted post-breach to prevent recurrence (e.g., patch deployment, staff training, policy updates, strengthened access controls), and any ongoing remedial actions or planned improvements.

The risk-assessment rationale and the Article 83(2)(h) incentive

Critically, the breach log must capture the controller's risk assessment and decision-making rationale for each breach. The ICO guidance states that controllers must document the reasons for non-notification when a breach is assessed as not presenting a risk to rights and freedoms and therefore not notified under Article 33(1). This documentation is essential because the ICO can audit the breach log during routine inspections or in response to a complaint and can challenge the controller's assessment if it determines that a breach should have been reported. The ICO's published breach examples illustrate this dynamic: in one scenario, a controller initially assessed a lost-laptop breach as low-risk and did not report it, but upon discovering the laptop was unencrypted, updated the breach log to reflect the escalation and then reported to the ICO late. The controller was able to use the internal breach log to explain the delay, demonstrating that the initial non-notification was based on a good-faith (though ultimately incorrect) assessment rather than wilful non-compliance.

Article 83(2)(h) UK GDPR creates a further incentive for robust breach logging: it requires the ICO to consider "the manner in which the infringement became known to the supervisory authority, in particular whether, and if so to what extent, the controller or processor notified the infringement" when determining the amount of any administrative fine. Self-reporting—including proactive late notification accompanied by a full explanation documented in the breach log—is an explicit mitigating factor under Article 83(2) and can significantly reduce penalties even when the controller has missed the 72-hour deadline.

Retention period for breach logs — balancing accountability and data minimisation

UK GDPR Article 33(5) does not specify a retention period for breach logs. The ICO's audit framework guidance addresses this tension, stating that controllers should "set out a retention period for breach logs that contain personal information and establish a lawful basis for their retention" and should "regularly review the contents of breach logs for possible excessive retention." The ICO recommends that controllers apply data minimisation techniques—such as anonymising or pseudonymising entries after the risk of regulatory follow-up has passed, or redacting names and contact details of affected individuals while retaining anonymised aggregate data for trend analysis—to comply with the storage limitation principle under Article 5(1)(e) UK GDPR.

Many UK organisations adopt a three to five year retention period for breach log entries, aligned with the ICO's general statute-of-limitations practice (the ICO typically does not pursue enforcement action for breaches discovered more than three years after occurrence, absent exceptional circumstances) and with common document retention schedules for audit and legal purposes. The Data Protection Act 2018 does not impose a statutory minimum or maximum retention period for breach logs, so controllers must justify their chosen retention period under Article 5(2) accountability and be prepared to demonstrate that the period is necessary for compliance, audit, and trend-analysis purposes.

Format, access controls, and centralisation

Article 33(5) UK GDPR does not prescribe a specific format for the breach log. The ICO has published a template breach log form that many controllers use, but controllers may also use spreadsheets, database systems, incident-management platforms, or integrated governance-risk-compliance (GRC) tools. The critical requirement is that the log is sufficiently detailed to demonstrate what happened, why the controller made the decisions it made, and what steps were taken—enough detail to enable the ICO to verify compliance.

The ICO's audit framework guidance emphasises that controllers should "seek assurance that all personal data breaches and near misses are captured centrally (e.g., there are no locally held breach logs)" and should "only give access to the breach log to staff who need it." Decentralised or shadow breach logs—maintained by individual departments without consolidation into a master log—create audit risk because the ICO cannot verify that all breaches have been assessed consistently or that notifiable breaches were escalated to the appropriate decision-makers. Access controls are essential because breach logs themselves contain personal data (details of affected individuals, contact information, descriptions of harm) and must be protected under Articles 5(1)(f) and 32 UK GDPR.

The ICO's audit and enforcement posture

The ICO routinely requests breach logs during data protection audits, investigations triggered by data-subject complaints, and enforcement actions following publicised incidents. Failure to maintain a breach log—or maintaining an incomplete, inconsistent, or obviously post-hoc log—is itself a breach of Article 33(5) UK GDPR. While the ICO has not, as of 2026, published a standalone penalty notice exclusively for breach-log non-compliance, the absence or inadequacy of a breach log is frequently cited as an aggravating factor in enforcement decisions where the ICO has imposed fines for underlying security-of-processing failures under Article 32 or breach-notification failures under Article 33(1). The ICO's regulatory action policy confirms that controllers demonstrating a mature, well-documented breach-response capability—evidenced by a detailed, contemporaneous breach log—are more likely to receive warnings, reprimands, or enforcement notices rather than monetary penalties for first-time or low-severity violations.

The ICO's published breach examples also illustrate how the breach log functions as a compliance record. In one scenario involving a Scottish pharmacy that delivered medication to the wrong patient, the pharmacist decided that the risk to the affected individual was unlikely (the medication was returned unopened) and did not report the breach to the ICO, but documented the decision in the internal breach log. The ICO guidance confirms that "if, having received a complaint from the data subject, the ICO wanted to know why the pharmacy had not reported the breach, they would be able to refer to the rationale recorded on the internal breach log." This scenario demonstrates that the breach log serves as the controller's contemporaneous audit trail for notification decisions, protecting the controller from allegations of wilful non-compliance when the decision was a reasonable exercise of judgment at the time.

Trend analysis, strategic oversight, and continuous improvement

Beyond regulatory compliance, the ICO encourages controllers to use breach logs for trend analysis and root-cause identification. The ICO's accountability framework guidance recommends that controllers "undertake trend analysis on breach reports over time to understand themes or issues" and that "groups with oversight for data protection and information governance review the outputs." Common trends revealed by breach-log analysis include repeated phishing incidents (suggesting a need for enhanced staff training), frequent misconfigured-email incidents (indicating a technical control gap that can be addressed with email encryption or data-loss-prevention tools), or clustering of breaches among particular processors (signaling the need for enhanced Article 28 oversight or processor substitution). The ICO's audit framework treats evidence of regular senior-management review of breach logs and evidence of remedial actions flowing from trend analysis as indicators of Article 5(2) accountability and Article 24 controller-responsibility compliance.

Relationship to other recordkeeping obligations

The Article 33(5) breach log is distinct from, but often integrated with, other UK GDPR documentation obligations. Controllers must maintain a record of processing activities (ROPA) under Article 30 UK GDPR (though controllers with fewer than 250 employees are exempt unless the processing is not occasional, is likely to result in a risk to rights and freedoms, or includes special-category data or criminal-conviction data). Many controllers integrate their breach log with their ROPA, their data protection impact assessment (DPIA) register, and their information-security incident log to create a unified compliance record. The ICO's audit framework treats such integration as a best practice, provided that access controls ensure that only authorised personnel can view each component.

Source: UK GDPR Art. 33(5), as retained and amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (S.I. 2019/419) (legislation.gov.uk) Source: ICO, Personal data breaches: a guide (ico.org.uk) Source: ICO, Breach identification, assessment and logging — Data Protection Audit Framework (ico.org.uk) Source: ICO, Personal data breach examples (ico.org.uk)

A processor that becomes aware of a personal data breach must notify the controller without undue delay under UK GDPR Article 33(2), which provides that "a processor shall notify the controller without undue delay after becoming aware of a personal data breach." This duty is statutory and applies to all processors subject to UK GDPR, regardless of whether the processor contract explicitly requires notification. However, the contract between the controller and processor must also address breach notification under Article 28(3)(f) UK GDPR, which requires the processor to assist the controller in ensuring compliance with the controller's own obligations to notify the Information Commissioner's Office (ICO) under Article 33(1) and to communicate breaches to data subjects under Article 34.

The "without undue delay" standard and the timeline engineering problem

Article 33(2) UK GDPR does not specify an outer deadline in hours or days for processor-to-controller notification, unlike the controller's 72-hour deadline to notify the ICO under Article 33(1). The ICO's guidance states that processors must notify controllers "without undue delay" and confirms that this phrase is deliberately flexible but in practice means notification within hours, not days. The ICO expects processor notification to be sufficiently rapid that the controller retains enough time to assess the breach, determine whether it crosses the Article 33(1) risk threshold, and—if notifiable—report to the ICO within the controller's own 72-hour window after the controller becomes aware.

This creates a practical timeline-engineering challenge: if a processor delays notification until the 48-hour or 60-hour mark after the processor became aware of the breach, the controller may have insufficient time to investigate, assess risk, gather the required Article 33(3) information, and submit a compliant ICO notification before the 72-hour clock (measured from when the controller became aware) expires. The ICO has confirmed in published guidance that controllers remain responsible for timely notification even when the breach originates at a processor, and a controller cannot excuse a late ICO notification solely by pointing to a processor's delay in notifying the controller—though the ICO will consider processor delay as a mitigating factor under Article 83(2) when determining penalties.

In practice, most UK controller–processor agreements therefore include an explicit 24-hour or 48-hour processor-to-controller notification SLA, calibrated to leave the controller a meaningful window to meet its own 72-hour ICO deadline. Many standard-form processor contracts—including those based on the ICO's template contract clauses and on the EU Standard Contractual Clauses (SCCs) adopted for UK use—specify that the processor must notify the controller "within 24 hours" or "as soon as reasonably practicable and in any event within 48 hours" after the processor becomes aware of a breach.

Article 28(3)(f) UK GDPR — mandatory contract clause requiring processor assistance with breach notification

UK GDPR Article 28(3) sets out nine categories of mandatory clauses that must appear in every controller–processor contract. Article 28(3)(f) UK GDPR requires that the contract stipulate that the processor will "assist the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36," which include:

• Article 32 (security of processing);
• Article 33 (notification of a personal data breach to the supervisory authority);
• Article 34 (communication of a personal data breach to the data subject);
• Article 35 (data protection impact assessment); and
• Article 36 (prior consultation with the supervisory authority).

The contract must specify that the processor's assistance obligation takes into account "the nature of processing and the information available to the processor." The ICO's guidance on Article 28 contracts confirms that this clause requires the processor to provide the controller with the information and cooperation necessary to enable the controller to comply with its breach notification duties. In the breach-notification context, this means the processor must:

1. Notify the controller promptly when a breach occurs, so the controller can begin its own 72-hour clock and risk assessment;
2. Provide sufficient detail for the controller to determine whether the breach is notifiable under Article 33(1) (i.e., whether it is likely to result in a risk to rights and freedoms);
3. Supply the Article 33(3) required information or assist the controller in gathering it, including the categories and approximate number of affected data subjects and records, the nature of the breach, the likely consequences, and the remedial measures taken or proposed by the processor; and
4. Cooperate with the controller's follow-up investigation, including providing logs, forensic reports, and updates as the processor learns more about the scope and impact of the breach.

The ICO recommends that controller–processor contracts specify how the processor will assist—for example, by naming a processor security contact or incident-response team email address, specifying the format and minimum content of the processor's initial breach notification, and requiring phased updates if the processor cannot provide complete information immediately.

The processor's 72-hour clock does not restart the controller's clock

A common misunderstanding is that the controller's 72-hour deadline begins only when the processor notifies the controller. This is incorrect. Article 33(1) UK GDPR states that the controller must notify the ICO "not later than 72 hours after having become aware of" the breach. The controller "becomes aware" of a breach at the moment the processor notifies it (or, if the controller learns of the breach from another source—such as a data subject complaint or media report—at that earlier moment). The processor's own awareness and the processor's delay in notifying the controller do not extend the controller's 72-hour window.

For example, if a processor becomes aware of a breach at 9:00 AM on Monday and notifies the controller at 3:00 PM on Tuesday (a 30-hour delay), the controller's 72-hour clock starts at 3:00 PM on Tuesday, and the controller must report to the ICO by 3:00 PM on Friday (assuming the breach is notifiable). If the processor delays until Thursday morning, the controller may have fewer than 72 hours remaining before its own deadline expires, creating acute operational pressure. This asymmetry is why controllers negotiate tight processor notification SLAs.

Controller liability for processor breaches — Article 82 and Article 83

The controller remains primarily liable for data protection compliance, including compliance with breach notification obligations, even when the breach occurs at a processor. Under Article 82 UK GDPR, an individual harmed by a breach can bring a claim for compensation against either the controller or the processor (or both jointly), but the controller "shall be liable for the damage caused by processing which infringes [the UK GDPR]" unless the controller can prove "it is not in any way responsible for the event giving rise to the damage." In practice, this means that a controller whose processor suffers a breach due to inadequate processor security measures or delayed processor notification may still be liable to affected individuals unless the controller can demonstrate it met its own Article 28(1) due-diligence obligation to "use only processors providing sufficient guarantees to implement appropriate technical and organisational measures."

Similarly, under Article 83 UK GDPR, the ICO can impose administrative fines on the controller for failing to notify a breach under Article 33(1), even when the underlying security failure occurred at the processor. The controller's primary defence in such a scenario is to demonstrate that (a) the processor contract included robust Article 28(3)(f) assistance clauses and a tight notification SLA, (b) the controller conducted appropriate due diligence when selecting the processor, and (c) the controller acted promptly once the processor notified it. Article 83(2)(h) UK GDPR explicitly requires the ICO to consider "the manner in which the infringement became known to the supervisory authority, in particular whether, and if so to what extent, the controller or processor notified the infringement" when determining the fine amount, so a controller that self-reports a late notification and provides evidence of processor delay and subsequent remedial action is likely to receive a reduced penalty compared to a controller that concealed the breach or failed to report it at all.

Processor liability for its own breach notification failures

The processor is also subject to direct ICO enforcement for its own breach of Article 33(2) UK GDPR. If the processor fails to notify the controller without undue delay, the ICO can issue a reprimand, enforcement notice, or administrative fine against the processor. The maximum penalty for breach notification failures is set by Article 83(4) UK GDPR at £8.7 million or 2% of the processor's total worldwide annual turnover, whichever is higher. However, the ICO's enforcement posture to date has favoured enforcement against controllers (who bear primary responsibility for compliance) and has imposed penalties on processors primarily where the processor's failure was egregious—for example, a processor that delayed notification for weeks or months, or a processor that failed to notify the controller at all and the controller learned of the breach from a third party.

The processor may also incur contractual liability to the controller under the terms of the Article 28 contract. Many controller–processor agreements include indemnity clauses requiring the processor to indemnify the controller for ICO fines, compensation claims by data subjects, and other losses resulting from the processor's breach of the contract, including late or absent breach notification. The enforceability of such indemnity clauses is subject to UK contract law principles (including reasonableness under the Unfair Contract Terms Act 1977 in some contexts), but the ICO's guidance confirms that well-drafted indemnity clauses can allocate financial risk between controller and processor in line with their respective responsibilities.

Sub-processors and the notification chain

Where a processor engages a sub-processor (a processor-to-processor arrangement), the same "without undue delay" notification duty applies at each link in the chain. Article 28(4) UK GDPR requires the processor to impose "the same data protection obligations as set out in the contract or other legal act between the controller and the processor" on any sub-processor, including the Article 28(3)(f) obligation to assist with breach notification. This means that if a sub-processor becomes aware of a breach, the sub-processor must notify the processor without undue delay, and the processor must in turn notify the controller without undue delay.

In practice, multi-tiered supply chains create compounding delay risk: if each link in the chain takes 24 hours to notify the next, a breach discovered by a third-tier sub-processor may not reach the controller until 72 hours have elapsed, leaving the controller with zero time to assess and report before its own ICO deadline. Controllers should therefore require processors to map and disclose their sub-processor chains and to impose cascading notification SLAs that ensure the controller receives notice within a fixed absolute window (e.g., 24 hours from breach discovery by any processor or sub-processor in the chain), regardless of the number of intermediaries.

Recommended contract language and operational implementation

The ICO's published guidance on controller–processor contracts recommends that Article 28 contracts include specific language addressing breach notification. Recommended provisions include:

• A requirement that the processor notify the controller "without undue delay and in any event within [24 / 48] hours" after becoming aware of a personal data breach;
• A definition of "becoming aware" aligned with the Article 33(1) standard (reasonable degree of certainty that a breach has occurred, not mere suspicion);
• A requirement that the processor's initial notification include, at minimum, the nature of the breach, the date and time the processor became aware, the categories of data affected, and the processor's emergency contact details;
• A requirement that the processor provide follow-up information in phases if complete details are not available within the initial notification window;
• A requirement that the processor assist the controller in compiling the Article 33(3) required information (categories and number of data subjects and records, likely consequences, remedial measures);
• Specification of the notification method and contact points (e.g., email to a designated controller security email address, with escalation to a named individual if no acknowledgment is received within a specified time);
• A requirement that the processor document all personal data breaches in its own internal breach log (mirroring the controller's Article 33(5) obligation) and make that log available to the controller upon request; and
• Indemnity or liability clauses allocating financial responsibility for ICO fines and data subject compensation claims arising from processor breach notification failures.

Operationally, controllers should verify during Article 28(3)(h) audits and inspections that the processor has implemented breach-detection and incident-response procedures capable of meeting the contractual notification SLA. Common audit checkpoints include evidence of 24/7 security monitoring, documented breach escalation procedures, staff training on breach identification and reporting, and testing of the processor-to-controller notification pathway (e.g., through tabletop exercises or simulated breach scenarios).

Source: UK GDPR Art. 33(2), as retained and amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (S.I. 2019/419) (legislation.gov.uk) Source: UK GDPR Art. 28(3)(f), as retained and amended (legislation.gov.uk) Source: ICO, What does it mean if you are a processor? (ico.org.uk) Source: ICO, What needs to be included in the contract? (ico.org.uk) Source: ICO, Personal data breaches: a guide (ico.org.uk)

A processor that becomes aware of a personal data breach affecting data it processes on behalf of a controller must notify that controller without undue delay under UK GDPR Article 33(2). This processor-to-controller notification duty applies to all personal data breaches the processor becomes aware of, regardless of whether the breach meets the risk threshold that would trigger a controller's Article 33(1) duty to notify the Information Commissioner's Office (ICO). The processor does not assess whether the breach is reportable to the ICO—that determination is the controller's responsibility. Article 33(2) UK GDPR provides simply: "A processor shall notify the controller without undue delay after becoming aware of a personal data breach." The provision mirrors EU GDPR Article 33(2) verbatim, with no post-Brexit modification.

No statutory 72-hour deadline for processor notification, but "without undue delay" means hours, not days

Unlike the Article 33(1) controller-to-ICO notification, which must occur "without undue delay and, where feasible, not later than 72 hours after having become aware" of the breach, Article 33(2) contains no explicit 72-hour outer limit for processor notification to the controller. The statute requires only "without undue delay." However, the ICO has made clear that this phrase imposes a more urgent practical timeline than 72 hours. ICO guidance on processor obligations states: "if you become aware of a personal data breach, you must notify the relevant controller without undue delay. Most controllers will expect to be notified immediately, and may contractually require this, as they only have a limited time in which to notify the supervisory authority (such as the ICO)."

The practical implication is that "without undue delay" for processor notification should be measured in hours, not days. A processor that delays notification by 24, 48, or 72 hours may prevent the controller from meeting its own 72-hour ICO notification deadline under Article 33(1), which in turn exposes the controller to administrative fines under Article 83(4) UK GDPR and triggers the Article 83(2)(h) inquiry into whether the controller self-reported the breach or whether the ICO learned of it from a third party. Many controller–processor contracts therefore impose explicit notification deadlines—commonly 12, 24, or 48 hours from the processor's awareness of the breach—and treat late notification as a material breach of contract subject to indemnification. The ICO's published guidance confirms this expectation: "You must also assist the controller in complying with its obligations regarding personal data breaches."

Article 28(3)(f) — the contractual assistance duty

Article 28(3)(f) UK GDPR reinforces the processor's breach-notification and breach-assistance duty by requiring that the processor contract include terms under which the processor "assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor." Article 33 (breach notification to the ICO) and Article 34 (communication to data subjects) fall within Articles 32 to 36, so the processor's contractual duty to assist the controller in breach compliance is a statutory requirement, not merely a negotiated term. This assistance obligation goes beyond the Article 33(2) notification itself: the processor must provide the controller with the information necessary to assess the breach under Articles 33 and 34, to populate the Article 33(3) required content fields in the ICO notification, and to determine whether the breach crosses the Article 34(1) high-risk threshold requiring data-subject communication.

In practice, Article 28(3)(f) assistance typically includes the processor providing the controller with: the date and time the breach occurred (if known) and the date and time the processor became aware of it; a description of the nature of the breach (confidentiality, integrity, or availability incident; cyberattack, employee error, system failure, or third-party sub-processor failure); the categories and approximate number of affected data subjects and the categories and approximate number of personal data records compromised; a description of the data involved, including whether it includes special-category data under Article 9, financial data, credentials, or other sensitive information; whether technical protection measures such as encryption or pseudonymisation were in place and effective at the time of the breach; the processor's initial assessment of the cause and scope of the breach; immediate containment measures the processor has implemented; and any ongoing investigation or remedial actions. The processor must update the controller as new information becomes available, consistent with the Article 33(4) phased-notification principle that applies to controller-to-ICO reports.

When does a processor "become aware" of a breach?

The Article 33(2) clock starts when the processor has "become aware" of a personal data breach. The ICO applies the same "reasonable degree of certainty" standard to processors as it does to controllers: the processor has become aware when it has established that a security incident has in fact occurred and has led to personal data being compromised, not merely when the processor first receives a security alert or suspects an incident. A processor's security-information-and-event-management (SIEM) system flagging anomalous access does not alone start the Article 33(2) clock; confirmation that personal data was accessed, disclosed, altered, lost, or destroyed does.

However, processors must not delay notification to the controller while conducting a lengthy internal investigation to establish every detail of the breach. The ICO expects processors to notify controllers as soon as the processor has reasonable certainty that a breach has occurred, and to provide additional information in phases as it becomes available. This expectation aligns with the controller's own obligation under Article 33(4) to notify the ICO within 72 hours even if full details are not yet known and to submit further information "without undue further delay" as the investigation progresses. A processor that withholds notification from the controller for days or weeks while attempting to quantify the exact number of affected records or the precise cause of the breach would breach Article 33(2), even if the processor eventually provides a complete report.

All breaches, not just high-risk or ICO-reportable breaches

Article 33(2) contains no risk threshold. The processor must notify the controller of every personal data breach the processor becomes aware of, including breaches that the controller may ultimately determine are unlikely to result in a risk to rights and freedoms and therefore not reportable to the ICO under Article 33(1). The ICO guidance confirms: "Processors have to notify the controller 'without undue delay' if they become aware of a breach. This is not restricted to 'serious' breaches. … It is the responsibility of the controller to determine whether a breach meets the criteria to be … reportable to the ICO. Therefore the processor should report all breaches to you, so you can make this assessment."

This asymmetry—processors notify all breaches to controllers, but controllers notify only risk-presenting breaches to the ICO—reflects the division of responsibility under the UK GDPR. The processor does not determine the purposes and means of processing (Article 4(8) definition of processor), does not choose the lawful basis under Article 6, and does not conduct the risk assessment required by Articles 33(1) and 34(1). The controller retains those determinations. The processor's role is to provide the controller with timely, accurate information so the controller can exercise its assessment and notification duties.

Processor liability for failure to notify — Article 83(4) fines and Article 82 compensation

A processor that fails to notify the controller of a breach without undue delay is subject to administrative fines under Article 83(4) UK GDPR. The maximum fine for processor breach-notification violations is £8.7 million or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher—the same tier as controller failures under Article 33(1). Article 83(2)(f) requires the ICO to consider "the degree of cooperation with the supervisory authority" when determining the fine amount; a processor that proactively notifies the controller late (and documents the reason for the delay) is likely to receive more lenient treatment than one that fails to notify at all or delays notification for weeks without justification.

Under Article 82(1) UK GDPR, the processor is also exposed to private claims for compensation. Article 82(2) provides that "a processor shall be liable for the damage caused by processing only where it has not complied with obligations of this Regulation specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller." Article 33(2) is an obligation "specifically directed to processors." If a processor's failure to notify the controller without undue delay causes the controller to miss the Article 33(1) 72-hour ICO notification deadline, and the controller incurs an Article 83(4) fine from the ICO as a result, the controller may be entitled to recover that fine (or a portion of it) from the processor under Article 82(4), which permits liability sharing among joint controllers and processors "where more than one controller or processor … is involved in the same processing." The extent of such recovery depends on the allocation-of-responsibility provisions in the controller–processor contract and the ICO's assessment under Article 83(2)(d) of "the degree of responsibility … taking into account technical and organisational measures implemented" by the controller and processor.

Contractual notification deadlines — 12-, 24-, and 48-hour SLAs in practice

Because Article 33(2) provides no explicit deadline and the phrase "without undue delay" is inherently fact-dependent, many controller–processor contracts specify a concrete notification deadline to operationalise the statutory duty. Common contractual notification deadlines include:

• 12 hours: Common in high-risk or highly regulated sectors (financial services, healthcare, government contractors) where the controller needs maximum time to investigate and assess before the 72-hour ICO clock expires.
• 24 hours: A widely adopted standard for cloud service providers, SaaS vendors, payment processors, and other commercial processors. The ICO's "most controllers will expect to be notified immediately" language suggests that 24 hours is likely the outer boundary of what qualifies as "without undue delay" in most contexts.
• 48 hours: Occasionally seen in lower-risk processing scenarios or legacy contracts predating the UK GDPR. A 48-hour processor notification SLA leaves the controller with only 24 hours to assess the breach, prepare the ICO notification, and submit it within the 72-hour window, which the ICO has characterised as inadequate in published breach examples.

The ICO has not published guidance specifying a safe-harbor timeline for processor notification, but in enforcement decisions and published breach examples the ICO has criticised delays of several days or weeks. Controllers negotiating processor contracts should specify a notification deadline that aligns with the Article 33(1) 72-hour controller obligation and should require the processor to provide phased updates as the investigation progresses, mirroring the Article 33(4) framework. Contractual deadlines do not displace the statutory "without undue delay" duty—they operationalise it, and a processor remains liable under Article 33(2) if it meets a contractual 48-hour SLA but the delay nonetheless prevents timely controller notification to the ICO.

Sub-processors and the chain-of-notification duty

Where a processor engages a sub-processor (a processor's processor) under Article 28(2) and (4) UK GDPR, and the sub-processor experiences a breach, the sub-processor must notify the processor without undue delay, and the processor must in turn notify the controller without undue delay. The UK GDPR does not permit a sub-processor to notify the controller directly unless the controller–processor contract explicitly authorises such direct notification. Article 28(4) UK GDPR provides that "where a processor engages another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor … shall be imposed on that other processor by way of a contract." This includes the Article 33(2) notification duty. Many controller–processor contracts require the processor to flow down equivalent notification deadlines to all sub-processors and to notify the controller immediately upon receiving a sub-processor breach notification, rather than waiting to conduct an investigation before escalating.

Relationship to Data Protection Act 2018 Part 3 (law enforcement processing)

For processors processing personal data on behalf of controllers under Part 3 of the Data Protection Act 2018 (law enforcement processing), section 67(9) DPA 2018 imposes an equivalent duty: "If a processor becomes aware of a personal data breach (in relation to personal data processed by the processor), the processor must notify the controller without undue delay." The structure and wording mirror Article 33(2) UK GDPR, and the ICO applies the same "hours, not days" practical expectation to law-enforcement processors as it does to UK GDPR processors.

Source: UK GDPR Art. 33(2), as retained and amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (S.I. 2019/419) (legislation.gov.uk) Source: UK GDPR Art. 28(3)(f) (legislation.gov.uk) Source: Data Protection Act 2018, s. 67(9) (legislation.gov.uk) Source: ICO, What does it mean if you are a processor? (ico.org.uk) Source: ICO, Personal data breaches: a guide (ico.org.uk)

Controllers report personal data breaches to the Information Commissioner's Office (ICO) using the ICO's online breach reporting portal at ico.org.uk/for-organisations/report-a-breach/. The portal is the primary statutory notification channel for Article 33(1) UK GDPR notifications. The ICO guidance states that "you can report a breach online" and that "the online form should take approximately 30 minutes to complete." Controllers must ensure they have all relevant breach details assembled before starting the form, because the ICO guidance confirms: "Please ensure you have all the details regarding the breach ready before you start—you can't save the form and return at a later date."

Form content requirements and phased reporting

The online form operationalises the Article 33(3) UK GDPR content requirements: the controller must provide a description of the nature of the breach (including, where possible, the categories and approximate number of affected data subjects and records), the name and contact details of the data protection officer or other contact point, a description of the likely consequences, and a description of remedial measures taken or proposed. The ICO's guidance emphasises the need for organisations to "report early, update later": "We recognise that a detailed understanding of what happened may take time, however it is important that we receive a factually accurate account as soon as possible." The ICO confirms that "it may not be possible for you to provide a full and complete picture of what has happened within the 72-hour reporting requirement, especially if the breach is complex and possibly ongoing," but controllers are legally required to meet the 72-hour timeframe and should "provide whatever relevant information you have to us at this stage." The controller can provide additional details later "as long as you do this without undue delay," mirroring the Article 33(4) phased-notification provision.

The form collects the controller's organisational details, the reporter's name, email address, and contact phone number, and the name and details of an alternative contact person if the reporter is not the primary point of contact for ICO follow-up. The ICO's privacy notice for breach reporting confirms that the lawful basis for collecting this personal data is Article 6(1)(e) UK GDPR (processing necessary to perform the ICO's public tasks as a regulator), and that the ICO collects this information "so we can communicate with you about the breach."

Automated confirmation and case creation

Upon submission, the ICO sends the reporter an email containing a copy of the submitted information and a reference number for future correspondence. Controllers should save this confirmation email to document the date and time of submission for Article 33(5) breach-log purposes and as evidence of timely notification under Article 83(2)(h). The ICO's privacy notice for breach reports discloses that the ICO uses "large language models from Microsoft Azure AI Services to automate the creation of new personal data breach cases in our case management system," and that "all breach reports are then reviewed by a member of ICO staff who will decide on the appropriate case outcome." The ICO confirms that it does not use any data processors for handling breach reports themselves; the LLM automation is an ICO-operated tool for intake processing.

This automated intake does not constitute the ICO's substantive decision. Every breach report is subsequently reviewed by an ICO staff member who assesses the case and determines the appropriate outcome. The ICO evaluates the categories of personal data involved (with particular attention to special-category data under Article 9 UK GDPR), the number of affected individuals, the likely consequences for data subjects, the controller's containment and remedial measures, and whether the controller notified data subjects under Article 34.

Case outcomes — advice, closure, or escalation to investigation

The ICO's published guidance confirms that "not every breach reported to us results in formal action. Our main aim is to provide advice to help the organisations avoid similar incidents in the future." The ICO's role is "to uphold information rights and help to protect people's personal information. By working with organisations to comply with the law and providing appropriate support when breaches occur, we can help to ensure that organisations get it right in future."

For many breach reports—particularly those involving limited data, prompt containment, effective remedial measures, and low risk to individuals—the ICO will close the case with an advisory letter and no further enforcement action. For other cases, the ICO may request additional information from the controller to clarify the scope of the breach, the controller's risk assessment, or the adequacy of remedial measures. The ICO may ask for evidence of staff training, audit logs, processor contracts, or updates on whether the controller has notified affected data subjects under Article 34. Controllers should respond to ICO inquiries promptly and completely; the ICO's assessment of the controller's degree of cooperation under Article 83(2)(f) UK GDPR is an explicit mitigating or aggravating factor in any subsequent penalty decision.

In serious cases, the ICO may escalate the matter to formal investigation. The ICO's guidance states that "depending on the impact of the breach, we may decide to use our investigative or enforcement powers, or both, under data protection laws." The ICO may exercise its investigative powers under Article 58 UK GDPR, including issuing information notices, conducting audits, and—if the investigation substantiates a breach of the notification obligation or an underlying security failure—issuing enforcement notices, reprimands, or monetary penalties under Article 83.

Information sharing and coordination with other authorities

The ICO states explicitly that "where appropriate, we may share the information you provide with law and cybercrime agencies or other regulators, such as the Financial Conduct Authority. If an incident is relevant to another country, we may also share the information with appropriate regulatory representatives in that country." Controllers reporting breaches affecting individuals in the European Economic Area should therefore be aware that the ICO may share the breach report with the controller's EU lead supervisory authority under the EU GDPR's one-stop-shop mechanism, and may coordinate enforcement action with that authority.

The ICO also encourages controllers to report certain types of breaches to other UK authorities in parallel with the ICO notification. For cyber incidents, the ICO states: "If you've experienced a cyber incident you can report to the NCSC [National Cyber Security Centre]. The NCSC is the UK's independent authority on cyber security, providing cyber incident response to the most critical incidents affecting the UK." The ICO advises controllers to "read the NCSC's guidance about its role and the type of incidents that you should consider reporting to them." For breaches involving suspected criminal activity, the ICO recommends: "When an incident occurs that you believe may have criminal intent, you should consider reporting this to Report Fraud—the UK's national fraud and cybercrime reporting centre. If your organisation is in Scotland, then you should make a report to Police Scotland." The ICO notes that "where appropriate, we may liaise with the above organisations about the incidents reported to us."

What controllers should not expect — no acknowledgment of risk assessment or pre-clearance

Controllers should understand that submitting a breach report to the ICO does not constitute the ICO's endorsement of the controller's risk assessment or remedial measures. The automated confirmation email and reference number are evidence of receipt, not approval. The ICO does not provide real-time feedback during the 72-hour notification window, and controllers should not delay data-subject notification under Article 34 while waiting for ICO guidance. The ICO may challenge the controller's risk assessment weeks or months after the initial report. Controllers must document their own Article 33(1) and Article 34 decision-making rationale in the Article 33(5) breach log contemporaneously, because that log—not the ICO's eventual response—is the evidence of the controller's accountability under Article 5(2) UK GDPR.

The ICO's guidance for small organisations reassures controllers: "It's understandable if you're concerned about what happens next. But we're here to help you understand what happened and to prevent it happening again." The ICO emphasises that controllers should prioritise timely initial notification even if the full details are not yet known: "Don't worry if you haven't got all the information to hand straight away—the important part is letting us know that it's happened before 72 hours have passed. You can always provide more later as part of a follow-up report if necessary."

Source: ICO, UK GDPR data breach reporting (DPA 2018) (ico.org.uk) Source: ICO, Report a breach (all controllers) — privacy notice (ico.org.uk) Source: ICO, Personal data breaches: a guide (ico.org.uk) Source: ICO, 72 hours — how to respond to a personal data breach (ico.org.uk)