Last updated: 3 November 2026

Data breach notification laws tell you who you must notify after a personal data breach, how fast, and what you must say. Under the GDPR and UK GDPR the regulator clock is 72 hours from awareness; South Africa's POPIA says "as soon as reasonably possible"; US states set their own rules, often 30 to 60 days for individuals. This guide puts the main regimes side by side, explains when the clock actually starts, and walks through a worked example of a single incident that triggers several laws at once.

It covers the GDPR, the UK, South Africa (POPIA), US state and federal rules, Canada, Australia, and the EU sector rules (NIS2 and DORA) that sit alongside privacy law. It is general information, not legal advice: confirm your position with counsel for any live incident.

Data breach notification deadlines at a glance

The table below summarises the regulator and individual deadlines. The detail, exceptions and sources for each regime follow in the sections below.

Regime Who you notify Deadline to regulator Deadline to individuals Threshold
EU GDPR Lead or competent supervisory authority; data subjects Without undue delay, where feasible within 72 hours of awareness Without undue delay Regulator: unless unlikely to result in a risk. Individuals: likely high risk
UK GDPR ICO; data subjects Without undue delay, not later than 72 hours of awareness Without undue delay Same risk tests as the EU GDPR
UK PECR (telecoms and ISPs) ICO Without undue delay, where feasible within 72 hours (24 hours before 20 August 2025) Where the breach is likely to adversely affect them Any personal data breach by a public electronic communications service
South Africa POPIA s22 Information Regulator (via the eServices portal); data subjects As soon as reasonably possible after discovery As soon as reasonably possible after discovery Reasonable grounds to believe personal information was accessed or acquired by an unauthorised person
US states (all 50 plus DC and territories) Residents; often the state attorney general Varies by state (for example 30 days in Colorado, Florida and Washington where thresholds are met) Varies: commonly 30 to 60 days Usually defined "personal information" (for example name plus ID or account number); risk-of-harm tests in some states
US HIPAA Individuals; HHS; media (500+ in a state) 500+: with individual notice. Under 500: within 60 days of year end Without unreasonable delay, no later than 60 calendar days after discovery Unsecured protected health information
US SEC (listed companies) Investors via Form 8-K Item 1.05 Four business days after determining the incident is material Not applicable Material cybersecurity incident
Canada PIPEDA Privacy Commissioner; individuals As soon as feasible As soon as feasible Real risk of significant harm
Australia NDB scheme OAIC; individuals at risk As soon as practicable (assessment within 30 days) As soon as practicable Eligible data breach (likely serious harm)
EU NIS2 CSIRT or competent authority Early warning 24 hours; notification 72 hours; final report one month Recipients of services, where appropriate Significant incident (not limited to personal data)
EU DORA Financial supervisor Initial 4 hours from classification as major, no later than 24 hours from awareness; intermediate 72 hours; final one month Clients, where the incident affects their financial interests Major ICT-related incident

Two practical points come out of this table. First, the strictest clock usually belongs to a sector or cyber rule (NIS2, DORA) rather than a privacy law, so security and privacy teams need one shared incident process. Second, a single incident often triggers several regimes with different thresholds, so you need to assess each one separately rather than applying the most famous rule (the 72-hour GDPR deadline) everywhere.

What counts as a personal data breach?

Before any deadline applies, you need a breach in the legal sense. The GDPR defines a personal data breach in Article 4(12) as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data". That covers far more than hacking:

  • Confidentiality breaches: an email with a spreadsheet of customer data sent to the wrong recipient, an exposed cloud storage bucket, a stolen laptop.
  • Integrity breaches: records altered without authorisation, for example bank details changed in a payroll system.
  • Availability breaches: ransomware that encrypts records, or loss of the only copy of data, even temporarily.

POPIA uses the term "security compromise" and focuses on personal information that has been "accessed or acquired by any unauthorised person" (section 22). US state laws generally define a narrower set of "personal information" (typically a name combined with a Social Security number, driver's licence number or financial account number with access codes), so an incident can be a GDPR breach but not a US state breach, or the reverse.

When does the 72-hour clock start?

Under GDPR Article 33(1), the controller must notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it". The EDPB Guidelines 9/2022 on personal data breach notification (version 2.0, adopted 28 March 2023) treat a controller as "aware" when it has a reasonable degree of certainty that a security incident has compromised personal data. A short initial investigation to establish that is acceptable; sitting on an alert is not.

Three rules make the clock workable in practice:

  1. Calendar hours, not business hours. The 72 hours run through weekends and public holidays.
  2. Phased notification is allowed. Article 33(4) lets you provide information "in phases without undue further delay" when you do not yet have the full picture. File what you know, then update.
  3. Late notification needs reasons. If you notify after 72 hours, Article 33(1) requires you to explain the delay.

Processors have their own duty. Article 33(2) requires a processor to notify the controller "without undue delay" after becoming aware of a breach. Your contracts should turn that into a specific number of hours, and your vendor risk assessments should check that suppliers can actually meet it. The controller's clock generally starts when the processor tells the controller, which is why slow vendor notification is one of the most common causes of late reports.

GDPR breach notification requirements

Notifying the supervisory authority (Article 33)

You must notify unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons". The notification must at least (Article 33(3)):

  • describe the nature of the breach, including the categories and approximate number of data subjects and records concerned;
  • give the name and contact details of the data protection officer or other contact point;
  • describe the likely consequences;
  • describe the measures taken or proposed, including mitigation.

Article 33(5) also requires you to document every personal data breach, including the ones you decide not to report, with the facts, effects and remedial action. Regulators can ask to see this log, and it is the evidence that your "unlikely to result in a risk" decisions were reasoned.

Which authority? Organisations with an EU establishment use the one-stop-shop and notify their lead supervisory authority. Organisations with no EU establishment do not benefit from the one-stop-shop simply by appointing an Article 27 representative: the EDPB guidelines say such controllers must notify every supervisory authority in whose Member State affected data subjects reside. For a South African or US company with customers across several EU countries, that can mean several parallel notifications.

Telling the individuals (Article 34)

Where a breach is "likely to result in a high risk", you must communicate it to the data subjects without undue delay, in clear and plain language. Article 34(3) removes that duty where:

  • the data was protected by measures such as encryption that make it unintelligible to anyone not authorised to access it;
  • you have taken subsequent measures that mean the high risk is no longer likely to materialise; or
  • individual communication would involve disproportionate effort, in which case you must use a public communication instead.

UK breach notification: UK GDPR and PECR

The UK kept the GDPR model. The ICO's guidance on personal data breaches says you must report a notifiable breach to the ICO "without undue delay, but not later than 72 hours after becoming aware of it", with the same risk tests and the same duty to tell individuals where the risk is high. The ICO notes that this guidance is under review following the Data (Use and Access) Act 2025, but the 72-hour rule itself is unchanged.

Telecoms providers and internet service providers also fall under the Privacy and Electronic Communications Regulations (PECR). Since 20 August 2025, the Data (Use and Access) Act has aligned the PECR timescale with UK GDPR: providers must report "without undue delay and where feasible, not later than 72 hours" after becoming aware, rather than within 24 hours as before (ICO PECR security breaches guidance).

POPIA breach notification in South Africa (section 22)

Section 22 of the Protection of Personal Information Act applies where there are reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person. The responsible party must notify both the Information Regulator and the data subject, unless the data subject's identity cannot be established.

POPIA requirement What the Act says
Timing (s22(2)) "As soon as reasonably possible after the discovery of the compromise", taking into account the legitimate needs of law enforcement and the measures needed to determine the scope of the compromise and restore integrity
Delay for law enforcement (s22(3)) Notification to data subjects may be delayed only if a public body responsible for the prevention, detection or investigation of offences, or the Regulator, determines that notification will impede a criminal investigation
Method (s22(4)) In writing: post to the last known address, email, a prominent notice on the website, publication in news media, or as the Regulator directs
Content (s22(5)) Enough information for data subjects to take protective measures: possible consequences, measures taken or intended, recommended steps for the data subject, and the identity of the unauthorised person if known
Operators (s21(2)) An operator (processor) must notify the responsible party "immediately" where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person

How to report to the Information Regulator. Since 1 April 2025, reporting security compromises through the Regulator's eServices portal has been mandatory for all organisations, replacing email submissions (Information Regulator media statement, April 2025; fact sheet on security compromises). Have your information officer registered on the portal before you need it, not during an incident.

POPIA has no fixed number of hours, but "as soon as reasonably possible" is not a licence to wait. If the same incident also triggers the GDPR, the 72-hour EU deadline will usually set the pace for your South African report as well. For the wider POPIA programme, see our POPIA compliance guide.

US data breach notification laws

There is no single federal breach law covering all personal data. According to the National Conference of State Legislatures, all 50 states, the District of Columbia, Guam, Puerto Rico and the US Virgin Islands have laws requiring notification of security breaches involving personal information. Each applies based on where the affected residents live, not where your company is based.

State laws: examples of deadlines

State Individuals Attorney general Source
California Within 30 calendar days of discovering or being notified of the breach (deadline added by SB 446, 2025) Sample notice if more than 500 residents Civ. Code 1798.82
Colorado Within 30 days after determining a breach occurred Within 30 days if 500+ residents Colorado AG
Florida As expeditiously as practicable, no later than 30 days (up to 15 more with good cause) Within 30 days if 500+ individuals Fla. Stat. 501.171
New York Most expedient time possible, within 30 days of discovery AG, Department of State and State Police (and DFS for covered entities) GBL 899-aa
Texas Without unreasonable delay, no later than 60 days after determining a breach occurred Within 30 days if at least 250 Texans Texas AG
Washington No more than 30 calendar days after discovery Within 30 days if more than 500 residents RCW 19.255.010

State laws change often, and many have amended their deadlines in recent years. Treat any table, including this one, as a starting point and check the current statute for each state where affected residents live.

Federal sector rules

  • HIPAA. Covered entities must notify affected individuals "without unreasonable delay and in no case later than 60 calendar days after discovery" of a breach of unsecured protected health information (45 CFR 164.404). Breaches affecting 500 or more people also require notice to HHS at the same time and, where more than 500 residents of a state are affected, to prominent media. Smaller breaches are logged and reported to HHS within 60 days of the end of the calendar year.
  • SEC. Public companies must disclose a material cybersecurity incident on Form 8-K Item 1.05, generally within four business days after determining that the incident is material (SEC press release, July 2023). The trigger is the materiality determination, which must be made without unreasonable delay after discovery.

Canada and Australia

Canada (PIPEDA). Organisations must report to the Office of the Privacy Commissioner any breach of security safeguards where it is reasonable to believe the breach "creates a real risk of significant harm", and notify affected individuals, "as soon as feasible" after determining the breach occurred (PIPEDA s10.1). The Breach of Security Safeguards Regulations require you to keep a record of every breach for 24 months, whether or not it was reported. Our explainer on Bill C-36 covers the proposed federal reform.

Australia (Notifiable Data Breaches scheme). Under the Privacy Act 1988, an entity that suspects an eligible data breach must take reasonable steps to complete an assessment within 30 days, and must notify the OAIC and individuals at risk as soon as practicable once it is aware of an eligible breach (OAIC quick reference guide).

NIS2 and DORA: incident reporting that runs alongside privacy law

NIS2 and DORA are not privacy laws. They cover significant or major incidents in general, whether or not personal data is involved, and they apply in addition to the GDPR.

NIS2 (Directive (EU) 2022/2555, Article 23). Essential and important entities must report significant incidents to their CSIRT or competent authority in stages:

  1. an early warning within 24 hours of becoming aware;
  2. an incident notification within 72 hours, with an initial assessment of severity and impact;
  3. an intermediate report on request;
  4. a final report no later than one month after the incident notification (or a progress report if the incident is still ongoing).

DORA (Regulation (EU) 2022/2554, Article 19, with Delegated Regulation (EU) 2025/301). Financial entities report major ICT-related incidents with an initial notification within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report no later than one month after the latest intermediate report.

If you are a SaaS provider to EU banks or critical-sector clients, expect your contracts to require you to notify them within a few hours, because their own regulatory clock is that short. That is a third-party risk question as much as a legal one.

Worked example: one incident, five notification decisions

The scenario is illustrative and simplified.

A Cape Town-based online learning platform sells subscriptions to individuals in South Africa, Germany, the Netherlands, the UK and the US. It has no EU establishment, but because it offers services to people in the EU, the GDPR applies under Article 3(2). Its billing is run by a payments processor. At 16:00 on a Friday the processor emails to say it has confirmed that an attacker exfiltrated a database the previous Tuesday. The database holds names, email addresses, bank account details and government ID numbers (collected for identity checks) for 2,400 subscribers: 1,900 in South Africa, 300 in Germany and the Netherlands, 120 in the UK and 80 in Texas.

Decision Assessment Action and deadline
Is it a breach? Yes: unauthorised disclosure of personal data (GDPR Art 4(12)); unauthorised acquisition (POPIA s22); Texas definition met (name plus government-issued ID number) Open an incident record; start the breach log entry
When did the clock start? Friday 16:00, when the processor told the company with reasonable certainty. Tuesday is when the attack happened, not when the controller became aware GDPR and UK GDPR deadline: Monday 16:00
EU regulators Risk is likely (financial data). No EU establishment, so no one-stop-shop: notify the German and Dutch supervisory authorities Notify both by Monday 16:00, in phases if facts are incomplete
UK ICO Same risk; 120 UK data subjects Notify the ICO by Monday 16:00
Information Regulator (SA) Reasonable grounds to believe personal information was acquired Notify via the eServices portal as soon as reasonably possible; in practice in the same window as the EU reports
Individuals High risk under GDPR (bank and ID numbers, fraud risk); POPIA requires notice regardless of risk level; Texas requires notice Send one plain-language notice that meets POPIA s22(5) and GDPR Art 34 content, without undue delay; Texas residents within 60 days at the latest
Texas attorney general Only 80 Texans affected, below the 250 threshold No AG notice required; document the decision

The lessons: the processor's three-day delay used up time the company never had, the strictest deadline (72 hours) governs the practical timeline even for laws with softer wording, and the "no notice required" decisions need documenting as carefully as the notifications.

How to build a breach notification process: step by step

  1. Map where your data subjects live. Notification duties follow residents, not your head office. Your data map and record of processing activities should show which jurisdictions each system's data covers, so you are not working it out during an incident.
  2. Write a jurisdiction matrix. One page listing each applicable regime, its trigger, its regulator deadline, its individual deadline, the regulator's reporting channel, and who in your team files. Use the table at the top of this guide as a template.
  3. Set contractual notice periods for processors and vendors. Specify hours, not "promptly". Twenty-four to forty-eight hours is common for processors handling sensitive data; shorter where your clients are under DORA or NIS2.
  4. Define "awareness" internally. Agree who can declare that a security incident is a personal data breach, and log the timestamp. That timestamp is what regulators will ask about.
  5. Create a single breach register. Record every breach, including those not reported, with facts, risk assessment per regime, decisions and evidence. GDPR Article 33(5) and Canada's regulations both require it.
  6. Prepare templates in advance. A regulator notification draft (Article 33(3) fields), an individual notice that also meets POPIA s22(5), and a holding statement for customers.
  7. Pre-register on reporting portals. The Information Regulator eServices portal, the ICO's breach reporting form, and any state AG portals you are likely to use.
  8. Run a tabletop exercise. Use a scenario like the worked example above, with a vendor-originated breach discovered late on a Friday. Time how long it takes to reach a notification decision.
  9. Review after every incident. Feed the root cause into your risk register and log remediation actions as issues with owners and due dates.

Frequently asked questions

Do I need to report every data breach?

No. Under the GDPR and UK GDPR you must report to the regulator unless the breach is unlikely to result in a risk to individuals, and tell individuals only where the risk is high. You must still document every breach. POPIA has no risk threshold: if there are reasonable grounds to believe personal information was accessed or acquired by an unauthorised person, you must notify the Regulator and the data subjects. US state laws usually apply only to defined categories of personal information, and some include a risk-of-harm test.

What is the GDPR 72-hour rule?

It is the requirement in Article 33 to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. The 72 hours are calendar hours, the clock starts at awareness rather than at the time of the attack, and you may submit information in phases. If you miss 72 hours you must give reasons for the delay.

How do I report a data breach to the ICO?

Use the ICO's online personal data breach reporting form within 72 hours of becoming aware of a notifiable breach. The ICO's guidance includes a self-assessment to help you decide whether a breach needs reporting. Telecoms and internet providers report PECR breaches separately, now also within 72 hours.

How do I report a security compromise under POPIA?

Through the Information Regulator's eServices portal, which has been mandatory for security compromise reports since 1 April 2025. You must also notify affected data subjects in writing (by post, email, a prominent website notice or news media) with enough detail for them to protect themselves, as soon as reasonably possible after discovery.

Does the GDPR apply to a breach at a US or South African company?

It can. If the GDPR applies to your processing under Article 3, for example because you offer services to people in the EU, the breach rules apply too. Without an EU establishment you cannot use the one-stop-shop, so you may need to notify the supervisory authority in each Member State where affected people live.

What should a data breach notification letter include?

At a minimum: a plain description of what happened, what information was involved, the likely consequences, what you have done and will do, what the individual should do to protect themselves (for example watch for phishing or contact their bank), and a contact point. Under POPIA include the identity of the unauthorised person if you know it. Check state-specific content requirements for US residents.

Keep breach decisions and evidence in one place

Breach notification is one part of a wider GRC programme. Deadlines are short; the evidence regulators ask for afterwards is detailed. Core GRC's risk and issue registers let you log incidents and breaches, record the assessment and notification decision for each regime, assign remediation as tracked issues, and link the incident back to the vendor and processing activity involved. Our DSR management and data mapping modules sit in the same platform, so the jurisdiction map you need during an incident is already there.

Cover photo by Mimi Thian on Unsplash