CyphrQ
Menu

Data Breach Notification Deadlines by Country: Comparison Table

Who must be told about a data breach, and by when: GDPR, UK, Australia, Brazil, Canada, the SEC and NIS2 side by side, each linked to its source.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

9 min read

What are the data breach notification deadlines by country? There is no single number. The EU and UK say 72 hours from becoming aware, Brazil says 3 working days, NIS2 starts at 24 hours, Australia caps the assessment at 30 days, and Canada says "as soon as feasible". The table below sets out each one with its source. This is not legal advice.

Checked on 25 October 2026. Laws and regulator guidance change, so check the linked source before you rely on a row.

How do data breach notification deadlines by country compare?

Each row below comes from a page I opened: the regulator's own guidance, the European Commission, or the SEC. Where a page gave no figure, I say so instead of filling the gap.

Jurisdiction Law Notify the regulator Notify individuals Source
EU/EEA GDPR, Articles 33 and 34 (our GDPR guide) Within 72 hours of becoming aware, unless the breach poses no risk to individuals Without undue delay, if the breach is likely to result in a high risk EDPB
UK UK GDPR Without undue delay and no later than 72 hours after becoming aware Directly and without undue delay, if high risk ICO
Australia Privacy Act 1988, Notifiable Data Breaches scheme Assessment within 30 calendar days (s 26WH(2)), then a statement to the OAIC as soon as practicable (s 26WK(2)) As soon as practicable after the statement (s 26WL(3)) OAIC
Brazil LGPD, Article 48, and ANPD Resolution CD/ANPD 15/2024 3 working days 3 working days, per the same ANPD page ANPD
Canada PIPEDA, breach of security safeguards rules Report breaches that pose a real risk of significant harm; the page I read gives no fixed time As soon as feasible after determining the breach meets that test OPC
United States (federal, listed companies) SEC Form 8-K, Item 1.05 Public filing due 4 business days after the company determines the incident is material No federal rule in this row; states differ SEC
EU, in-scope entities NIS2 Directive, for significant incidents (our NIS2 guide) Early warning in 24 hours, incident notification in 72 hours, final report one month after that, to the CSIRT or competent authority The FAQ page I read does not cover this European Commission

Two cautions on reading it. The columns are not like for like: the SEC row is a public disclosure to investors, not a report to a privacy regulator, and the NIS2 row is a cybersecurity incident duty, not a privacy one. And "Notify the regulator" means different clocks: some start at awareness, some at a decision.

Where does each clock start?

The start point matters as much as the number.

  • GDPR and UK GDPR: awareness. The EDPB says you are aware once there is "a reasonable degree of certainty that a security incident has occurred and compromised personal data". Suspicion alone is not the trigger, but you cannot wait for a finished investigation either.
  • Australia: the 30 days run from when you suspect an eligible data breach, and cover the assessment, not the report. The OAIC says to treat 30 days as a maximum and aim for much shorter.
  • SEC: the four business days run from the materiality determination, not from discovery. The SEC page I read sets no separate deadline for making that determination.
  • NIS2: 24 hours from first becoming aware of a significant incident.
  • Brazil: the ANPD page I read does not say when the 3 working days begin, so confirm that against the resolution before you build a runbook around it.

What counts as a reportable breach?

Most regimes do not ask for a report of every incident. They use a threshold:

  • EU and UK: report unless the breach is unlikely to risk people's rights and freedoms; tell individuals only when the risk is high.
  • Australia: the breach must be likely to result in serious harm to an individual whose information is involved (OAIC). "Likely" means more than possible.
  • Canada: a real risk of significant harm, judged from how sensitive the information is and how likely it is to be misused.
  • SEC: materiality to the company, which is an investor test, not a privacy one.

The practical effect: a breach can be reportable in one place and not in another. A lost laptop with encrypted data may need no individual notice in the EU, where the EDPB says notice may be unnecessary if the data was encrypted and the keys were not compromised. It needs its own assessment in each other regime.

What happens when organisations miss the clock?

Two documented cases in our own library show that the notification process is where regulators look.

In practice: British Airways, 2018. BA notified the ICO, banks, payment schemes and customers on 6 September 2018, after a skimmer had been live for 15 days. The ICO treated quick notification as a mitigating factor in the penalty. The details, with paragraph references to the ICO's penalty notice, are in our British Airways breach explainer.

In practice: INSS, Brazil, 2023. The ANPD's first enforcement wave was mostly about failing to notify, not about the breach itself. In the INSS case, weak access logs could not show whose records were read, which widened the group that had to be told. Read the INSS case write-up.

Both cases come from posts that cite their primary decisions. I did not re-open those decisions for this table.

Going deeper: for security and IT teams

If you operate in several places, the useful question is not "which deadline applies" but "which of my clocks starts first". Build one incident record and derive every regulator's deadline from it.

One record, several clocks. Store these timestamps as separate fields, because the regimes start from different events:

  1. detected_at: first alert or report. No regulator in the table starts here by name, but it is your evidence of when you could have known.
  2. aware_at: the point of reasonable certainty that personal data was compromised. This drives the 72-hour EU and UK clocks and, in practice, the NIS2 24 hours.
  3. suspected_at: the grounds-to-suspect date that starts Australia's 30-day assessment.
  4. material_at: the board or disclosure committee's materiality determination, which starts the SEC's four business days.
  5. determined_notifiable_at for Canada and Brazil, where the standard is a decision followed by prompt action.

Then compute due times per regime from those fields. Use business-day logic for the SEC, which counts business days, and Brazil, which counts working days; use elapsed hours for the EU, UK and NIS2.

Run to the strictest clock. For an entity in NIS2 scope, the 24-hour early warning is the first deadline. The Commission describes it as a quick alert, and the same FAQ says it can be used to ask for operational advice. File thin and early, then update. The ICO and EDPB both allow phased reporting, as long as you do not add undue delay. If the 72-hour window passes without full facts, you still send an initial notice and explain the gap.

Make "aware" a recorded decision. The EDPB recommends recording how and when you became aware and how you assessed the risk. Write the decision as a log entry with a named person. If you cannot show when awareness happened, a regulator can pick the earliest plausible moment.

Evidence to keep, whether or not you report. - The assessment and the reasons for not notifying. Canada requires records of all breaches of security safeguards for two years (OPC), and the OAIC says to document the steps taken and the reasons for any assessment taking longer than 30 days. - Draft and sent versions of each notification, with the recipient and send time. - Processor and supplier notices, with received times, since your clock may already be running when they tell you. - Logs that show which records were exposed. The INSS case above is the cost of not having them.

Controls that support the clock. ISO/IEC 27035 gives a structure for incident management, and NIST CSF 2.0 has a Respond function you can map the steps to. Neither sets a legal deadline, so map each deadline to a step yourself.

Test it. Run a tabletop that starts at a detection alert and ends with filed notices for two regimes. Check four things: can you name the decision-maker out of hours, can you reach the filing channel, is the contact list current, and do your calendars handle the working-day regimes?

What to ask suppliers. How quickly will you tell us about an incident that touches our data, in writing, and what will you send? A contract that says "promptly" gives you no clock.

What should you do this week?

  1. List the places where you hold people's data and the regimes that apply to each.
  2. Copy the rows that apply from the table, and confirm each at its source.
  3. Name who declares "aware", who decides "notifiable", and who files.
  4. Add the timestamp fields above to your incident ticket template.
  5. Ask your top five suppliers for their breach notice period in writing.

Not covered yet

I could not read an official source for these during this research, so they are not in the table. Our own explainers on them exist, but their deadlines were not re-checked for this post.

  • Singapore PDPA: see our Singapore PDPA breach notification guide.
  • Saudi Arabia PDPL: see our Saudi PDPL guide.
  • UAE federal PDPL: our UAE PDPL guide says the breach period sits in Executive Regulations that no primary government source shows as issued.
  • India DPDP: tell each affected person and the Data Protection Board without delay, then send the Board a detailed report within 72 hours of becoming aware, or longer if the Board allows on written request (DPDP Rules 2025, rule 7). The rule applies 18 months after the Rules were published (rule 1(4)), and failing to notify can cost up to ₹200 crore (Act, Schedule item 2). More in our DPDP explainer.
  • US states: each state sets its own rules. I have not read them for this post.

Learn more

Key takeaways

  • The EU and UK give 72 hours from awareness, NIS2 starts at 24 hours, Brazil gives 3 working days, and the SEC gives 4 business days after a materiality decision.
  • Australia limits the assessment to 30 days; Canada has no fixed hours on the page I read, only "as soon as feasible" for individuals.
  • Clocks start at different events: awareness, suspicion, or a decision.
  • Keep one incident record with a timestamp for each event, and run to the shortest clock that applies.
  • Keep the assessment and the reasoning even when you decide not to report.

Sources