One ransomware attack on a multinational can start a two-hour clock in Singapore, a six-hour clock in India, a 24-hour clock in the EU and a four-business-day clock at the SEC, each with a different trigger and recipient. Missing a deadline is now a compliance failure in its own right, separate from the incident. This map lists the main cyber incident reporting obligations in one table: deadline, what starts the clock, the threshold that makes an incident reportable, and who receives the report. It then explains how the triggers differ, how to run them from one playbook, and what changes when the compromised party is a service account or an AI agent. It is for incident response leads, CISOs, legal counsel and GRC teams. Status as of 25 October 2026; obligations still in rulemaking are marked as such.
Key takeaways
- Deadlines run from two hours to 60 days. Singapore CII owners report within two hours of becoming aware, CERT-In wants six hours, Hong Kong and Australia 12 hours for serious incidents, NIS2 and DORA 24 hours for a first notice, GDPR and many others 72 hours, and HIPAA up to 60 days.
- The trigger matters as much as the number. Clocks start on awareness, on noticing, on classification as major, on determination of materiality or on making a ransom payment, so your incident log must timestamp each of those decisions.
- Most regimes are multi-stage. NIS2 and DORA expect an initial notice, an intermediate update and a final report within about a month; the first notice is short and early, not complete.
- CIRCIA is still not in force. The statute fixes 72 hours for covered incidents and 24 hours for ransom payments, but reporting is voluntary until CISA's final rule takes effect; a September 2026 target was reported and publication was not confirmed as of 25 October 2026.
- Machine identity compromise is reportable compromise. Unauthorised access through a stolen API key, OAuth token or agent credential meets the same thresholds as a stolen password, and supply chain compromise through a provider is named explicitly in several regimes.
Regulations and frameworks at a glance
| Regime | Who reports | Threshold | Deadline and trigger | Recipient | Status (25 October 2026) |
|---|---|---|---|---|---|
| EU NIS2 Directive, Article 23 | Essential and important entities | Significant incident (severe operational disruption or financial loss, or considerable damage to others) | Early warning 24h, notification 72h from awareness; final report one month after notification | National CSIRT or competent authority | Applies via national law |
| EU DORA with Delegated Regulation (EU) 2025/301 | EU financial entities | Major ICT-related incident under the classification criteria | Initial 4h after classification as major and no later than 24h from awareness; intermediate 72h after initial; final one month after latest intermediate | Competent authority | Applies since 17 January 2025 |
| GDPR / UK GDPR Article 33 | Controllers (processors notify controllers without undue delay) | Personal data breach unless unlikely to result in a risk to individuals | Without undue delay and where feasible within 72h of awareness, reasons for any delay | Lead or competent supervisory authority (ICO in the UK) | In force |
| EU Cyber Resilience Act | Manufacturers of products with digital elements | Actively exploited vulnerability or severe incident affecting the product | Early warning 24h | CSIRT coordinator and ENISA via the single reporting platform | Reporting applies from 11 September 2026 |
| UK NIS Regulations 2018, regulation 11 | Operators of essential services | Significant impact on continuity of the essential service (users, duration, geography) | Without undue delay, no later than 72h after awareness | Designated competent authority | In force; Cyber Security and Resilience Bill (24h initial, 72h full report) not yet law |
| US SEC, Form 8-K Item 1.05 | SEC registrants | Cybersecurity incident determined to be material | Four business days after the materiality determination; delay only on Attorney General request | Public filing with the SEC | In force since 18 December 2023 |
| US CIRCIA, 6 U.S.C. 681b | Covered entities in critical infrastructure sectors (as the final rule defines) | Covered cyber incident; any ransom payment | 72h after reasonable belief; ransom payment 24h after paying | CISA | Final rule pending; voluntary until effective |
| New York 23 NYCRR 500.17 | DFS-licensed covered entities | Cybersecurity incident at the entity, an affiliate or a third-party service provider | 72h after determining an incident occurred; extortion payment 24h, written justification 30 days | NYDFS via its portal | In force |
| US HIPAA Breach Notification Rule | Covered entities and business associates | Breach of unsecured PHI | Individuals and HHS (500 or more) no later than 60 days after discovery | Individuals, HHS OCR, media above 500 residents of a state | In force |
| India CERT-In Directions, 28 April 2022 | Service providers, intermediaries, data centres, body corporates and government organisations | Incident types in Annexure I, including unauthorised access, ransomware, data breaches and DDoS | 6h after noticing or being told | CERT-In | In force since June 2022 |
| Australia SOCI Act, Part 2B | Responsible entities for critical infrastructure assets | Critical incident (significant impact) or other incident (relevant impact) | 12h for significant impact; 72h for relevant impact | Australian Cyber Security Centre | In force since 8 July 2022 |
| Singapore Cybersecurity Act | CII owners (including provider-owned CII since 31 October 2025) | Prescribed incidents, including suspected APT activity and supply chain incidents | 2h after becoming aware | Cyber Security Agency of Singapore | In force; amendments phased in |
| Hong Kong Protection of Critical Infrastructures (Computer Systems) Ordinance | Designated critical infrastructure operators | Serious incident disrupting or likely to disrupt core function; other incidents | 12h serious; 48h other, after awareness | Commissioner of Critical Infrastructure (Computer-system Security) | In force since 1 January 2026 |
Sector and national rules sit on top of these (central bank, telecoms, energy and payment regimes). National NIS2 laws may shorten or detail the EU timings; check the transposition in each Member State.
Scope: who and what is covered
Every regime answers three questions differently: which organisations, which incidents, and whose awareness counts.
- Entity scope: sector and size (NIS2, CIRCIA as proposed), licence (DORA, NYDFS), listing status (SEC), data role (GDPR, HIPAA) or designation by a regulator (Singapore CII, Hong Kong, SOCI). Groups often hold several roles; a bank's EU subsidiary under DORA can be part of a US registrant filing an 8-K.
- Incident scope: availability and service continuity (NIS2, UK NIS, SOCI), any personal data breach with risk (GDPR), materiality to investors (SEC), or an enumerated list (CERT-In Annexure I). CERT-In's list includes targeted scanning of critical systems, which most other regimes would not treat as reportable.
- Third-party incidents: NYDFS counts incidents at third-party service providers; the CIRCIA NPRM includes unauthorised access through a compromised cloud, managed service or supply chain provider; GDPR processors must alert controllers. See the CIRCIA Incident Reporting Guide.
- Ransom payments: CIRCIA (24 hours) and NYDFS (24 hours, then 30 days for the justification) treat the payment itself as a reportable event even when the attack is not. See the Ransomware Payments and Sanctions Guide.
Key obligations
What starts the clock
| Trigger | Regimes | What to log |
|---|---|---|
| Becoming aware | NIS2, GDPR, UK NIS, SOCI, Singapore, Hong Kong | Time a responsible person had reasonable certainty an incident occurred, not the first alert |
| Noticing or being told | CERT-In | Time the incident was first noticed or reported to you, which can be earlier than awareness elsewhere |
| Classification as major | DORA | Time of the classification decision, with the criteria met; still capped at 24h from awareness |
| Reasonable belief | CIRCIA | Time the entity reasonably believed a covered incident occurred |
| Determination | NYDFS (incident occurred), SEC (incident is material) | Who decided, when, and on what evidence; the SEC expects the determination without unreasonable delay |
| Discovery | HIPAA | First day the breach was known, or would have been known with reasonable diligence |
| Payment | CIRCIA, NYDFS | Time and amount of any ransom or extortion payment |
What the first report contains
- NIS2 early warning: whether the incident is suspected to be caused by unlawful or malicious acts, and whether it could have cross-border impact. The 72-hour notification adds an initial assessment, severity, impact and indicators of compromise.
- DORA initial notification: the standard template fields from the implementing technical standards; the intermediate report must follow within 72 hours even if nothing has changed, and missing a deadline must itself be explained to the authority before it passes.
- GDPR: nature of the breach, approximate numbers and categories of people and records, DPO contact, likely consequences and measures taken; information can be provided in phases. All breaches, reported or not, must be documented under Article 33(5).
- SEC Item 1.05: material aspects of the nature, scope and timing of the incident and its material impact or reasonably likely impact; technical details that would hinder response are not required.
- CERT-In: report through the formats on its website; separate directions require logs of all ICT systems to be kept for a rolling 180 days within India, which is what makes a six-hour report answerable.
For notifying individuals and US state regulators after a personal data breach, see the Data Breach Notification Checklist and the Breach Notification Laws by Country Guide. Incidents involving AI systems have their own emerging duties; see the AI Incident Reporting Guide.
Timeline and current status
| Date | Development |
|---|---|
| 15 March 2022 | CIRCIA signed into law |
| 28 April 2022 | CERT-In Directions issued; effective 60 days later |
| 8 July 2022 | Australia SOCI mandatory cyber incident reporting starts |
| 26 July 2023 | SEC adopts cybersecurity disclosure rules; 8-K reporting from 18 December 2023, smaller reporting companies 180 days later |
| 17 October 2024 | NIS2 transposition deadline |
| 17 January 2025 | DORA applies, with the incident reporting RTS in Delegated Regulation (EU) 2025/301 |
| 31 October 2025 | Singapore Cybersecurity Act amendments on provider-owned CII and systems of temporary cybersecurity concern in force |
| 1 January 2026 | Hong Kong critical infrastructure ordinance in force |
| 17 July 2026 | Unified Agenda preview reported a September 2026 target for the CIRCIA final rule |
| 7 September 2026 | UK Cyber Security and Resilience Bill amended in Lords Grand Committee (HL Bill 49); no Royal Assent as of 22 October 2026 |
| 11 September 2026 | EU Cyber Resilience Act reporting obligations apply |
Watch three items: publication and effective date of the CIRCIA final rule, Royal Assent and commencement regulations for the UK Bill, and the Commission's proposed targeted NIS2 amendments.
Enforcement and penalties
- NIS2: up to EUR 10 million or 2% of worldwide annual turnover for essential entities and EUR 7 million or 1.4% for important entities, with management liability.
- GDPR: failure to notify under Article 33 falls in the lower fine tier, up to EUR 10 million or 2% of worldwide turnover.
- DORA: penalties are set by Member States and applied by competent authorities.
- SEC: enforcement under the securities laws for late or misleading disclosure, including Item 1.05 filings and later amendments.
- CIRCIA: CISA may request information, then issue a subpoena, and refer non-compliance to the Attorney General for civil action.
- NYDFS: consent orders and penalties under the Financial Services Law.
- Hong Kong: fines up to HK$5 million, with daily fines for continuing offences.
- UK NIS: up to £17 million under the current regulations.
What it means for AI agents and non-human identities
Most reportable intrusions now involve a valid account (ATT&CK T1078), and an increasing share of those accounts are not human. Reporting obligations make no distinction, but investigations and evidence do.
| Scenario | Reporting impact | Preparation |
|---|---|---|
| Leaked cloud access key used to read customer data | Personal data breach (GDPR 72h); possibly NIS2 significant incident; CERT-In unauthorised access (6h) | Key inventory with owners; CloudTrail or equivalent logs retained long enough to scope access |
| Stolen OAuth token at a SaaS provider used against your tenant | Third-party incident under NYDFS; supply chain category in the CIRCIA NPRM; processor-to-controller alert under GDPR | Contract clauses requiring provider notice within hours; token revocation runbook |
| AI agent tricked into exporting records | Same thresholds as any data breach; may also trigger AI-specific reporting | Per-agent identity, action logs and data access logs to show what the agent touched |
| Ransomware deployed with a compromised service account (T1486) | Availability triggers under NIS2, DORA, SOCI, UK NIS; ransom payment clocks under CIRCIA and NYDFS | Privileged service account monitoring, offline backups, payment decision process |
The hard part is scoping: you cannot answer "how many records, which systems" inside 72 hours if machine credentials have no owner and their activity is not logged. See the Identity Incident Response Playbook and the AI Agent Incident Response Playbook.
Compliance steps
- Build the obligations register. For each legal entity, list applicable regimes, threshold, trigger, deadline, recipient, portal and template. Review it quarterly and on every new market or licence.
- Define decision points and owners. Name who declares awareness, who classifies a DORA major incident, who makes the SEC materiality determination and who approves a ransom decision. Record each decision with a timestamp.
- Pre-register and pre-draft. Create accounts on regulator portals (NYDFS, national CSIRTs, CERT-In), and keep templates with the fields each first report needs.
- Integrate the clocks into the incident response plan. Add a reporting track that starts at triage, not after containment. See the Incident Response Plan Template.
- Fix the evidence gaps. Log retention to match CERT-In's 180 days, identity and API logs for non-human accounts, and supplier notification clauses that beat your own deadlines.
- Exercise it. Run a tabletop that starts a ransomware scenario at 17:00 on a Friday across three jurisdictions, and check DORA's weekend rule, which does not apply to credit institutions or NIS2 entities.
- Review after every incident. Compare actual times with deadlines and update the register.
Metrics that show it is working
- Clock compliance: percentage of regulatory notices filed within deadline over 12 months (target 100%).
- Time to awareness decision: median time from first alert to documented awareness or classification.
- Register coverage: percentage of legal entities with a reviewed obligations entry.
- Supplier notice terms: percentage of critical suppliers contractually bound to notify within 24 hours or less.
- Machine credential attribution: percentage of service accounts and API keys with an owner and retained activity logs.
Common failure patterns
- Waiting for certainty: teams delay "awareness" until forensics finish; regulators read awareness as reasonable certainty, and early notices may be incomplete.
- One clock only: legal tracks GDPR while NIS2's 24-hour early warning passes unnoticed.
- Ignoring payment clocks: the ransom decision triggers its own 24-hour report under NYDFS and, once effective, CIRCIA.
- Supplier silence: a provider's incident becomes yours, as the claims and payment disruption across US healthcare after the Change Healthcare breach showed; without contractual notice terms you learn of it late.
- Undocumented materiality: no record of when and why the SEC determination was made.
Framework mapping
| Theme | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Legal and regulatory requirements understood | GV.OC-03 | PM-9 |
| Stakeholders notified of incidents | RS.CO-02 | IR-6 |
| Information shared with designated stakeholders | RS.CO-03 | IR-4 |
| Supplier requirements in contracts | GV.SC-05 | SR-3 |
Practitioner checklist
- Maintain an obligations register per legal entity with threshold, trigger, deadline and recipient.
- Name owners for awareness, DORA classification, SEC materiality and ransom decisions, and timestamp each decision.
- Pre-register on every regulator portal you may need and test logins twice a year.
- Keep first-report templates for NIS2, DORA, GDPR, CERT-In and NYDFS ready to fill.
- Retain logs for at least 180 days where CERT-In applies, including non-human identity activity.
- Require suppliers to notify you within 24 hours or less of incidents affecting your data or service.
- Check CIRCIA final rule status and UK Bill commencement before each plan review.
- Rehearse a cross-border scenario at least annually and record actual notice times.
Standards and references
- EUR-Lex: Commission Delegated Regulation (EU) 2025/301 (DORA incident reporting)
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- GDPR: Article 33 Notification of a personal data breach to the supervisory authority
- SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
- CISA: Cyber Incident Reporting for Critical Infrastructure Act of 2022
- 23 NYCRR 500.17: Notices to Superintendent
- CERT-In: Directions under section 70B(6) of the IT Act, 28 April 2022
- legislation.gov.uk: NIS Regulations 2018, regulation 11
This guide summarises cyber incident reporting requirements as of 25 October 2026 and is not legal advice. Related NHI Mgmt Group resources: CIRCIA Incident Reporting Guide · Global Cybersecurity Regulatory Map · Data Breach Notification Checklist · AI Incident Reporting Guide · Incident Response Guide