AI Incident Reporting: Which Regulator Clock Starts First

Open a file, not a ticket. The first-hour record captures the facts that decide which deadlines exist, because the shortest window in the set is four hours long and starts on a decision, not on the failure itself.

# incident-intake.yaml
# House convention, not a tool format. One file per incident, opened in the
# first hour. Trailing comments name the official field or article each key feeds.
# Worked example: an in-scope manufacturer, NIS2 Annex II, not a financial entity.

incident_ref: INC-2028-0412

timestamps_utc:                            # ISO 8601 UTC, as the DORA form demands
  aware_at: 2028-04-12T08:41:00Z           # form field 2.2; starts NIS2 24h and
                                           # 72h, GDPR 72h, AI Act 15 / 2 / 10 days
  classified_major_at: null                # DORA only, form field 2.3; null here
                                           # because DORA does not apply to us
  classification_owner: head-of-ops        # the one person allowed to set it

regime:
  financial_entity_under_dora: false       # true would switch NIS2 Art 21 and 23 off
  nis2_entity: annex_ii                    # annex_i | annex_ii | out_of_scope
  ai_act_role: provider                    # Art 3(3): we put it into service

fork_questions:
  person_harmed: unknown                   # Art 3(49)(a): death moves Art 73 to 10 days
  critical_function_down: true             # NIS2 Art 23(3) significance test
  personal_data_left_our_control: unknown  # GDPR Art 33

ai_act:
  system: shift-allocation-model
  annex: iii                               # Annex III point 4(b): allocating tasks
  built_on_our_own_gpai_model: true        # Art 75(1)(a) first condition
  model_and_system_same_undertaking: true  # second condition, so Art 75(1a)
                                           # sends the report to the AI Office
  equivalent_union_reporting: false        # so no Art 73(9) narrowing

filings:
  - { regime: nis2,   filing: early_warning,          due: aware_at + 24h }
  - { regime: nis2,   filing: incident_notification,  due: aware_at + 72h }
  - { regime: gdpr,   filing: art_33_notification,    due: aware_at + 72h,
      if: personal_data_left_our_control }
  - { regime: ai_act, filing: art_73_report,          due: aware_at + 15d,
      to: ai_office }

The key names are ours. The field numbers in the comments are not: 2.2 and 2.3 are positions in Annex I of Implementing Regulation (EU) 2025/302, which carries 76 numbered fields in four blocks, 15 on the entity, 10 for the initial notification, 35 for the intermediate report and 16 for the final report. The example is a manufacturer above the NIS2 size ceiling, which is why classified_major_at is null and no DORA filing appears. Switch it to a credit institution and three lines flip together, and the filings block is rewritten.

Three fork questions do the routing. Has a person been harmed? Article 3(49)(a) of the AI Act treats death or serious harm to health as a serious incident, and death moves the Article 73 deadline to 10 days. Is a critical or important function down? That is the NIS2 Article 23(3) significance test and, for a financial entity, the critical-services gate in Delegated Regulation (EU) 2024/1772 Article 8(1). Has personal data left your control? That is GDPR Article 33, and nothing else asks it.

Eight fields, and only one is a judgement call that a single person should own.

The deconfliction is a two-step, not a stack.

Directive (EU) 2022/2555, Article 4
Sector-specific Union legal acts

1. Where sector-specific Union legal acts require essential or important
   entities to adopt cybersecurity risk-management measures or to notify
   significant incidents and where those requirements are at least equivalent in
   effect to the obligations laid down in this Directive, the relevant
   provisions of this Directive, including the provisions on supervision and
   enforcement laid down in Chapter VII, shall not apply to such entities. Where
   sector-specific Union legal acts do not cover all entities in a specific
   sector falling within the scope of this Directive, the relevant provisions of
   this Directive shall continue to apply to the entities not covered by those
   sector-specific Union legal acts.

Recital 28 identifies Regulation (EU) 2022/2554 as that sector-specific act and tells Member States not to apply the Directive's risk-management, reporting, supervision and enforcement provisions to financial entities covered by it. Article 4(2) sets the equivalence test in two alternative limbs: risk-management measures equivalent in effect to Article 21(1) and (2), or immediate access for NIS2 bodies plus notification requirements equivalent in effect to Article 23(1) to (6).

A financial entity covered by DORA does not file NIS2, and a hospital, energy operator or in-scope manufacturer does not file DORA. The second sentence of Article 4(1) limits that carve-out: where the sector-specific act misses entities in a sector, the Directive keeps applying to them. Article 2(10) closes the reverse gap, excluding entities a Member State has exempted from DORA's scope.

Two provisions resemble a second filing without being one. DORA Article 19(6)(c) requires the competent authority, on receiving each report, to pass the details to the competent authorities, single points of contact or CSIRTs designated under NIS2, and Article 19(1) lets a Member State require the same Article 20 template to go to those bodies directly. That is one filing, possibly delivered twice, not a NIS2 notification with its own clock.

The AI Act narrows rather than switches off. Article 73(9) limits notification to Article 3(49)(c) incidents, the fundamental-rights limb, but only for high-risk systems in Annex III and only where the provider is itself subject to Union instruments laying down equivalent reporting obligations. The relief attaches to the provider's regulatory status, not the deployer's, so a manufacturer that happens to be a NIS2 important entity should not assume it. If you land on that limb, who owes a fundamental rights impact assessment is the adjacent question.

No row carries all four regimes, which is why AI compliance in financial services reads differently from the same exercise in a hospital or a factory.

The hour figures do not live in DORA itself. Regulation (EU) 2022/2554 Article 19(4) names the three filings and Article 20 delegates the time limits; the numbers exist only in Delegated Regulation (EU) 2025/301, so citing level 1 for a four-hour deadline is a sourcing error.

Delegated Regulation (EU) 2025/301, Article 5
Time limits for the initial notification, and for the intermediate and final reports

1. Financial entities shall submit the initial notification and the intermediate
   and final reports as referred to in Article 19(4), points (a), (b) and (c), of
   Regulation (EU) 2022/2554 within the following time limits:

(a) for the initial report: as early as possible, but in any case, within four
    hours from the classification of the ICT-related incident as a major
    ICT-related incident and no later than 24 hours from the moment the
    financial entity has become aware of the ICT-related incident;

(b) for the intermediate report: at the latest within 72 hours from the
    submission of the initial notification, even where the status or the
    handling of the incident have not changed [...] Financial entities shall
    submit an updated intermediate report without undue delay, and in any case
    when the regular activities have been recovered;

(c) for the final report: no later than one month after either the submission of
    the intermediate report, or, where applicable, after the latest updated
    intermediate report.

Three anchors, and two are your own prior filings. The intermediate report runs from the submission of the initial notification, not from awareness, and the final report runs from the intermediate report or the latest updated one. Because point (b) demands an updated intermediate report when regular activities are recovered, a three-week recovery does not compress the final report into what is left of the month. It restarts the month.

Article 5(2) removes the reading that makes 24 hours safe. Where an entity has not classified an incident as major within 24 hours of awareness but classifies it later, the initial notification is due within four hours of that later classification. Slow classification does not buy time, it moves the four-hour window.

Classification is therefore the real deadline, and it is a test with a gate in front of it. Delegated Regulation (EU) 2024/1772 Article 8(1) treats an incident as major where it affected critical services under Article 6 and where either the data-loss threshold in Article 9(5)(b) is met alone, or two or more of the other thresholds are met.

Six criteria, and the pair an AI serving outage reaches first is downtime plus reputation: two hours of unavailability on a service supporting a critical or important function, and one press mention. Neither needs a euro of realised loss. Article 8(2) then aggregates individually non-major incidents into one major incident where they recurred at least twice within six months with the same apparent root cause, and Article 19(3) of DORA separately requires you to inform clients whose financial interests are affected, without undue delay.

Read the form first. DORA Article 18(1) lists six classification criteria, but Annex I field 2.5 offers seven choices, because the criterion bundling clients, counterparts and transactions with reputational impact is split in two. Article 2 of Delegated Regulation (EU) 2025/301 sets out ten items for the initial notification, including the criteria you classified on: you file your reasoning, not just your timestamp.

Article 5 carries a relief, and an exclusion list that takes it back from four categories.

Delegated Regulation (EU) 2025/301, Article 5

3. Financial entities that are unable to submit the initial notification,
   intermediate report, or final report within the time limits set out in
   paragraph 1, shall inform the competent authority thereof without undue
   delay, but no later than the respective time limits for the submission of the
   notification or report, and shall explain the reasons for the delay.

4. Where the time limit for the submission of an initial notification,
   intermediate report, or a final report falls on a weekend day or a bank
   holiday in the Member State of the reporting financial entity, the financial
   entity may submit the initial notification, intermediate or final reports by
   noon of the next working day.

5. Paragraph 4 shall not apply for the submission of an initial notification or
   an intermediate report by credit institutions, central counterparties,
   operators of trading venues, and other financial entities identified as
   essential or important entities pursuant to Article 3 of Directive (EU)
   2022/2555.

Paragraph 5 names four categories: credit institutions, central counterparties, operators of trading venues, and other financial entities identified as essential or important under NIS2 Article 3. The disapplication is narrower than it looks: it removes the relief for the initial notification and the intermediate report only, so those four keep it for the final report, the one filing whose deadline is a calendar date a month out.

Article 5(6) extends the exclusion at discretion. A competent authority may decide the relief does not apply to other financial entities that are significant or systemic nationally or at Union level, must notify that decision to the entities identified, and it bites only for incidents reported after the date of notification. If you are large but outside the four named categories, the weekend is a question about your inbox rather than the text.

Article 5(3) is the provision to wire in regardless: an entity that will miss any of the three limits must tell the competent authority before that deadline, with reasons. A missed deadline reported late is two failures; one flagged at hour three and a half is one.

Directive (EU) 2022/2555, Article 23(4)

(a) without undue delay and in any event within 24 hours of becoming aware of
    the significant incident, an early warning [...];
(b) without undue delay and in any event within 72 hours of becoming aware of
    the significant incident, an incident notification [...];
(c) upon the request of a CSIRT or, where applicable, the competent authority,
    an intermediate report on relevant status updates;
(d) a final report not later than one month after the submission of the incident
    notification under point (b) [...];
(e) in the event of an ongoing incident at the time of the submission of the
    final report referred to in point (d), Member States shall ensure that
    entities concerned provide a progress report at that time and a final report
    within one month of their handling of the incident.

Five limbs, and (a) and (d) are the two that decide how much work this is. Point (a) is an early warning, not a report, so treating it as a 24-hour reporting deadline invents work the Directive does not ask for. Point (d) counts one month from the submission of the notification under point (b), not from the incident. Point (e) covers the case where the incident is still running at that moment: you file a progress report then and the final report within one month of handling it.

The trigger is Article 23(3): an incident is significant if it has caused or is capable of causing severe operational disruption or financial loss for the entity, or has affected or is capable of affecting other persons by causing considerable material or non-material damage. The words "is capable of causing" do the work. A serving layer returning wrong classifications for six hours can be significant on capability alone.

The early warning is not pure cost. Article 23(5) requires the CSIRT or competent authority to respond without undue delay and where possible within 24 hours, with initial feedback and, on request, guidance or operational advice. Filing at hour four rather than hour 23 buys that response while it still matters.

Scope decides whether any of this reaches you. Annex I, the sectors of high criticality, covers health, energy, transport, banking, financial market infrastructures, drinking water, waste water, digital infrastructure, ICT service management, public administration and space; manufacturing sits in Annex II. Article 3(1)(a) makes Annex I entities essential where they exceed the ceilings for medium-sized enterprises and Article 3(2) makes the rest important. The band decides the penalty: Article 34(4) and (5) set fines of at least EUR 10 000 000 or 2 % of total worldwide annual turnover for essential entities and at least EUR 7 000 000 or 1,4 % for important ones, whichever is higher.

One derogation: the second subparagraph of Article 23(4) gives trust service providers 24 hours rather than 72 where the incident affects their trust services.

Regulation (EU) 2016/679, Article 33(1)

In the case of a personal data breach, the controller shall without undue delay
and, where feasible, not later than 72 hours after having become aware of it,
notify the personal data breach to the supervisory authority competent in
accordance with Article 55, unless the personal data breach is unlikely to
result in a risk to the rights and freedoms of natural persons. Where the
notification to the supervisory authority is not made within 72 hours, it shall
be accompanied by reasons for the delay.

Both qualifiers matter. The duty is conditional on feasibility and disapplied where the breach is unlikely to result in a risk to rights and freedoms, and late notification is contemplated by the text with an obligation to explain rather than an automatic breach. Article 34 is the separate half: communication to the data subject where the risk is high, removed by Article 34(3)(a) where the data was rendered unintelligible, in particular by encryption.

The fact that starts this clock, personal data leaving your control, is asked by nothing else in the set. It is not among the DORA classification criteria, not in the NIS2 Article 23(3) significance test, and not in the AI Act Article 3(49) definition. The answer comes from your architecture rather than the incident narrative: whether a retrieval layer kept a copy after the source row was deleted is what a DELETE actually does inside an HNSW index, and whether a managed service put a replica elsewhere is why a Frankfurt region label is not data sovereignty. For lawful basis, impact assessments and transfers, handling EU customer data in AI systems covers what this post does not.

The regulator then makes you declare the deconfliction. Annex I field 3.31, "Reporting to other authorities", is a multiple choice over six values: police or law enforcement, CSIRT, data protection authority, national cybersecurity agency, none, and other, specified in field 3.32. It is mandatory in the intermediate and final reports, so whatever you decided about GDPR in hour one you write down in hour 76.

Regulation (EU) 2024/1689, Article 73

2. The report referred to in paragraph 1 shall be made immediately after the
   provider has established a causal link between the AI system and the serious
   incident or the reasonable likelihood of such a link, and, in any event, not
   later than 15 days after the provider or, where applicable, the deployer,
   becomes aware of the serious incident.

3. Notwithstanding paragraph 2 [...], in the event of a widespread infringement
   or a serious incident as defined in Article 3, point (49)(b), the report
   [...] shall be provided immediately, and not later than two days after the
   provider or, where applicable, the deployer becomes aware of that incident.

4. Notwithstanding paragraph 2, in the event of the death of a person, the
   report shall be provided immediately after the provider or the deployer has
   established, or as soon as it suspects, a causal relationship between the
   high-risk AI system and the serious incident, but not later than 10 days
   after the date on which the provider or, where applicable, the deployer
   becomes aware of the serious incident.

All three limbs count from awareness by the provider or, where applicable, the deployer. None counts from the incident, and none from the moment you established the causal link, which is only the trigger for the "immediately" half of each sentence. Paragraph 2's second subparagraph adds that the period must take account of severity, so 15 days is an outer bound rather than a target. Article 73(5) permits an incomplete initial report followed by a complete one, making this limb two-stage too.

The trigger is Article 3(49), which defines a serious incident by four consequences: the death of a person or serious harm to health; a serious and irreversible disruption of the management or operation of critical infrastructure; the infringement of obligations under Union law intended to protect fundamental rights; and serious harm to property or the environment. Limb (b) routes an incident to the two-day deadline. Limb (c) is the only one that survives both the Article 73(9) narrowing and the Article 73(10) device carve-out, which routes systems covered by Regulations (EU) 2017/745 and (EU) 2017/746 to a nationally chosen authority instead and is where the MDR and IVDR route into the AI Act takes over.

Article 73(8) starts a clock back at you: the market surveillance authority takes measures under Article 19 of Regulation (EU) 2019/1020 within seven days of receiving the notification. What you send at day 15 is acted on at day 22.

Now the honest part. Article 73 sits in Chapter IX and applies from 2 August 2026, but the provisions that create a high-risk AI system with a provider carrying obligations sit in Chapter III Sections 1 to 3, and Regulation (EU) 2026/1744, the Digital Omnibus on AI in force since 27 July 2026, moved those to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. So there is no high-risk AI system for Article 73 to attach to today, while DORA has applied since 17 January 2025, NIS2 since October 2024 and GDPR since 2018. You build this limb ahead of a clock that starts later.

Thirteen rows. Seven count from awareness of the incident; the other six count from something you did or from a state you reached.

Deployment location changes nothing about the first three clocks. A major ICT-related incident is major on the Delegated Regulation (EU) 2024/1772 criteria whether the model runs in your rack or someone else's, NIS2 significance is about operational disruption and damage to others, and GDPR Article 33 is about personal data. What a private perimeter changes there is evidentiary: the aware_at timestamp exists only if you instrument it, and inside your own perimeter you are the only party who can. AI Act Article 26(6) will require deployers to keep a high-risk system's automatically generated logs, to the extent they control them, for at least six months, and that retention is what makes the timestamp defensible in month four.

The fourth clock is where a private deployment changes the answer completely. Article 3(3) makes a provider anyone who develops an AI system, or has one developed, and puts it into service under its own name, and Article 3(11) defines putting into service to include supply "for own use". A team that builds an internal high-risk system for itself is the provider outright, so Article 73(1) lands directly and there is no chain to escalate up. Article 25(1)(b) and (c) reach the same result for a substantial modification or a repurposing; whether fine-tuning alone crosses that line is worked through in what makes you a provider when you fine-tune inside your own perimeter. Article 26(5) covers only the narrow case where a deployer of someone else's system cannot reach the provider. Being the provider then decides where the report goes, and the Digital Omnibus moved that.

Regulation (EU) 2026/1744, amendment item (31)(c), inserting into
Regulation (EU) 2024/1689:

'1a. By way of derogation from Article 73, providers of high-risk AI systems
 subject to the competence of the AI Office pursuant to paragraph 1 of this
 Article shall report any serious incidents to the AI Office. Article 73 (2) to
 (9), shall apply mutatis mutandis. The AI Office shall promptly transmit the
 relevant information to the market surveillance authority of the Member State
 in the territory of which the provider or its legal representative is
 situated.'

and, in amendment item (31)(b), replacing Article 75(1):

'1. The AI Office shall be exclusively competent for the supervision and
 enforcement of the obligations under this Regulation in relation to the
 following AI systems:
 (a) AI systems based on general-purpose AI models where the model and the
     system are developed by the same provider, or by providers forming part of
     the same undertaking as that provider, with the exception of:
     (i)   AI systems related to products covered by the Union harmonisation
           legislation listed in Annex I;
     (ii)  AI systems referred to in point 2 of Annex III;
     (iii) AI systems provided by law enforcement authorities, border management
           authorities and financial institutions, insofar as those AI systems
           fall under Article 74(6); and
     (iv)  AI systems referred to in point 8 of Annex III as regards the
           administration of justice;'

Four exceptions, and the third produces an asymmetry worth sitting with. A bank stays with its financial supervisor under Article 74(6), expressly carved out of AI Office competence, and for an Annex III system it gets the Article 73(9) narrowing as well, because it is a provider subject to an equivalent Union reporting instrument. A pharmaceutical or manufacturing group that trained its own model and built the system on it inside the same undertaking gets neither: it files in Brussels, and it files the full report. The regulated entity ends up better placed than the industrial one. The quoted list is not exhaustive of the replaced Article 75(1), which also reaches systems inside very large online platforms.

Do not overclaim the trigger. The test is two-part: the system is based on a general-purpose AI model, and the model and the system are developed by the same provider or within the same undertaking. An open-weight checkpoint pulled off a public hub fails the second part, so the ordinary self-hoster stays with the national authority. What moves you to the AI Office is training your own model, not running someone else's on your own metal. One consequence: Article 73 is absent from the Article 99(4) fine list, but the Omnibus-inserted Article 75c(4)(a) makes infringement of any applicable provision, including those not listed there, subject to that band when the AI Office enforces.

Every legal fact above is checkable without a secondary source.

# EUR-Lex returns HTTP 202 with an empty body to scripted clients.
# The Publications Office CELLAR endpoint serves the same OJ text.
# Only application/xhtml+xml resolves; text/html and application/pdf return 400.

curl -sL \
  -H 'Accept: application/xhtml+xml' \
  -H 'Accept-Language: eng' \
  http://publications.europa.eu/resource/celex/32025R0301 \
  -o 2025-301.xhtml

# CELEX numbers used in this post:
#   32025R0301  DORA reporting RTS (time limits)
#   32025R0302  DORA reporting ITS (the 76-field template)
#   32024R1772  DORA classification RTS (materiality thresholds)
#   32022L2555  NIS2
#   32024R1689  AI Act
#   32026R1744  Digital Omnibus on AI
#   32022R2554  DORA level 1
#   32016R0679  GDPR

The intervention this week is two fields and one name. Add aware_at and classified_major_at to your incident template, both ISO 8601 UTC, because the official form demands both and the gap between them is printed on the submission. Then name the single person allowed to write the second one, and give them a documented path to the initial notification that fits inside four hours. Everything else here is a lookup. That part is a decision someone makes before the incident, because no version of it gets made well at 02:00.