GPAI Incident Reporting: Navigating AI Act Art.73, CRA Art.14 & NIS2 Art.23 Overlap

Post #1510 in the sota.io EU AI Act GPAI Incident Reporting Series

A serious incident involving a GPAI model rarely stays within the boundaries of a single regulation. If the model is embedded in a software product, the same event that triggers Art.73 of the EU AI Act can simultaneously constitute a severe incident under the Cyber Resilience Act's Art.14 and a significant cybersecurity incident under NIS2 Art.23. Three reporting clocks — each with its own authority, timeline, and content requirements — start running from the same moment of awareness.

This guide maps the overlap zones, compares the timelines, identifies the single-report strategies the regulations themselves permit, and gives GPAI providers a decision framework for coordinating multi-regulation incident response before the August 2, 2026 enforcement date for AI Act Art.73.

The Three Regulations in Scope

Before mapping the overlaps, it is important to establish exactly which legal instruments apply and when.

EU AI Act Art.73 — Reporting of serious incidents

Art.73 creates the primary incident-reporting obligation for GPAI model providers. It requires notification to the relevant national market surveillance authority (MSA) whenever a provider becomes aware of a serious incident. A serious incident is defined in Art.3(49) as any incident or malfunction of an AI system that directly or indirectly leads to death, serious harm to health, serious unintended breaches of obligations under EU or member state law that protect fundamental rights, or serious and irreversible disruption to the provision of critical infrastructure services.

Enforcement deadline: 2 August 2026. GPAI-model-specific obligations, including Art.73 incident reporting, become binding on that date.

CRA Art.14 — Reporting obligations of manufacturers

Art.14 applies to manufacturers of products with digital elements — a category that can encompass standalone GPAI software models and AI systems distributed as software products. Art.14 requires notification to ENISA and the relevant national CSIRT coordinator whenever a manufacturer becomes aware of an actively exploited vulnerability in its product, or a severe incident affecting the security of a product.

Application date: 11 September 2026. Art.14 is one of three provisions that entered application before the main CRA body. Chapter IV (conformity assessment body notifications) applied from June 11, 2026. Art.14 reporting obligations apply from September 11, 2026. The full CRA applies from December 11, 2027.

NIS2 Art.23 — Reporting obligations

Art.23 applies to essential and important entities in the sectors listed in Annexes I and II of NIS2. For GPAI providers that qualify as digital infrastructure providers, cloud computing service providers, or managed service providers under NIS2 Annex I or II, Art.23 requires notification to the relevant national Computer Security Incident Response Team (CSIRT) or competent authority for significant incidents — meaning incidents that have or can have a significant impact on the provision of services.

NIS2 is already in force. Member state transposition was required by October 17, 2024. As of June 2026, most member states have transposed NIS2 into national law.

When Does an Incident Trigger Under All Three?

Not every GPAI incident triggers all three regulations simultaneously. The overlap occurs at a specific intersection of facts.

Single trigger (AI Act only): A GPAI model generates output that causes serious harm to a user — for example, a medical advice AI provides instructions that lead to a hospitalisation. The harm flows from the AI system's behaviour, not from a software vulnerability or cybersecurity failure. CRA Art.14 is not triggered (no exploited vulnerability, no security incident). NIS2 is not triggered (no disruption to a network or information system). AI Act Art.73 is the sole reporting obligation.

Dual trigger (AI Act + NIS2): A DDoS attack causes a GPAI API to become unavailable, and the outage disrupts critical services for essential-entity customers. The AI Act Art.73 trigger may apply if the disruption constitutes serious and irreversible disruption to critical infrastructure services. NIS2 Art.23 applies because there is a significant cybersecurity incident affecting the provider's services. CRA Art.14 does not apply if the attack exploited no product vulnerability — it was an availability incident, not a product security defect.

Triple trigger (AI Act + CRA + NIS2): A previously unknown vulnerability in the GPAI model software is actively exploited to extract training data or manipulate model behaviour, causing serious harm to health or a fundamental rights breach and disrupting services to essential-entity customers. All three reporting obligations are active simultaneously.

The triple-trigger scenario is the hardest to manage. It is also the most foreseeable: supply chain attacks on AI model weights, prompt injection exploits with systemic effect, and API security failures that cascade into service outages are all realistic incident patterns for GPAI providers.

Timeline Comparison: Three Clocks Running at Once

The core coordination challenge is that the three regulations impose materially different timelines, measured from the same moment of awareness.

Several differences are operationally significant.

Working days vs calendar hours. AI Act Art.73 counts in working days. CRA Art.14 and NIS2 Art.23 count in calendar hours. A 72-hour CRA window that starts on a Thursday evening may expire before the AI Act's 2-working-day window begins. In a triple-trigger scenario, the CRA and NIS2 clocks almost certainly expire before the AI Act's working-day count reaches deadline.

The AI Act has a tiered initial deadline. The standard AI Act timeline is 15 working days. But if the incident involves critical infrastructure disruption or imminent risk of death, the deadline compresses to 2 working days — which is faster than the CRA or NIS2 72-hour clock in calendar terms. A provider facing a critical infrastructure incident has approximately 48 hours (working) under AI Act Art.73 and 72 calendar hours under CRA Art.14 and NIS2 Art.23.

Final report timelines diverge sharply. The CRA 14-day final report deadline is activated when a corrective or mitigating measure becomes available — which may be much earlier than 14 days if the vulnerability is patchable. The NIS2 1-month final report runs from the incident notification. The AI Act Art.73 10-working-day timeline applies specifically when death has occurred and is measured from awareness.

The Authority Matrix: Who Gets What Notification

The three regulations route notifications to different authorities, which creates a deduplication problem unless the provider proactively coordinates.

In most member states, the NIS2 competent authority and the CRA CSIRT coordinator are separate from the AI Act market surveillance authority. Germany provides a clear example: the Bundesnetzagentur (BNetzA) has designated competence for AI Act enforcement, while BSI is both the NIS2 authority and the CRA CSIRT coordinator. A German GPAI provider in a triple-trigger scenario sends notifications to both BNetzA (AI Act) and BSI (CRA and NIS2) — with different content, different timelines, and different statutory bases.

The Gap Window: August 2 to September 11, 2026

A particular coordination challenge arises from the six-week gap between AI Act Art.73 enforcement (August 2, 2026) and CRA Art.14 application (September 11, 2026).

During this window, GPAI providers who manufacture products with digital elements are subject to AI Act Art.73 incident reporting but not yet subject to CRA Art.14 reporting. If a severe software incident occurs between August 2 and September 11, 2026 — for instance, an actively exploited model vulnerability — the provider must notify under AI Act Art.73 but has no parallel CRA Art.14 obligation.

This does not mean CRA preparedness can wait until September 11. The 72-hour CRA Art.14 clock runs from when a manufacturer becomes aware of a vulnerability or incident. Manufacturers who build their incident response processes only after September 11, 2026 will begin that clock having already lost preparation time. The six-week gap is preparation time, not a break.

NIS2 Art.23 applies throughout the gap for providers in scope. An incident during the gap that is significant under NIS2 must be reported under NIS2 regardless of whether it would also qualify under CRA or AI Act.

Single-Report Strategy: What the Regulations Permit

CRA Art.16 mandates the establishment of a single reporting platform at EU level, to which manufacturers can submit vulnerability and incident notifications for distribution to the relevant national CSIRT coordinators and ENISA. This platform consolidates the CRA reporting channel and avoids manufacturers having to submit the same vulnerability notification to multiple national authorities in cross-border incidents.

NIS2's cross-border incident coordination uses the CSIRT network established under Art.15 of the original NIS Directive (retained in NIS2). When an incident has cross-border impact, the reporting CSIRT coordinates with affected national CSIRTs. The provider's notification obligation remains to the national authority.

There is currently no single platform that accepts notifications across all three regulations simultaneously. AI Act MSA notifications, CRA/ENISA notifications, and NIS2 CSIRT notifications are routed through separate systems. The regulation texts do not currently provide a consolidated multi-regulation reporting mechanism.

The practical single-report strategy is therefore not a single platform but a coordinated notification package:

1. Prepare one master incident record containing all facts, timeline, impact assessment, and technical detail.
2. Derive the regulation-specific notification from that master record, reformatting for each authority's expected structure.
3. Submit to AI Act MSA, CRA CSIRT coordinator / ENISA, and NIS2 CSIRT in parallel, referencing the same incident identifier across all submissions.
4. Notify the authorities of the multi-regulation nature of the incident to facilitate cross-authority coordination — most member states have not yet formalised protocols for this, but early disclosure prevents duplicated investigation effort.

This approach satisfies each regulation's independent notification requirement while minimising duplicated documentation work.

Content Overlap and Divergence in Notifications

The three notification templates share a substantial common core — incident identifier, affected system, timeline of events, initial impact assessment, and notifying entity's contact details. But each regulation requires content the others do not.

AI Act Art.73 unique requirements:

• Identification of the specific AI system and GPAI model involved
• Description of how the AI system's behaviour contributed to the serious incident (causation analysis)
• Reference to the system's registration in the EU database (Art.71)
• For GPAI models with systemic risk: notification to the AI Office via the MSA

CRA Art.14 unique requirements:

• Technical description of the exploited vulnerability (CVE reference or equivalent if not yet assigned)
• Product identifier and affected version range
• Whether the vulnerability was actively exploited at the time of notification
• Available mitigation measures or workarounds

NIS2 Art.23 unique requirements:

• Preliminary assessment of whether the incident is cross-border in nature
• Sector designation (Annex I or II) and competent authority jurisdiction
• Impact on other entities or sectors that depend on the notifying entity

Providers should build notification templates that cover all three requirement sets, with modular sections that can be included or excluded based on which regulations apply to a given incident.

Decision Framework: Which Checks to Run First

When an incident occurs, GPAI providers should work through the following sequence before determining which reporting obligations are active.

Step 1 — Characterise the incident source. Is the incident caused by the AI system's output or behaviour (AI Act trigger zone)? By exploitation of a software vulnerability (CRA trigger zone)? By a cybersecurity attack on the provider's infrastructure (NIS2 trigger zone)? By a combination?

Step 2 — Apply the serious incident / significant incident / severe incident threshold. AI Act Art.3(49) sets the serious incident definition. CRA Art.14 covers actively exploited vulnerabilities and severe incidents. NIS2 Annex provides the significance criteria. Incident triage must apply all three thresholds, not just the first that appears to fit.

Step 3 — Check the application date. Before September 11, 2026, CRA Art.14 does not apply even if the incident would otherwise qualify. AI Act Art.73 applies from August 2, 2026. NIS2 Art.23 applies now.

Step 4 — Identify the reporting authorities. Determine the member state of establishment for each regulation (which may differ), identify the designated authorities, and locate their notification channels and preferred formats.

Step 5 — Synchronise the clocks. Identify the earliest deadline across active regulations. CRA and NIS2 use calendar hours; AI Act uses working days. Map both to calendar time to identify the actual sequence of submission deadlines.

Step 6 — Prepare the master incident record. Draft the complete factual narrative once, then derive each regulation-specific notification from it. Submit in parallel, cross-referencing the same incident identifier.

Practical Implications for GPAI Providers

Several operational preparations follow from the multi-regulation structure.

Incident triage must be multi-regulation aware. Incident response procedures written solely around AI Act Art.73 will miss CRA and NIS2 triggers. Incident triage playbooks should include a regulatory scope check that applies all three thresholds simultaneously at the point of incident detection.

The 24-hour CRA and NIS2 early warning is the binding constraint. In a triple-trigger incident, the 24-hour early warning to the CSIRT coordinator (CRA Art.14) and the national CSIRT (NIS2 Art.23) is the fastest mandatory obligation. Incident response procedures must be capable of generating a credible early warning within 24 calendar hours of awareness, which requires pre-built notification templates and pre-identified authority contacts.

CRA Art.14 and NIS2 Art.23 apply to the same categories of events but through different lenses. CRA Art.14 focuses on product vulnerabilities and security defects; NIS2 Art.23 focuses on service disruption and cybersecurity incidents. A severe software supply chain attack on a GPAI model may qualify under both without the incident facts being identical for each regulation.

Cross-regulation coordination is not yet formalised. Member states have not yet established formal inter-authority protocols for AI Act MSA / NIS2 CSIRT / CRA CSIRT coordination. Providers who notify all three authorities simultaneously and reference the multi-regulation nature of the incident are ahead of current enforcement infrastructure.

Implementation Checklist for Multi-Regulation Incident Response

Before August 2, 2026:

• Confirm whether the GPAI model is also in scope for CRA (product with digital elements) and NIS2 (essential or important entity designation)
• Identify the relevant national authorities under all three regulations for the primary establishment jurisdiction
• Locate the notification channels and current template requirements for each authority
• Build or update the master incident record template to cover all three regulation-specific content requirements
• Run a tabletop exercise against a triple-trigger scenario (exploited GPAI model vulnerability causing service disruption and serious harm)
• Map the 24-hour → 72-hour → 14-day / 15-working-day timeline to an internal escalation matrix with named owners

For the CRA gap window (August 2 – September 11, 2026):

• Confirm internal processes are ready for CRA Art.14 reporting even before September 11
• Identify which existing NIS2 and AI Act procedures can be extended to cover CRA Art.14 with minimal additional work

After September 11, 2026 (CRA Art.14 active):

• Run a first live test notification to confirm authority contacts and submission systems are functional
• Document multi-regulation notifications as precedent for future incidents

Conclusion

Multi-regulation incident overlap is not an edge case for GPAI providers — it is the default pattern for any sufficiently serious incident involving a GPAI model embedded in a software product serving essential entities or critical infrastructure. The practical challenge is that AI Act Art.73, CRA Art.14, and NIS2 Art.23 impose materially different timelines, route to different national authorities, and require different content, while sharing a substantial common factual core.

The single-report strategy is not a platform but a discipline: one master incident record, multiple regulation-specific notifications, parallel submission with cross-referenced incident identifiers, and early disclosure of multi-regulation scope to facilitate inter-authority coordination. Providers who build this process before August 2, 2026 will be ready for both the AI Act enforcement window and the CRA Art.14 application date that follows six weeks later.

The next and final post in this series covers GPAI incident reporting readiness in full: internal playbook structure, escalation paths, NCA coordination protocols, and the complete pre-August checklist.

This post is part of the sota.io EU AI Act GPAI Incident Reporting Series. Post #1510 of 1511 in this series.