Breach notification: who you have to tell, and how fast

A single incident routinely triggers several notification obligations at once, to different recipients, on different deadlines, measured from different starting points. None of those clocks pause while you investigate, and the time to work out which apply is long before anything happens.

The clocks that typically run

• Data protection regulators - under GDPR and UK GDPR, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in risk to individuals. The Saudi PDPL and other regimes set their own periods; several are shorter.
• Affected individuals - where the breach is likely to result in high risk to them, without undue delay. A higher bar than regulator notification, so many breaches are reported to the regulator but not to individuals.
• Sector regulators - financial services, health, telecoms and critical infrastructure regimes often impose shorter deadlines. Some initial reports are due within 24 hours, and under regimes like NIS2 an early warning can be due faster still.
• Customers under contract - frequently the tightest of all. Enterprise contracts commonly demand 24 or 48 hours, and unlike regulation these are commitments you negotiated.
• Cyber insurers - policies usually require prompt notification, and late notice can prejudice the claim.
• Securities regulators for listed companies, on materiality.
• Payment brands and acquirers where card data is involved.
• Law enforcement - usually optional, occasionally expected.

Note the asymmetry: your contractual obligation to a customer is often shorter than your regulatory one. Teams that plan only around 72 hours discover on day one that a customer notification was due yesterday.

"Aware" is the word that decides everything

The regulatory clock starts at awareness, which means having a reasonable degree of certainty that a security incident occurred leading to personal data being compromised - not full understanding of scope or cause. You may take a short period to establish whether a breach has occurred; you may not use continued investigation as a reason to defer the clock indefinitely.

Practically: you will almost always notify with incomplete information. That is expected and permitted - regulators allow phased notification, where you provide what you know and supplement later. Waiting for complete facts is the more common failure.

Build the notification matrix now

A single table, maintained in advance, listing for each obligation:

• Who must be told - named regulator, customer, insurer.
• What triggers it - personal data, availability loss, card data, materiality.
• The deadline and its starting point - awareness, determination, or discovery.
• The channel - portal, email, phone - with credentials held somewhere reachable during an outage.
• Who is authorised to make the notification.
• What must be included.

Two practical details that cause real problems. First, regulator portals require registration and credentials - do that in advance, not at hour 60. Second, if your notification information lives only in the environment that is down, you have no plan; keep it offline.

What a regulator notification must contain

Broadly: the nature of the breach, categories and approximate numbers of individuals and records, the DPO or contact point, likely consequences, and measures taken or proposed. Where you cannot provide all of it, say so and follow up - phased reporting is explicitly allowed.

Telling individuals

Required where high risk to them is likely. It must be in clear, plain language and describe the likely consequences, the measures taken, and what the individual can do. Communicate directly unless disproportionate effort makes a public communication appropriate instead.

One exception worth knowing: if the data was rendered unintelligible to unauthorised parties - properly encrypted, with keys uncompromised - individual notification may not be required. This is the concrete, regulator-recognised payoff for encryption at rest, and it is worth stating in your business case for it.

The processor and supplier dimension

If you process on behalf of others, you must notify your controller without undue delay - you do not notify the regulator on their behalf. Conversely, when a supplier breaches your data, your clock starts when you become aware, so their contractual notification deadline directly determines whether you can meet yours. Suppliers with a 72-hour notification clause leave you with no time at all.

Record everything, including the decisions not to notify

You must document all breaches, including those you assessed as not notifiable, with the reasoning. Regulators examine that register - a set of consistently "not notifiable" conclusions with no analysis behind them is a finding in itself, and it is the evidence most organisations have not kept.

Key takeaways

• Several clocks run at once - contractual customer deadlines are often the shortest.
• The regulatory clock starts at awareness; notify with partial facts and supplement later.
• Build the notification matrix, register for portals and keep it available offline.
• Record the breaches you decided not to notify, with reasoning - regulators check.