Guide Incident Response Cybersecurity

Incident Notification Duties: Building and Using a Notification Matrix

Which regulators, individuals, customers and contracts you may need to notify after an incident, and how to keep track when several deadlines run at once.

10 November 2026
5 min read

This page is part of our guide to building an incident response plan and expands on step 3, the notification matrix. For a country-by-country table of deadlines, see breach notification deadlines by country.

Regulatory and contractual notification

Notification duties depend on where you operate, where the affected people live and which sector you are in. An incident that touches customers in several countries can start several clocks at once, each with its own regulator, threshold and deadline. Containing the incident does not remove any of them. The notification matrix from step 3 of the plan guide lists every regime that could apply. When an incident happens, work through these questions for each one:

  • Which laws, regulators and contracts apply, given where you operate, whose data is involved and which sector you are in?
  • What type of incident is it: a personal data breach, a disruption to a regulated service, or both?
  • Does it meet the regime's threshold? Most only require a report above a set level of risk or impact.
  • When did you become aware? Most deadlines run from that moment, so record it.
  • Who must be told (a regulator, affected individuals, customers, your insurer), who decides, who files and through which channel?
  • What is the deadline, and what follow-up reports are due after the first one?

The UK rules below show how this works in practice, followed by a summary for other major jurisdictions.

UK GDPR and the ICO

A controller must report a personal data breach to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. The ICO treats you as aware once you have a reasonable degree of certainty that a security incident has led to personal data being compromised, not when the full scope is known. If you report after 72 hours, you must give reasons for the delay.

Where a breach is likely to result in a high risk to individuals, you must also tell those individuals without undue delay. That is a separate, higher threshold. Record every personal data breach, including those you decide not to report, with your assessment and reasoning. ICO investigations examine whether the organisation had a reasonable process, not just whether the outcome was correct.

UK NIS Regulations

Operators of essential services in sectors such as energy, transport, health, water and digital infrastructure must notify their competent authority without undue delay, and no later than 72 hours after becoming aware, of an incident with a significant impact on the service they provide. Relevant digital service providers (online marketplaces, online search engines and cloud computing services) report substantial-impact incidents to the ICO on the same timeline. The Cyber Security and Resilience Bill, currently before Parliament, would extend the regime to managed service providers and data centres and introduce a 24-hour initial notification followed by a full report within 72 hours. NIS reporting operates alongside, not instead of, UK GDPR notification where personal data is involved.

UK financial services

FCA and PRA regulated firms already have to tell their regulator about material operational incidents. FCA PS26/2, with matching PRA and Bank of England rules, introduces a single operational incident and third-party reporting regime from 18 March 2027, with staged reports for incidents that meet defined thresholds. Build those thresholds and timelines into your notification matrix now.

Outside the UK

The main regimes elsewhere, in brief. Each has its own threshold for what counts as reportable, and several apply only to certain sectors or company sizes. Our article on breach notification deadlines by country covers each one in more detail, with links to the official sources.

RegimeWho reports to whomDeadline
EU GDPRController to the lead or local supervisory authority; individuals if the risk is high72 hours from awareness, where feasible
EU NIS2Essential and important entities to the national CSIRT or competent authorityEarly warning in 24 hours, notification in 72 hours, final report within one month
EU DORAFinancial entities to their financial supervisor, for major ICT-related incidents4 hours from classification as major (24 hours from awareness at most), then 72 hours, then one month
US statesOrganisations to affected residents, and often the state attorney generalVaries by state; Colorado, Florida and Washington set 30 days
US HIPAACovered entities to individuals, HHS and, above 500 residents of a state, the media60 days from discovery; breaches under 500 people logged and reported to HHS yearly
US SECListed companies to investors on Form 8-K, for material incidentsFour business days from deciding the incident is material, a decision that must be made without unreasonable delay
Brazil LGPDController to the ANPD and affected individualsThree working days (double for small processing agents)
AustraliaOrganisations to the OAIC and individuals; businesses with turnover of A$3 million or more to the ASD for ransomware paymentsData breaches as soon as practicable; ransomware payments within 72 hours
IndiaMost organisations to CERT-In, for listed cyber incidentsSix hours from becoming aware
CanadaPrivate-sector organisations to the Privacy Commissioner and individualsAs soon as feasible, where there is a real risk of significant harm

Work out in advance which EU supervisory authority leads for you, if any, and record it in the plan. In the US, also consider reporting attacks to CISA and the FBI's IC3, and check whether your sector has its own mandatory reporting rules.

A common mistake: waiting for certainty before notifying

Organisations frequently delay notifying the regulator while trying to establish the full scope of a breach. Under GDPR, the 72-hour window starts once you have a reasonable degree of certainty that a breach has occurred, not when you can confirm its full scope. Notify within the window with what you know, and submit supplementary information as the investigation progresses. Regulators, the ICO among them, treat late notification as an aggravating factor in enforcement decisions. Shorter clocks, such as Brazil's three working days, leave even less room to wait.

Ryland Deakin
About the author
Lead Consultant, Cyvra · CISM · CompTIA Security+ · MCP

Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years. View full profile

Common questions

What triggers the 72-hour GDPR notification requirement?

UK and EU GDPR require notification to the regulator (the ICO in the UK) without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach likely to result in a risk to the rights and freedoms of individuals. The clock starts when the organisation has a reasonable degree of certainty that a breach has occurred, not when the full scope is confirmed. Low-risk breaches, such as a single misdirected email containing non-sensitive information, may not require notification. High-risk breaches require direct notification to affected individuals without undue delay. Record every personal data breach, including those you decide not to report, with your assessment and reasoning. Regulators examine the process, not only the outcome.

Cybersecurity Assessment

Know your risks before an incident forces the conversation

Our assessment covers your incident response readiness alongside four other security domains. You leave with a prioritised roadmap.

Disclaimer: This article is for general informational purposes only and does not constitute legal, regulatory, or professional advice. Cyvra makes no warranty as to the accuracy or completeness of this content, which may not reflect the most current regulatory developments. Readers should seek independent legal and regulatory advice appropriate to their specific circumstances. Cyvra accepts no liability for any loss arising from reliance on this content.