AI Governance Engineer
GitHub

AI incident reporting clocks: which run, and when they stop.

One AI incident can start several reporting clocks at once. Enter when you became aware, the roles you hold, the tier of the system and what happened: the tool classifies the event on chapter 17's scale and lays out each clock as a calendar date, with reminders and a record skeleton.

By Updated

Indicative, not legal advice and not a conformity claim. Nothing you enter leaves your browser.

JavaScript is off or has not loaded, so the live result and the exports are not available. The questions, the criteria and the guide below still work as a worksheet you can read and fill in by hand.

Built from 17. Incidents, issues and root causes of the Body of Knowledge. Runs entirely in this page: no account and no upload.

One task from the everyday practice of AI governance, defined and compared.

Verify with counsel or the authority before you rely on any date here. Verify every clock with counsel or the competent authority before relying on it. The tool adds the chapter's hours, days or months to the awareness time and shows the earliest reading; it does not apply rules for counting periods, weekends or public holidays, and it does not decide whether an event is reportable.

The clocks are the ones chapter 17 states, as of 2026-09-24; the tool asserts nothing the chapter does not. It does not compute Cyber Resilience Act Art. 14, California SB 53, New York RAISE Act, OECD common reporting framework (voluntary, no clock).

When

Times are read in this browser's time zone and shown with it; exports carry UTC as well. The clocks count from awareness, except where a regime counts from a later decision.

When a person responsible decided this is, or may be, a reportable event.

EU AI Act Art. 73 asks for the report immediately once a causal link, or its reasonable likelihood, is established.

DORA counts four hours from classification, no later than 24 hours from awareness; a classification made after those 24 hours starts its own four hours.

Your roles for this event

Tick every role you hold. One organisation often holds several.

The AI system's tier under the EU AI Act

From the registry entry. If it is not classified, say so: the tool plans against the high-risk clocks until it is.

If any of these is true

What happened

Tick every reading that is plausible on what you know now. Classify up: the most severe reading sets the level, and you downgrade with evidence.

Decisions already taken

For the record skeleton (optional)

Only needed for the JSON incident record, which must name the system, the organisation and at least one evidence link to validate against incident-record.v1.

Trace, ticket or log links. They stay in this page and in the file you download.

How the tool reads chapter 17

Two decisions, kept apart [1]. Severity is a judgement about harm on the internal scale; reportability is a separate test, run once per regime against that regime's trigger. A moderate incident can still be notifiable, and a severe one can fall outside every regime's scope. The tool sets severity from the most severe reading you tick and runs each regime's test on your roles, the tier and the decisions you have taken.

The severity scale

The chapter's scale is illustrative; what matters is that each level names a harm test.

Severity, as chapter 17 states it
Level Harm test Default response
SEV-1 Critical Death; serious harm to health; serious and irreversible disruption of critical infrastructure; widespread infringement Incident commander within 15 minutes; contain first; legal and DPO on the bridge
SEV-2 Major Infringement of fundamental-rights obligations; serious harm to property or environment; high-risk personal data breach; serious cybersecurity breach of a model Same working day; reportability assessed per regime within hours
SEV-3 Moderate Realised harm that is limited, recoverable and below the serious thresholds Contain same day; after-action review within five working days
SEV-4 Near miss No harm; a plausible path to harm was interrupted Weekly review; regression eval added
ISSUE Issue Defect or control weakness with no event Issue log with owner and due date

The clocks the tool computes

As of 2026-09-24, from the chapter's overlapping clocks table [1], with the instruments behind each row [2][3][4][5][6][7].

Regime, trigger, first report, follow-up and recipient
Regime Who reports Trigger First report Follow-up and final To whom
EU AI Act Art. 73 [2] Provider of a high-risk system; the deployer if the provider cannot be reached Serious incident (Art. 3(49)) Immediately on a causal link or its reasonable likelihood; no later than 2 days (widespread infringement or critical infrastructure), 10 days (death) or 15 days (other) from awareness; an incomplete initial report is allowed Investigation, risk assessment and corrective action; no altering the system before informing authorities Market-surveillance authority where it occurred; the AI Office for systems under its competence
EU AI Act Art. 26(5) [2] Deployer of a high-risk system Serious incident; or reason to consider the system presents a risk Serious incident: immediately, provider first; risk: without undue delay, plus suspension Cooperation with the provider's investigation Provider, then importer or distributor, and the market-surveillance authority
EU AI Act Art. 55(1)(c) with Code of Practice Commitment 9 [3] Provider of a GPAI model with systemic risk Serious incident involving the model Without undue delay; under the Code: 2 days (critical infrastructure), 5 days (serious cybersecurity breach), 10 days (death), 15 days (health, rights, property, environment) Intermediate report at least every four weeks while unresolved; final report within 60 days of resolution AI Office and, as applicable, national authorities
GDPR Art. 33 [4] Controller (the processor notifies the controller without undue delay) Personal data breach, unless unlikely to result in a risk Without undue delay and, where feasible, within 72 hours of awareness; reasons required if later Information may be provided in phases; every breach documented Supervisory authority
GDPR Art. 34 [4] Controller Breach likely to result in a high risk Without undue delay None set Affected data subjects
NIS2 Art. 23 [5] Essential and important entities Significant incident Early warning within 24 hours; incident notification within 72 hours Intermediate report on request; final report within one month of the notification CSIRT or competent authority
DORA Art. 19 with RTS 2025/301 [6][7] Financial entities Major ICT-related incident Within 4 hours of classification as major, and no later than 24 hours from awareness; if classified as major only after those 24 hours, within 4 hours of that classification Intermediate within 72 hours of the initial notification; final within one month of the latest intermediate report Financial competent authority

What the dates mean

  • The triggers are not the same event. GDPR, NIS2 and Art. 73 count from awareness; DORA's four hours count from classification as major, no later than 24 hours from awareness, and a classification made after those 24 hours starts its own four hours; Art. 73 also asks for the report immediately once a causal link, or its reasonable likelihood, is established. The chapter's advice is a timestamp per trigger, not one "opened at" (reading the table).
  • Some regimes defer to others. NIS2 steps aside where a sector-specific Union act imposes at least equivalent notification, which is how DORA displaces NIS2 for financial entities; for Annex III systems whose providers are under equivalent Union reporting obligations, and AI in medical devices, Art. 73 reporting is limited to fundamental-rights infringements. Which regimes count as equivalent is a legal call.
  • The high-risk regime is not in application yet. The Digital Omnibus postponed high-risk classification and the Chapter III duties, the deployer duties included, to 2 Dec 2027 for Annex III systems and 2 Aug 2028 for Annex I systems [8]. Art. 73 was not itself postponed, but it reaches a system only once it is classified as high-risk, so in practice it follows the same dates (verify with counsel); the GPAI duties of Art. 55 already apply. For an earlier awareness date the tool marks those clocks "not yet in application" and still shows the dates, for planning and drills.
  • "Immediately" and "without undue delay" have no number. The tool dates them to the awareness time. Follow-up dates assume the previous report went on its last permitted day; filing earlier moves them earlier.
  • Periods are simple sums. Hours and 24-hour days are added to the awareness time, and a month is the same day and time a calendar month later. No rule on counting periods, weekends or public holidays is applied: that reading is for counsel or the authority.

By hand, without JavaScript

  1. Write down the awareness time, and the classification and causal-link times if any.
  2. Find the most severe harm test above that the facts plausibly meet: that is the severity.
  3. For each row of the clock table, check who reports against your roles and the trigger against the facts. Where both hold, add the row's hours or days to the awareness time.
  4. Record each "not applicable" with its rationale and owner, in one incident record from which every report is rendered (one record, many reports; the incident record fields).

What you can take away

  • Reminders (.ics). One event per dated step, at the deadline itself and marked busy, with an alarm an hour before (and a day before when the deadline is more than two days out); the exact time is in the title too [9].
  • Record skeleton (JSON). A record that validates against the incident-record.v1 schema, with one reporting obligation per regime, its rationale and deadline; the tool's inputs travel in extensions so the file can be reopened here.
  • Summary (Markdown) and the link, which carries the inputs after the #.

What this is not

Not legal advice, not a reportability decision and not a conformity claim. The chapter also lists Cyber Resilience Act Art. 14; California SB 53; New York RAISE Act; OECD common reporting framework (voluntary, no clock); read them in its table. For the response itself (contain, freeze before you fix, root cause), read the response lifecycle and deployer duties, and the Incident Pipeline pattern that wires detection to the report.

Terms used here

Sources

  1. [1] 17. Incidents, issues and root causes: "The overlapping clocks" (table as of 2026-09-24), "A severity scale mapped to the clocks", "Deployer duties: inform the provider, suspend use" and "Reading the table", the text this tool computes from. AI Governance Engineering Body of Knowledge. 2026-09-24. https://aigovernanceengineer.com/bok/incidents (verified: primary)
  2. [2] Regulation (EU) 2024/1689 (AI Act), consolidated text as amended by Reg. (EU) 2026/1744: Art. 3(49) serious incident, Art. 3(61) widespread infringement, Art. 26(5) deployer duties, Art. 55(1)(c) GPAI serious incidents, Art. 73 reporting of serious incidents (2, 10 and 15 days), Art. 75(1a). Publications Office of the EU (EUR-Lex); Art. 26(5), 55(1)(c) and 73(2) to (4) read on the Commission's AI Act Service Desk on 2026-09-24. 2026-07-27. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng#art_73 (verified: primary)
  3. [3] General-Purpose AI Code of Practice, Safety and Security chapter, Commitment 9 serious incident reporting (timelines of 2, 5, 10 and 15 days; intermediate reports at least every four weeks; final report within 60 days of resolution). European Commission. 2025-07-10. https://ec.europa.eu/newsroom/dae/redirection/document/118119 (verified: primary)
  4. [4] Regulation (EU) 2016/679 (GDPR): Art. 33 notification of a personal data breach to the supervisory authority (72 hours where feasible; processor to controller) and Art. 34 communication to the data subject (high risk). Publications Office of the EU (EUR-Lex). 2016-04-27. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng (verified: primary)
  5. [5] Directive (EU) 2022/2555 (NIS2): Art. 23 reporting obligations (early warning within 24 hours; notification within 72 hours; final report within one month); Art. 4 sector-specific Union acts. Publications Office of the EU (EUR-Lex). 2022-12-14. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng (verified: primary)
  6. [6] Regulation (EU) 2022/2554 (DORA): Art. 19 reporting of major ICT-related incidents. Publications Office of the EU (EUR-Lex). 2022-12-14. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng (verified: primary)
  7. [7] Commission Delegated Regulation (EU) 2025/301, RTS on the content and time limits for major ICT-related incident reports under DORA (Art. 5(1): initial notification within 4 hours of classification and no later than 24 hours from awareness; Art. 5(2): within 4 hours of a classification made after those 24 hours; intermediate within 72 hours; final within one month). Publications Office of the EU (EUR-Lex). 2024-10-23. https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng (verified: primary)
  8. [8] Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending Reg. (EU) 2024/1689; in force 27 Jul 2026; Annex III high-risk obligations from 2 Dec 2027. Publications Office of the EU (EUR-Lex). 2026-07-24. https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng (verified: primary)
  9. [9] RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar) (the reminders file: timed events in UTC with a unique UID, DTSTAMP and display alarms, VALARM). IETF. 2009-09. https://www.rfc-editor.org/rfc/rfc5545 (verified: primary)