A single incident that touches personal data in several countries can start five or six different notification clocks at once, each with its own trigger, threshold, regulator and content rules. The 72-hour GDPR deadline is the one most teams know, but it is not the shortest: Brazil counts three business days, Singapore three calendar days from the assessment, China's new incident rules count in hours, and sector regimes such as NIS2, DORA and the SEC disclosure rule run in parallel. This guide compares the main national regimes side by side, as checked against official or primary sources in October 2026, and shows how to build one response process that meets all of them. It is written for incident responders, privacy and legal teams, and the executives who sign off notifications. US state laws and the step-by-step GDPR and US playbook are covered elsewhere and are linked, not repeated.
Key takeaways
- Clocks start at different moments. GDPR counts from awareness, Singapore from the assessment that the breach is notifiable, Canada from the determination that a breach occurred, and the SEC from the materiality determination, so record each of those decision times.
- Thresholds differ more than deadlines. "Risk", "high risk", "real risk of significant harm", "serious harm" and "relevant risk or damage" are different tests, and some regimes (Japan, Singapore) add numeric triggers of 1,000 or 500 individuals.
- Phased reporting is normal. Most regimes accept an initial notice followed by updates: GDPR Article 33(4), Japan's preliminary and final reports, Brazil's 20 business day supplement and NIS2's 24 hour, 72 hour and one month sequence.
- Record every incident, notified or not. GDPR Article 33(5), PIPEDA section 10.3 and Brazil's ANPD regulation all require internal breach records, and Brazil sets a five year minimum.
- Machine credentials change the analysis. Leaked API keys, tokens and authentication data are expressly treated as high-harm categories in Singapore and Brazil, and agent-driven incidents are already being notified to regulators.
Scope: who and what is covered
This guide covers personal data breach notification to regulators and individuals in the EU, UK, Canada, Australia, Singapore, Japan, Brazil, China and India, plus three sector regimes that commonly run alongside them. It does not cover US state breach laws in detail: see the US State Privacy Laws Guide for the state privacy statutes and the Data Breach Notification Checklist for the operational GDPR and US state workflow. Health data rules such as HIPAA are covered in the HIPAA Security Rule Guide.
- Who: the controller, data fiduciary, organisation or "APP entity" is almost always the party that notifies. Processors and data intermediaries usually owe a duty to tell the controller, not the regulator: GDPR Article 33(2) requires the processor to notify the controller without undue delay.
- What: a personal data breach, meaning loss, unauthorised access, disclosure, alteration or destruction of personal data. Encryption by ransomware counts as a loss of availability and can be notifiable even with no exfiltration.
- Where: most regimes apply based on where the affected individuals are or where the organisation operates, so a single SaaS incident can trigger several of them. Map regimes by data subject location, not by your headquarters.
Key obligations
The table compares deadlines, thresholds and regulators. Figures are taken from the primary or official source listed in the references; where a figure was not confirmed from a source read for this guide, the cell says "check current text".
| Jurisdiction and law | Threshold to notify regulator | Deadline to regulator | Individuals | Regulator |
|---|---|---|---|---|
| EU: GDPR Articles 33 and 34 | Unless the breach is unlikely to result in a risk to rights and freedoms | Without undue delay and, where feasible, not later than 72 hours after becoming aware; reasons required if later | Where high risk (Article 34), without undue delay | Lead or competent supervisory authority (Article 55) |
| UK: UK GDPR and Data Protection Act 2018 | Where a risk to people's rights and freedoms is likely | As soon as possible and, where feasible, within 72 hours | Where risk is high, without undue delay | ICO (online form) |
| Canada: PIPEDA section 10.1 | Reasonable to believe the breach creates a real risk of significant harm | As soon as feasible after determining the breach occurred | Same threshold, direct and conspicuous notice | Office of the Privacy Commissioner |
| Australia: Privacy Act 1988, Part IIIC (NDB scheme) | Eligible data breach: likely to result in serious harm | As soon as practicable (s 26WK); suspected breaches assessed within 30 days (s 26WH) | As soon as practicable after the statement is prepared (s 26WL) | OAIC |
| Singapore: PDPA Part 6A | Significant harm likely, or 500 or more individuals | As soon as practicable, no later than 3 calendar days after determining it is notifiable | Where significant harm is likely, at the same time as or after the PDPC | PDPC |
| Japan: APPI Article 26 | Sensitive data; risk of financial harm; unlawful act such as a cyberattack; more than 1,000 individuals | Preliminary report within about 3 to 5 days; final report within 30 days (60 days where an unlawful purpose is suspected) | Required, as the situation allows | Personal Information Protection Commission |
| Brazil: LGPD Article 48 and ANPD Resolution CD/ANPD 15/2024 | Incident that may cause relevant risk or damage to data subjects | 3 business days from knowing personal data was affected; supplement within 20 business days; small agents get double | 3 business days; public notice for at least 3 months if direct notice is not possible | ANPD |
| China: PIPL Article 57 and CAC incident reporting Measures (from 1 November 2025) | PIPL: leak, tampering or loss of personal information; Measures: graded cybersecurity incidents | PIPL: immediate remedial measures and notification; Measures: 1 hour (CIIOs), 2 hours (state organs), 4 hours (other network operators) for reportable incidents; summary within 30 days of closure | PIPL Article 57, with exceptions where harm is effectively avoided (check current text) | CAC and sector regulators; Public Security Bureau for CIIOs |
| India: DPDP Act 2023 section 8(6) and DPDP Rules 2025 | Any personal data breach | Intimation to the Board without delay; detailed report within 72 hours | Without delay, in plain language | Data Protection Board of India |
Sector regimes that run in parallel
| Regime | Who | What is reported | Timing |
|---|---|---|---|
| NIS2 Directive (EU) 2022/2555, Article 23 | Essential and important entities under national transposition | Significant incidents to the CSIRT or competent authority | Early warning within 24 hours of awareness, incident notification within 72 hours, final report within one month of the notification (progress report if still ongoing) |
| DORA, Regulation (EU) 2022/2554 | EU financial entities, applying from 17 January 2025 | Major ICT-related incidents, classified under RTS 2024/1772, reported under RTS 2025/301 and ITS 2025/302 | Initial, intermediate and final reports: check current text of RTS 2025/301 |
| SEC Form 8-K Item 1.05 | US-listed registrants (foreign private issuers use Form 6-K) | Material cybersecurity incidents | Four business days after determining the incident is material; delay only on Attorney General notice of national security or public safety risk |
A personal data breach in an EU bank can therefore require a GDPR notice to the data protection authority and a DORA report to the financial supervisor, and a listed parent may also need an 8-K. See the NIS2 Directive Guide, the DORA Guide and the SEC Cybersecurity Disclosure Rules Guide for the detail of each.
Content of a notification
Required content converges on the same core, so draft one template and add local fields:
- Nature of the breach: categories and approximate numbers of individuals and records (GDPR Article 33(3)(a)); the kinds of information involved (Australia s 26WK(3)).
- Contact point: the DPO or another contact (GDPR Article 33(3)(b); India requires a contact for queries in the notice to individuals).
- Likely consequences and measures taken: GDPR Article 33(3)(c) and (d); Brazil asks for the risk assessment and mitigation.
- Steps individuals should take: required in Australia's statement and Canada's notice, and good practice everywhere.
Timeline and current status
Status as checked on 24 October 2026 against the sources listed below. Laws in this area change often, so confirm before relying on any figure.
- GDPR: Articles 33 and 34 are unchanged in the text read. Proposals to simplify GDPR have been discussed at EU level; check current text before relying on the 72 hour rule for future incidents.
- UK: the Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025, and the ICO states that its breach reporting guidance is under review. The 72 hour test still applies as of the ICO page read. The UK GDPR and Data Protection Act 2018 guide in this series covers the wider regime.
- Canada: PIPEDA breach reporting applies; the federal reform bill (Bill C-27) did not complete passage, so PIPEDA remains the federal law. A separate Canada guide in this series covers PIPEDA and reform proposals.
- Australia: the NDB scheme applies as described by the OAIC. Separate ransomware payment reporting under the Cyber Security Act 2024 is covered in the Ransomware Payments and Sanctions Guide, and the wider landscape in the Australian Privacy and Cyber Rules Guide.
- Singapore: mandatory notification has applied since 1 February 2021.
- Japan: APPI reporting has applied since the 2022 amendments; a further amendment Act was promulgated in July 2026 and includes changes to individual notification for low-risk breaches, to be phased in by Cabinet Order. Check current text.
- Brazil: ANPD Resolution 15/2024 sets the three business day rule and replaced earlier ANPD guidance.
- China: the CAC National Cybersecurity Incident Reporting Measures took effect on 1 November 2025 and apply to all network operators.
- India: the DPDP Rules 2025 were notified on 13 November 2025; the breach notification provisions commence 18 months later, around May 2027, according to the law firm summary read. Plan now, but check the commencement notification.
- NIS2: transposition deadline was 17 October 2024; national laws and their reporting portals still vary by member state.
- SEC: Form 8-K Item 1.05 has applied since 18 December 2023 (smaller reporting companies 180 days later).
Enforcement and penalties
| Regime | Penalty exposure for notification failures |
|---|---|
| GDPR and UK GDPR | Administrative fines under Article 83 for infringing Articles 33 and 34 (lower tier); check current text and the ICO fining guidance for UK amounts |
| Canada PIPEDA | Knowingly failing to report or keep records is an offence under section 28: check current text for amounts |
| Australia | Failure to comply is an interference with privacy (s 13(4A)), opening OAIC enforcement including civil penalty proceedings: check current text for amounts |
| Singapore | PDPC financial penalties and directions under the PDPA; check current text for maximum amounts and published PDPC decisions |
| Brazil | ANPD sanctions under LGPD Article 52: check current text |
| China | Late, missing or false reports create liability under the Cybersecurity Law, Data Security Law and PIPL; timely reporting and reasonable measures can mitigate penalties |
| India | Up to INR 200 crore for failing the section 8(6) notification duty; up to INR 250 crore for failing reasonable security safeguards |
| NIS2 | Member state fines for essential and important entities, plus management accountability: see the NIS2 Directive Guide |
In practice, regulators penalise late or missing notification less often than the underlying security failure, but a late notice with no recorded reasons for the delay removes the main mitigating argument.
What it means for AI agents and non-human identities
Most breaches that reach regulators now involve a non-human credential somewhere in the chain, and the first notified agent-driven incidents have already appeared.
- Credentials are notifiable data: Singapore's regulations deem account authentication data a category causing significant harm, Brazil lists system authentication data as a risk factor, and Japan names login ID and password pairs for payment services. A leaked API key or token that unlocks personal data should move the assessment toward "notify".
- Agent incidents are already reported: the Spain AEPD AI agent breach was notified to the Spanish regulator in September 2026 after an autonomous agent logged in, searched for flaws and accessed personal data and invoices. The OpenAI agent Medicare portal breach shows the other side: the activity was found about eight weeks later and reported to a generic inbox, which is how notification clocks get missed.
- Awareness depends on machine telemetry: the GDPR clock starts at awareness. If service account and agent activity is not logged and reviewed, you cannot show when you became aware or scope the affected records.
- Scoping needs an NHI inventory: to state "categories and approximate number of records" you need to know what each compromised key, token or agent could reach. See the AI and Privacy Guide.
- Third-party agents and processors: when a vendor's agent or integration causes the breach, the vendor is usually a processor who must tell you without undue delay, and your clock starts when you become aware. Contract for hours, not days.
Compliance steps
- Build a jurisdiction matrix: list every country where you hold personal data of residents, the applicable regime, regulator portal URL, deadline and threshold. Review it twice a year and after any law change.
- Define the decision times: in the incident runbook, record "aware", "determined breach occurred", "assessed as notifiable" and "determined material" as separate timestamps, each with an owner.
- Write one assessment method: score sensitivity, volume, identifiability, credentials involved and likelihood of misuse, then map the score to each local test (risk, high risk, real risk of significant harm, serious harm).
- Pre-draft notices: keep templates with the GDPR Article 33(3) fields plus local extras (Australia's recommended steps, India's contact for queries, Brazil's small agent declaration).
- Contract with processors: require notice of suspected incidents within 24 hours or less, with log access and named contacts.
- Test with an exercise: run a tabletop on a multi-country incident involving a leaked cloud key, measure how long it takes to reach each decision, and fix the slowest step.
- Keep the register: log every incident, including those not notified, with reasons. Brazil requires at least five years.
- Roll back safely: if a notice turns out to be wrong in scope, send a correction or follow-up through the same channel rather than withdrawing it; phased reporting is expressly allowed under GDPR Article 33(4).
Measuring it
- Time from detection to notifiability decision, per incident.
- Percentage of notifications filed within each regime's deadline (target 100 per cent).
- Percentage of incidents with a complete register entry, notified or not.
- Processor notification lag: hours from vendor awareness to your awareness.
- Jurisdiction matrix age: days since last review.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03, RS.CO-02, RS.CO-03, RS.MA-01 | Legal requirements understood; stakeholders and third parties notified |
| NIST SP 800-53 Rev. 5 | IR-6 Incident Reporting, IR-8 Incident Response Plan | Reporting to authorities within defined timeframes |
| ISO/IEC 27001:2022 Annex A | 5.24 to 5.28 (incident management), 5.31 (legal and regulatory requirements), 5.34 (privacy and protection of PII) | Incident process and legal obligations |
| CIS Controls v8.1 | Control 17, Incident Response Management | Contacts, reporting and exercises |
Common failure patterns
- Waiting for certainty: teams hold the notice until forensics finishes. GDPR, the ICO and Japan all allow phased reporting; report early and update.
- One threshold for every country: applying the GDPR "risk" test everywhere misses Singapore's 500 individual trigger and Japan's 1,000 individual and cyberattack triggers.
- Ignoring credentials as data: treating a leaked token as "just a secret" when local rules treat authentication data as a high-harm category.
- No record of non-notified incidents: the decision not to notify is itself auditable under GDPR Article 33(5) and Brazil's register rule.
- Forgetting the sector report: filing with the data protection authority but missing the NIS2 24 hour early warning or the DORA report to the financial supervisor.
- Generic inbox contacts: as the Medicare portal case shows, notices sent to an unmonitored address delay the recipient's own clock and response.
Practitioner checklist
- Maintain a jurisdiction matrix covering every country where you hold resident personal data, with deadlines, thresholds and portals.
- Record separate timestamps for awareness, breach determination, notifiability decision and materiality decision.
- Use one assessment method mapped to each local harm test, including numeric triggers.
- Treat compromised API keys, tokens and authentication data as high-harm data in the assessment.
- Keep notice templates with GDPR Article 33(3) fields and local additions ready to send.
- Check whether NIS2, DORA or SEC reporting applies in parallel for every notifiable incident.
- Require processors and integration vendors to notify suspected incidents within 24 hours.
- Log every incident and every decision not to notify, with reasons, for at least five years.
- Exercise a multi-country breach at least annually and track the KPIs above.
Standards and references
- GDPR: Article 33, Notification of a personal data breach to the supervisory authority
- ICO: Personal data breaches, report a breach
- Justice Laws Website: Personal Information Protection and Electronic Documents Act, sections 10.1 to 10.3
- OAIC: Part 4, Notifiable Data Breach (NDB) Scheme
- Personal Information Protection Commission Japan: Responding to leaks of personal data
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- SEC: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
- Latham and Watkins: China CAC Announces New Cybersecurity Incident Reporting Measures
Related NHI Mgmt Group resources: Data Breach Notification Checklist · Global Privacy Regulatory Map · GDPR Compliance Guide for Security Teams · Top 10 Privacy Compliance Mistakes · India DPDP Act Guide. This guide summarises breach notification requirements in selected jurisdictions as checked in October 2026 and is not legal advice.