AI incident reporting obligations: a crosswalk of what to report, to whom and by when

An AI incident reporting obligation is a legal duty to tell a named authority, within a fixed clock, that an AI system caused, or the systems around it suffered, a defined harm. Most organizations answer to several such clocks at once, and the shortest one sets the pace.

This article is a crosswalk of those clocks. It covers the EU AI Act, NIS2 and DORA; the UK's data, cyber, AI and financial-services rules; the Singapore, Australia, Japan and Hong Kong rules where one exists; and the US sector rules. It maps each obligation to the report stage of the NIST, NSA and CISA key practices and to NIST CSF 2.0. It grades severity on a four-level scale and sizes the effort per practice for a mid-size GRC team. It ends with an action tracker you can download.

Method. Every obligation below carries its article number, its source and the date we read it, 29 Oct 2026. Where a rule is proposed or not yet in force, the row says so with the date. Where the original was not available on the publisher's site, the row cites the full-text copy we used instead. The clocks are the law's own words. The severity scale and the effort figures are ours and are labeled as such. Paragraphs marked "Our reading" are the desk's interpretation, not legal advice.

The shortest clocks at a glance. Each line gives the regime, the clock, the event that starts it and the recipient; the 26-row table below holds the rest.

• MAS Notice FSM-N05, Singapore banks: 1 hour from discovery, to MAS.
• DORA, EU financial entities: 4 hours from classification as major and no later than 24 hours from detection, to the competent authority.
• SOCI Act, Australian critical infrastructure: 12 hours from awareness for a critical incident, to ASD's ACSC.
• Hong Kong critical infrastructure: 12 hours from awareness for an incident that disrupts or is likely to disrupt the core function, to the Commissioner.
• NIS2, EU essential and important entities: early warning 24 hours from awareness, to the CSIRT or competent authority; the UK's proposed bill would match it.
• FCA rules from 18 Mar 2027: 24 hours from determining that a threshold is met, to the FCA.
• GDPR and UK GDPR: without undue delay and no later than 72 hours from awareness, to the supervisory authority or the ICO.
• UK NIS Regulations: without undue delay and no later than 72 hours from awareness, to the competent authority.
• SEC Form 8-K Item 1.05: four business days from the materiality determination, public.
• EU AI Act Article 73: 2, 10 or 15 days from awareness, to the market surveillance authority; the high-risk rules it attaches to apply from 2 Dec 2027 per the Commission.
• HIPAA: without unreasonable delay and no later than 60 calendar days from discovery, to individuals and HHS.

Download the action tracker (CSV) now if you want to work the rows as you read; it is explained at the end.

Which reporting rules apply to an AI incident?

Rarely one. An AI incident usually trips three kinds of rule at once. The first is AI-specific: the EU AI Act's serious incident duty. The second is cybersecurity or operational resilience: NIS2, DORA, the UK NIS Regulations, Australia's SOCI Act, Hong Kong's critical infrastructure ordinance, the FCA's incident rules. The third is privacy: GDPR and UK GDPR, HIPAA, the Singapore and Australian data breach schemes, the US state breach laws. A fourth kind, investor disclosure under the SEC's Form 8-K rule, applies to listed companies.

Our reading. The clocks do not start at the same moment. NIS2, SOCI, the UK NIS Regulations and the EU AI Act count from the moment the organization becomes aware. DORA counts from the moment the incident is classified as major, with a backstop from detection. The SEC counts from the determination that the incident is material. The FCA's new rules count from determining that a threshold is met. HIPAA counts from discovery. A GRC team therefore needs a clock on the decision itself, not only on the notice.

Example. Consider a mid-size insurer whose claims-triage agent starts approving claims outside its mandate. Security declares an incident when the monitor fires. Compliance then asks four questions in order. Is this a serious incident under the EU AI Act? A major ICT-related incident under DORA? A personal data breach under GDPR? An operational incident that meets an FCA threshold? Each yes starts a different clock from a different moment. Each notice goes to a different recipient. The crosswalk below is the table that answers those four questions in one pass.

What does the EU AI Act require, and from when?

Article 73 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to report serious incidents to the market surveillance authorities of the Member State where the incident occurred. Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to one of four harms. The first is the death of a person or serious harm to a person's health. The second is a serious and irreversible disruption of the management or operation of critical infrastructure. The third is the infringement of obligations under Union law intended to protect fundamental rights. The fourth is serious harm to property or the environment.

The clock has three settings. The report is due immediately after the provider establishes a causal link, or a reasonable likelihood of one. In any event it is due not later than 15 days after the provider, or the deployer where applicable, becomes aware of the incident. For a widespread infringement, or a serious incident under Article 3(49)(b), the limit is 2 days. For a death, it is 10 days. Where needed to report in time, the provider may file an incomplete initial report and complete it later. The provider must then investigate without altering the system in a way that could affect the later evaluation of causes. The authority must take appropriate measures within seven days of receiving the notification, under Article 73(8).

Deployers have their own line. Under Article 26(5), a deployer that has identified a serious incident must immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities. Where the deployer has reason to consider that the system presents a risk within the meaning of Article 79(1), it must inform the provider and the authority without undue delay and suspend use.

General-purpose AI models with systemic risk sit under Article 55(1)(c). Their providers keep track of, document and report relevant information about serious incidents and possible corrective measures, without undue delay. The report goes to the AI Office and, as appropriate, to national competent authorities. That obligation has applied since 2 Aug 2025. The General-Purpose AI Code of Practice, published 10 Jul 2025, turns "without undue delay" into numbers for its signatories. Measure 9.3 of the Safety and Security chapter sets four initial-report clocks, save in exceptional circumstances, each counted from awareness of the model's involvement. A serious and irreversible disruption of critical infrastructure: 2 days. A serious cybersecurity breach, including exfiltration of model weights: 5 days. A death: 10 days. Serious harm to health, a fundamental-rights infringement, or serious harm to property or the environment: 15 days. Intermediate reports follow at least every four weeks while the incident is unresolved. A final report is due within 60 days of resolution.

From when. The Commission's AI Act page, read 29 Oct 2026, says the Act became applicable on 2 Aug 2026 with exceptions. It also says the AI Omnibus entered into force on 27 Jul 2026; the page links its Official Journal text as OJ L 2026/1744. That regulation moved the high-risk obligations for Annex III systems to 2 Dec 2027 and for Annex I systems to 2 Aug 2028. Article 73 itself applies from 2 Aug 2026 under Article 113. The Commission's page, read 29 Oct 2026, says the high-risk rules apply from 2 Dec 2027 for Annex III systems and 2 Aug 2028 for Annex I systems. The reporting duty attaches to those systems, and the table states the dates that way, on the Commission's page. The Commission's guidance and reporting template for Article 73 were published as drafts on 26 Sep 2025 for consultation to 7 Nov 2025, and the page still describes them as drafts.

Our reading. A deployer's first obligation is to the provider, immediately, and only then to the authority. Keep the provider's incident contact on the AI system inventory record, because that is the first call.

What do NIS2 and DORA require?

Article 23 of Directive (EU) 2022/2555 (NIS2) requires essential and important entities to notify their CSIRT or competent authority of any significant incident, and, where appropriate, the recipients of their services. An incident is significant when it has caused or could cause severe operational disruption or financial loss for the entity, or has affected or could affect others by causing considerable material or non-material damage. The clock runs in stages. An early warning is due within 24 hours of becoming aware. An incident notification follows within 72 hours. An intermediate report is due when the authority asks for one. A final report is due not later than one month after the incident notification. If the incident is still being handled at that point, a progress report goes in and the final report follows within one month of handling. Member States had until 17 Oct 2024 to transpose the directive. The Commission's NIS2 page frames the scope as medium and large entities in 18 sectors. Our framework page on NIS2 holds the sector list.

Article 19 of Regulation (EU) 2022/2554 (DORA) requires financial entities to report major ICT-related incidents to the competent authority under Article 46. The report comes in three parts: an initial notification, an intermediate report and a final report, within time limits set by technical standards under Article 20. Clients whose financial interests are affected are informed without undue delay. The time limits are in Commission Delegated Regulation (EU) 2025/301. The EBA's page records it as adopted, published in the Official Journal and applying from 12 Mar 2025. It gives the limits as 4 hours after classification and 24 hours after detection for the initial notification, 72 hours for the intermediate report and one month for the final report. The Dutch regulator's AFM page anchors the clocks. The initial notification is due 4 hours after classification and no later than 24 hours after detection. The follow-up report is due 72 hours after the initial notification. The final report is due no later than one month after the follow-up report. Our framework page on DORA and the article on DORA in a connected GRC program cover the classification criteria.

A personal data breach in the EU also starts GDPR Article 33. The controller notifies the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware. The duty falls away only where the breach is unlikely to result in a risk to rights and freedoms. A processor notifies the controller without undue delay.

Our reading. NIS2 counts from awareness; DORA counts from classification with a backstop from detection. The classification decision under DORA therefore needs its own deadline inside the 24 hours, and the person who makes it needs to be named in the plan.

What do UK organizations report, and to whom?

Four regimes are in force and one is proposed. Under UK GDPR, the ICO's guide says a notifiable personal data breach is reported without undue delay and not later than 72 hours after becoming aware of it. A later report carries reasons for the delay. A breach likely to result in a high risk is also reported to the individuals without undue delay. A decision not to report is documented. Regulation 11 of the Network and Information Systems Regulations 2018 covers operators of essential services. They notify the competent authority of a NIS incident with a significant impact on the continuity of the service without undue delay and no later than 72 hours after becoming aware.

Reporting to the NCSC is voluntary. Its reporting guide says it prioritizes incidents on networks of national significance, welcomes "for information" reports on any incident, is not a regulator, and does not share a report with regulators without first seeking permission. The AI Security Institute describes itself as a research organization within the Department for Science, Innovation and Technology. It sets no reporting obligation. It was renamed from the AI Safety Institute on 14 Feb 2025.

The proposed rule is the Cyber Security and Resilience Bill. The government's policy statement, presented in April 2025, describes a two-stage structure. Regulated entities notify their regulator and inform the NCSC of a significant incident no later than 24 hours after becoming aware. An incident report follows within 72 hours. The duty extends to incidents capable of a significant impact on the service even where no interruption occurred. The Parliament bill page, read 29 Oct 2026, shows the Bill, titled the Cyber Security and Resilience (Network and Information Systems) Bill, introduced on 12 Nov 2025. The Commons passed it on 16 Jun 2026. It went through its House of Lords report stage on 26 Oct 2026 and is listed for Lords third reading on 2 Nov 2026. The Lords print as amended on Report keeps the two clocks. An initial notification is due within 24 hours of first awareness and a full notification within 72 hours, to the designated competent authority with a copy to the CSIRT. It is not yet an Act, so the clocks are proposed, not in force, and the duties would start when the Act's provisions are brought into force, not on Royal Assent.

Financial services firms get a new regime from 18 Mar 2027. The FCA's PS26/2, published 18 Mar 2026, applies to firms with a Part 4A permission, payment service providers, UK recognized investment exchanges, registered trade repositories and registered credit rating agencies. PRA and Bank of England firms follow the Bank's parallel publication. An operational incident is reported when it meets one of three thresholds. The first is a risk of intolerable consumer harm. The second is a risk to the safety and soundness of the firm or other participants. The third is a risk to market stability, integrity or confidence. The rules text asks for the initial phase of the report as soon as practicable, and at the very most within 24 hours of determining that a threshold is met. Enhanced reporters update after any significant change. They give a final update within 30 working days of resolution, or not more than 60 working days with reasons. Payment service providers keep their existing duty to report within 4 hours of first detecting a major operational or security incident. Until then, the FCA's current page points to Principle 11 and SUP 15.3: report a material incident to your supervisor.

What do the APAC rules require?

Singapore. Banks answer to the shortest clock in this crosswalk. MAS Notice FSM-N05 on technology risk management was issued 9 May 2024 and took effect 10 May 2024. It replaced MAS Notice 644, which MAS withdrew with effect from 10 May 2024. It requires a bank to notify MAS as soon as possible, but not later than 1 hour, upon the discovery of a relevant incident. A root cause and impact analysis report follows within 14 days of discovery. A relevant incident is a system malfunction or IT security incident with a severe and widespread impact on the bank's operations or a material impact on its service to customers. Part 6A of the Personal Data Protection Act adds the privacy clock, as the Ministry of Digital Development and Information states the rule. An organization assesses a data breach within 30 calendar days of having credible grounds to believe it occurred. Once it determines the breach is notifiable, it notifies the PDPC as soon as practicable and no later than 3 calendar days. Our framework pages cover the MAS TRM guidelines and the PDPA.

Australia. Part 2B of the Security of Critical Infrastructure Act 2018 sets two clocks, per the CISC's March 2026 guidance. The responsible entity for a critical infrastructure asset reports a critical cyber security incident, one with a significant impact on the availability of the asset, to ASD's ACSC within 12 hours of becoming aware. It reports any other cyber security incident with a relevant impact within 72 hours. An oral report is followed by a written record within 84 hours for a critical incident and 48 hours for another. The Notifiable Data Breaches scheme of the Privacy Act 1988 runs on the OAIC's guidance. An entity takes all reasonable steps to complete the assessment of a suspected eligible data breach within 30 calendar days. It gives its statement to the Commissioner as soon as practicable, and notifies individuals as soon as practicable after completing it.

Japan. Article 26 of the Act on the Protection of Personal Information covers a leakage, loss or damage of personal data likely to harm individual rights and interests, in the cases the Commission's rules prescribe. The personal information handling business operator reports it to the Personal Information Protection Commission and notifies the affected person. The time limits sit in the Commission's rules. The English rules file on the Commission's site is the 2016 version, so no deadline is stated here. Our APPI framework page covers the Act.

Hong Kong. The Protection of Critical Infrastructures (Computer Systems) Ordinance came into effect on 1 Jan 2026, per the commencement announcement of 27 Jun 2025. The Commissioner of Critical Infrastructure (Computer-system Security) took up the post the same day. Schedule 6 of the Ordinance sets four limits. An incident that has disrupted, is disrupting or is likely to disrupt the core function of the critical infrastructure is notified within 12 hours of awareness. Any other case is notified within 48 hours. If the first notification was not made in the form and way the Commissioner specifies, a written record in that form follows within 48 hours of it. A written report is due within 14 days of awareness. The limits are in Schedule 6 of the Ordinance as enacted, Ord. No. 4 of 2025. The privacy side, the PDPO, is not covered here because the Privacy Commissioner's guidance was not available to us.

What do the US sector rules require?

No US rule is AI-specific; four sector rules and one proposed rule carry the clocks. The SEC's cybersecurity disclosure rules of 26 Jul 2023 require a registrant to disclose a material cybersecurity incident on Form 8-K Item 1.05. The filing is generally due four business days after the registrant determines the incident is material. A delay is allowed only where the Attorney General finds in writing that immediate disclosure would pose a substantial risk to national security or public safety. Form 8-K compliance began on the later of 90 days after Federal Register publication or 18 Dec 2023, with 180 more days for smaller reporting companies. Our article on SEC cyber disclosure and the framework page cover the materiality process.

The HIPAA Breach Notification Rule runs on 60 days. Under 45 CFR 164.404, a covered entity notifies individuals without unreasonable delay and in no case later than 60 calendar days after discovery. A breach is treated as discovered on the first day it is known, or would have been known with reasonable diligence. Under 164.408, breaches of 500 or more individuals go to the Secretary contemporaneously with the individual notice. Smaller breaches go in a log submitted not later than 60 days after the end of the calendar year. Under 164.410, a business associate notifies the covered entity without unreasonable delay and in no case later than 60 calendar days after discovery. See the HIPAA Omnibus Rule framework page.

State breach laws set their own limits. The NCSL's summary counts a law in all 50 states, the District of Columbia, Guam, Puerto Rico and the Virgin Islands. Florida Statutes 501.171 require notice to individuals as expeditiously as practicable and no later than 30 days after the determination of a breach. A breach affecting 500 or more individuals is also reported to the Department of Legal Affairs within the same 30 days. RCW 19.255.010 in Washington requires notice in the most expedient time possible, without unreasonable delay, and no more than thirty calendar days after the breach was discovered. Other states use different day counts, so the tracker carries a row per state you operate in.

CIRCIA is still a proposal. CISA's page, read 29 Oct 2026, says the notice of proposed rulemaking was published on 4 Apr 2024. CISA continues to work on the final rule after funding lapses. Until the final rule's effective date, organizations are not required to submit reports. The proposed deadlines are 72 hours from the time the entity reasonably believes a covered cyber incident occurred and 24 hours after a ransom payment.

Federal AI guidance adds no clock. The NIST AI RMF 1.0 was released 26 Jan 2023 for voluntary use. MANAGE 4.3 says incidents and errors are communicated to relevant AI actors, including affected communities. It adds that processes for tracking, responding to and recovering from them are followed and documented. NIST's framework page says the AI RMF is being revised. The NIST, NSA and CISA key practices of October 2026 are voluntary; our article on the ten practices explains them, and the next section maps their report stage onto the obligations.

The crosswalk: what to report, to whom and by when

Twenty-six rows, last verified 29 Oct 2026. Status is one operative line: in force today, in force on a date, proposed, or voluntary. Each source was read on 29 Oct 2026; a row marked "mirror" cites a full-text copy of the Official Journal text because the original was not available on EUR-Lex.

#	Jurisdiction	Instrument	Who reports	Trigger	Clock	To whom	Status	Source
1	EU	EU AI Act Art. 73(1) to (5)	Providers of high-risk AI systems	Serious incident per Art. 3(49)	Immediately once a causal link is established or likely; not later than 15 days after awareness; 2 days for widespread infringement or critical-infrastructure disruption; 10 days for a death; incomplete initial report allowed	Market surveillance authority of the Member State	In force on a date: Art. 73 applies from 2 Aug 2026; the high-risk rules it attaches to apply from 2 Dec 2027 (Annex III) and 2 Aug 2028 (Annex I) per the Commission's page read 29 Oct 2026; guidance and template still drafts	Art. 73 (mirror); Commission dates
2	EU	EU AI Act Art. 26(5)	Deployers of high-risk AI systems	An identified serious incident	Immediately: provider first, then importer or distributor and the market surveillance authorities	Provider, then authorities	In force on a date: as row 1 (2 Dec 2027 Annex III, 2 Aug 2028 Annex I, per the Commission's page)	Art. 26 (mirror)
3	EU	EU AI Act Art. 55(1)(c)	Providers of GPAI models with systemic risk	Serious incidents and corrective measures	Without undue delay	AI Office; national competent authorities as appropriate	In force today, since 2 Aug 2025	Art. 55 (mirror)
4	EU	GPAI Code of Practice, Safety and Security chapter, Measure 9.3	Signatories with systemic-risk models	The model's involvement in a serious incident	Initial report 2 days (critical infrastructure), 5 days (serious cybersecurity breach), 10 days (death), 15 days (other serious harm); intermediate at least every four weeks; final within 60 days of resolution	AI Office; national authorities as applicable	Voluntary code, published 10 Jul 2025	Chapter text
5	EU	NIS2 Art. 23	Essential and important entities	Significant incident (Art. 23(3))	Early warning 24 hours; notification 72 hours; intermediate on request; final one month after the notification	CSIRT or competent authority; service recipients where appropriate	In force today through national law; transposition deadline 17 Oct 2024; national laws differ	Art. 23 (mirror); Commission page
6	EU	DORA Art. 19 with Delegated Regulation (EU) 2025/301	Financial entities	Major ICT-related incident	Initial 4 hours after classification and no later than 24 hours after detection; intermediate 72 hours after the initial; final one month after the intermediate; clients without undue delay	Competent authority (Art. 46)	In force today; the time limits apply since 12 Mar 2025	Art. 19 (mirror); EBA; AFM
7	EU	GDPR Art. 33	Controllers; processors to controllers	Personal data breach unless unlikely to result in a risk	Without undue delay and where feasible within 72 hours of awareness	Supervisory authority	In force today	Art. 33 (mirror)
8	UK	UK GDPR Art. 33 and 34	Controllers	Notifiable personal data breach; high risk also to individuals	Not later than 72 hours after awareness; individuals without undue delay	ICO; individuals	In force today	ICO guide
9	UK	NIS Regulations 2018, reg. 11	Operators of essential services	NIS incident with significant impact on continuity	No later than 72 hours after awareness	Competent authority	In force today	Reg. 11
10	UK	Cyber Security and Resilience Bill	Regulated entities under the NIS regime	Significant incident, including one capable of significant impact	Notify regulator and inform NCSC within 24 hours; incident report within 72 hours	Designated competent authority, copy to the CSIRT (the NCSC)	Proposed: introduced 12 Nov 2025; passed the Commons 16 Jun 2026; Lords report stage 26 Oct 2026; Lords third reading listed for 2 Nov 2026; not an Act as of 29 Oct 2026	Policy statement; Parliament bill page
11	UK	NCSC incident reporting	Any organization	Significant cyber incident; any incident for information	None	NCSC	Voluntary; the NCSC is not a regulator	NCSC guide
12	UK	AI Security Institute	Not applicable	Not applicable	No reporting duty	Not applicable	Research organization; renamed 14 Feb 2025	About AISI
13	UK	FCA PS26/2, SUP 15.18	FCA-regulated firms in scope	Operational incident meeting a threshold	Initial as soon as practicable, which the FCA expects to be at most 24 hours from determining a threshold is met (SUP 15.18.7G); enhanced reporting firms update after a significant change and give a final update within 30 working days of resolution; payment service providers keep their 4 hour clock from detection	FCA; PRA for dual-regulated firms	In force on a date: 18 Mar 2027	PS26/2
14	Singapore	MAS Notice FSM-N05, paras 7 and 8	Banks	Relevant incident	Not later than 1 hour after discovery; root cause report within 14 days	MAS	In force today, since 10 May 2024 (it replaced Notice 644, withdrawn the same day)	Notice
15	Singapore	PDPA Part 6A	Organizations	Notifiable data breach	Assess within 30 calendar days; notify PDPC no later than 3 calendar days after determining it is notifiable	PDPC; affected individuals	In force today	MDDI statement
16	Australia	SOCI Act Part 2B (ss. 30BC, 30BD)	Responsible entities for critical infrastructure assets	Critical or other cyber security incident	Critical within 12 hours; other within 72 hours; written record 84 or 48 hours after an oral report	ASD's ACSC	In force today	CISC guidance
17	Australia	Privacy Act 1988, NDB scheme	Entities covered by the Act	Eligible data breach	Assessment within 30 calendar days; statement to the Commissioner as soon as practicable; individuals as soon as practicable after	OAIC; individuals	In force today	OAIC guidance
18	Japan	APPI Art. 26	Personal information handling business operators	Leakage, loss or damage likely to harm rights and interests	Report and notify; limits in the Commission's rules, not stated here	Personal Information Protection Commission; the principal	In force today	Act text
19	Hong Kong	Protection of Critical Infrastructures (Computer Systems) Ordinance, s. 28	Critical infrastructure operators	Computer-system security incident	Incident that disrupts or is likely to disrupt the core function within 12 hours; any other within 48 hours; written record within 48 hours if the first notice was not in the specified form; written report within 14 days	Commissioner of Critical Infrastructure (Computer-system Security)	In force today, since 1 Jan 2026	Ordinance (Ord. No. 4 of 2025), Schedule 6; Commencement
20	US	SEC Form 8-K Item 1.05	SEC registrants	Material cybersecurity incident	Four business days after the materiality determination	SEC (public filing)	In force today, since Dec 2023	SEC release
21	US	HIPAA 45 CFR 164.404 to 164.410	Covered entities; business associates	Breach of unsecured protected health information	Individuals without unreasonable delay and no later than 60 calendar days after discovery; HHS contemporaneously for 500 or more, annual log otherwise; business associates within 60 days	Individuals; HHS; media for 500 or more in a state	In force today	164.404; 164.408
22	US	State breach laws	Businesses holding residents' personal information	Breach of personal information as defined	Varies: Florida 30 days after determination; Washington no more than 30 calendar days after discovery	Individuals; state authorities	In force today; all 50 states plus DC and territories	Florida; Washington
23	US	CIRCIA proposed rule	Covered entities in critical infrastructure	Covered cyber incident; ransom payment	72 hours from reasonable belief; 24 hours after a ransom payment	CISA	Proposed: NPRM 4 Apr 2024; no final rule as of 29 Oct 2026	CISA
24	US	NIST AI RMF 1.0, MANAGE 4.3	Voluntary	Incidents and errors	None; communicate to relevant AI actors and affected communities	Not applicable	Voluntary; under revision	AI RMF
25	US	NIST, NSA and CISA key practices 8 to 10	Voluntary; developers first, deployers possibly	SI control incidents and near-misses	Legal reporting first (9.1); voluntary sharing with CISA, NIST CAISSI and NSA SISC after (9.3)	CISA; law enforcement; NIST CAISSI; NSA SISC; affected parties; the public	Voluntary, October 2026	Key practices
26	US	NIST CSF 2.0 (CSWP 29)	Voluntary	Not applicable	Not applicable	Not applicable	Voluntary; outcomes quoted below	CSF 2.0

Five items are not in the table because no primary source was available to us on 29 Oct 2026. They are Hong Kong's PDPO breach timing, Japan's rule-level deadlines, the PRA's own policy statement, the Australian ransomware-payment reporting window, and the California and Texas breach statutes.

How do the obligations map to the NIST, NSA and CISA report stage and to CSF 2.0?

The key practices put the report stage last in the list and first in the sequence: the document says reporting practices take place throughout the incident lifecycle, not after recovery. Each sub-practice cites the CSF 2.0 outcome it supports, so the crosswalk can hang on those outcomes. The outcome texts below are quoted from NIST CSWP 29.

Practice	CSF 2.0 outcome	Outcome text (CSWP 29)	Obligations that discharge it (crosswalk rows)
Before any incident: know the rules	GV.OC-03	Legal, regulatory, and contractual requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed	The whole table; rows 10 and 23 tracked as proposed rules with a review date
Declare and grade	DE.AE-08; RS.MA-03	Incidents are declared when adverse events meet the defined incident criteria; incidents are categorized and prioritized	Awareness-based clocks start here: rows 1, 5, 8, 9, 16; classification-based clocks (row 6) and determination-based clocks (rows 13, 20) start at the grading decision
8. Coordinate with Affected Parties (8.1, 8.2)	RS.CO-02; RS.CO-03	Internal and external stakeholders are notified of incidents; information is shared with designated internal and external stakeholders	Row 2 (provider first), row 6 (clients), rows 7, 8, 15, 17, 21 and 22 (individuals)
9. Notify Government (9.1)	GV.OC-03; RS.CO-02	As above	Rows 1, 3, 5, 6, 8, 9, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22; rows 10 and 23 once in force
9. Notify Government (9.3)	RS.CO-03; RS.MA-03	Information is shared with designated stakeholders; incidents are categorized and prioritized	Voluntary sharing with NIST CAISSI and NSA SISC after mandated reporting (row 25); NCSC for-information reports (row 11); the GPAI code's reports (row 4)
10. Share Information Publicly (10.1 to 10.3)	RC.CO-04; ID.IM-01; ID.IM-03	Public updates on incident recovery are shared using approved methods and messaging; improvements are identified from evaluations and from execution of operational processes	Row 20 (a Form 8-K is public); lessons learned under rows 24 and 25
Keep the record	ID.IM-04; RS.AN-03; RS.AN-08	Incident response plans are established, communicated, maintained, and improved; analysis establishes what has taken place and the root cause; an incident's magnitude is estimated and validated	Every final report in the table asks for a description, a cause and an impact: rows 5, 6, 13, 14 and 19 name one explicitly

Our reading. Practice 9.1 is the hinge. It says to adhere to applicable legal reporting requirements first, including cybersecurity incident reporting obligations to CISA, law enforcement and cyber-defense organizations, and only then to report voluntarily. The crosswalk is the artifact that makes 9.1 checkable: one row per obligation, each with a clock and a recipient. Our SP 800-61 Rev. 3 framework page covers the incident response plan the practices build on.

How should a GRC team grade severity?

The key practices leave severity criteria to the organization, and the laws above define triggers rather than levels. The scale below is our method, written for a deployer of third-party AI agents in a regulated industry. It has four levels; each names the trigger, the clock that starts and who decides. Adopt it as a starting point and replace the triggers with your own thresholds.

Level	Trigger	Clock that starts	Who decides
1. Low	An agent acted outside its mandate with no harm, no outage, no personal data and no third party involved; contained by the operator	No external clock. Internal: record within one working day; near-miss logged for practice 9.3	The incident owner on the security or operations team
2. Moderate	Service degradation, a policy violation or data exposure inside the organization; no statutory trigger plausibly met	No external clock yet. Internal: a documented decision within 24 hours that no threshold is met, because that decision is what an authority will ask to see	The incident manager with the GRC lead
3. High	A statutory trigger is plausibly met: a significant incident (NIS2), a major ICT-related incident (DORA), a notifiable or eligible data breach, an FCA threshold, or an AI Act serious incident without death or critical-infrastructure disruption	The shortest applicable clock from awareness or detection: 1 hour (MAS banks), 4 hours from classification (DORA), 12 hours (SOCI critical, Hong Kong core-function disruption), 24 hours (NIS2 early warning), 72 hours (GDPR, UK GDPR, NIS Regulations), 15 days (AI Act)	The GRC lead and legal counsel together; the CISO or CRO informed
4. Critical	Death or serious harm to health, serious and irreversible disruption of critical infrastructure, a material incident for investors, or 500 or more individuals' health data	The AI Act's 2-day clock for critical-infrastructure disruption or a widespread infringement and its 10-day clock for a death, the SEC's four business days from the materiality determination, HIPAA's outer limit of 60 days from discovery, plus every level-3 clock	An executive (CISO, CRO or CCO) with the general counsel; the board or its committee informed; the materiality or classification decision recorded with its time

Our reading. Set the level at declaration, re-grade when the facts change, and record who decided and when. The decision time is the start of several clocks: DORA's classification, the SEC's determination and the FCA's threshold decision all count from the moment someone decides. A regulator reading your file later will look for that timestamp first.

How much effort does each practice take for a mid-size GRC team?

The figures below are the desk's estimates, not survey results. They assume a GRC team of three to five people in an organization of 1,000 to 10,000 employees that deploys third-party AI agents rather than training models. They count the GRC team's own hours to produce the records each practice asks for; engineering work on identity, gateways, logging and kill paths is a dependency, not included. The basis column says where each figure comes from: the number of sub-practices in the key practices document and the artifacts each one names.

#	Practice	GRC hours (estimate)	Engineering dependency	Basis for the estimate
1	Design and Implement Technical Controls	16	Yes: access, egress, kill path	Seven sub-practices; GRC records each control, its owner and its test, and maps it to the CSF 2.0 outcome the practice cites
2	Build Organizational and Personnel Response Readiness	24	No	The plan annex, the roles for each severity level, one tabletop exercise and its record
3	Monitor for Unexpected Activity	8	Yes: monitoring stack	GRC writes the declaration criteria that start the clocks and reviews the alert rules against them
4	Validate and Secure Monitors to Improve Operational Integrity	8	Yes	GRC records the validation and tamper checks as control tests
5	Collect, Retain, and Analyze Evidence	16	Yes: log integrity	A retention schedule agreed with counsel, log integrity checks as controls, and the magnitude estimate every final report asks for
6	Mitigate and Shut Down Undesired Activity	8	Yes: kill path	GRC records the containment decision, its time and its decider; the Article 26(5) notice to the provider belongs here
7	Verify and Strengthen Containment Before Resuming SI Agent Activity	8	Yes	Resumption criteria and the verification record that feed the final reports
8	Coordinate with Affected Parties	12	No	An affected-party list, notice templates for clients and individuals, and the timestamps the privacy rows require
9	Notify Government	24	No	This crosswalk localized to your jurisdictions, regulator contacts and portals, notice templates per row, and a review date for the proposed rules
10	Share Information Publicly	8	No	A public statement template, the lessons-learned record and the third-party review access the practice asks for

That is 132 hours of GRC work for a first pass, with 64 of them in practices 2, 5 and 9. Revisit the figures after the first tabletop exercise, because that is where the plan's gaps show.

What goes in the action tracker?

The tracker is one row per practice, ten rows. The columns are practice number and name, stage, the CSF 2.0 outcomes the practice cites, owner, evidence, due date, the reporting obligations that apply by crosswalk row number, status and notes. The obligations column is pre-filled from the mapping table above. The first job is to delete the rows that do not apply to your jurisdictions and add a row per US state you operate in. The owner and due-date columns are empty by design. In the evidence column, record what proves a notice was timely: the awareness, classification or determination timestamp, the sign-off, and the submission receipt.

Download the tracker as a CSV: AI incident reporting action tracker (CSV). A template in the Solution Library may follow; the CSV is the download today.

If you want these clocks to run as dated tasks with owners and reminders on the same record as the incident, its severity and its root cause analysis, SmartSuite's incident management product does that.

Where to start

1. Localize the crosswalk. Keep the rows for the jurisdictions and sectors you operate in, add a row per US state, and set a review date on rows 10 and 23, the proposed rules.
2. Name the decider for each severity level and give the decision itself a clock, because DORA, the SEC and the FCA count from that moment.
3. Put the provider's incident contact on every AI system inventory record; under Article 26(5) that is the first call.
4. Agree evidence retention with counsel before the first incident, since every final report in the table asks for a description, a cause and an impact.
5. Run one tabletop exercise against the level-3 row and re-size the effort table from what it shows.

Related reading: AI incident management, EU AI Act readiness, the glossary entry on breach notification, and the GRC Foundation library.

Reviewed by Jon Darbyshire, Chief Executive Officer; co-founder of Archer Technologies and earlier a national partner at Ernst & Young, where he led its Global Enterprise Security Services practice.