EU Incident Reporting 2026: AI Act Art.73 vs CRA Art.14 vs NIS2 Art.23
Post #1392 in the sota.io EU AI Act Compliance Series
If your SaaS product includes a high-risk AI feature, ships software with network connectivity, and provides managed services to EU customers — you might be subject to three different EU incident reporting regimes simultaneously, each with its own deadlines, recipients, and content requirements.
Missing any one deadline carries administrative fines up to €15 million (CRA), €10 million (NIS2), or €35 million (AI Act). Missing two at once is not impossible, and getting confused about which regime's clock started first is a real operational risk as August 2026 enforcement approaches.
This guide puts all three regimes in one place: EU AI Act Art.73, CRA Art.14, and NIS2 Art.23 — compared across every dimension that matters for your incident response team.
Why Three Separate Regimes Exist
The EU's sectoral regulatory model means each regulation was designed for a different risk domain:
- NIS2 (Directive 2022/2555) targets network and information security across essential and important entities — it protects infrastructure continuity
- CRA (Regulation 2024/2847) targets product security of software with digital elements — it protects users from insecure products
- EU AI Act (Regulation 2024/1689) targets AI system safety specifically — it protects individuals from AI-caused harm
Each regime's incident reporting requirements reflect these different purposes: NIS2 cares about service disruption to society, CRA cares about security vulnerabilities in products, and the AI Act cares about physical, psychological, or fundamental-rights harms caused by AI decisions.
The bad news: a single event in your system can simultaneously trigger all three.
At-a-Glance Comparison
| Dimension | EU AI Act Art.73 | CRA Art.14 | NIS2 Art.23 |
|---|---|---|---|
| Legal instrument | Regulation 2024/1689 | Regulation 2024/2847 | Directive 2022/2555 |
| Who must report | Providers of high-risk AI systems | Manufacturers of products with digital elements | Essential and important entities |
| What triggers it | Serious incident involving a high-risk AI system | Actively exploited vulnerability OR severe incident affecting security | Significant incident affecting services |
| First deadline | 15 days (general), 10 days (death), 2 days (critical infra/widespread) | 24 hours early warning | 24 hours early warning |
| Second deadline | — | 72 hours substantive notification | 72 hours full incident notification |
| Final deadline | (included in initial report) | 14 days (vulnerability) / 1 month (incident) | 1 month |
| Report goes to | NCA (national market surveillance authority) | CSIRT coordinator + ENISA via Art.16 platform | CSIRT / national competent authority |
| Fines (max) | €35M or 7% turnover (Art.99) | €15M or 2.5% turnover (Art.64) | €10M or 2% turnover (Art.34) |
| In force from | 2026-08-02 | Art.14: 2026-09-11 | Already (transposition Oct 2024) |
EU AI Act Art.73 — Serious Incident Reporting
Who It Covers
Art.73 applies to providers of high-risk AI systems listed in Annex III (biometric systems, critical infrastructure AI, employment AI, credit scoring, migration/asylum AI, justice administration AI, essential services AI). Deployers are typically not directly obligated to report to authorities — but they must notify their provider when they become aware of a serious incident.
If your SaaS product includes any Annex III functionality, you are a provider under Art.73.
What Counts as a "Serious Incident"
Post #1389 in this series covers this in full, but the key test: the AI system's output was a contributing cause (not necessarily the sole cause) of:
- Death or serious personal injury
- Serious damage to property or the environment
- Serious harm to fundamental rights
- Serious disruption of critical infrastructure, public safety, or public order
The causal chain must run through the AI system — a coincidental failure elsewhere that happens alongside an AI decision does not trigger Art.73.
The Three Deadlines
Art.73 uses calendar days, not hours — this surprises most teams:
| Deadline | Scenario | Calculation |
|---|---|---|
| 2 days | Widespread incidents; serious incidents affecting critical infrastructure (Art.73(3)) | From when provider becomes aware |
| 10 days | Incidents involving death (Art.73(4)) | From when provider becomes aware |
| 15 days | All other qualifying serious incidents (Art.73(2)) | From when provider becomes aware |
The "from when the provider becomes aware" formulation means your internal monitoring and escalation process determines when the clock starts. Document awareness timestamps.
Where to Report
Reports go to the national market surveillance authority (NCA) in the member state where the incident occurred. For incidents crossing multiple member states, the NCA where the AI system was first placed on the market coordinates. The European AI Office receives copies for GPAI models.
CRA Art.14 — Manufacturer Reporting Obligations
Who It Covers
CRA Art.14 applies to manufacturers of products with digital elements — which includes software sold as a standalone product or embedded in hardware if it has network connectivity or interfaces. Most SaaS companies shipping client-side software, SDKs, or APIs fall within scope.
Critical timing: while the CRA entered into force December 2024, Art.14 specifically applies from 11 September 2026 (Article 71). You have a short runway between August 2 (AI Act enforcement) and September 11 (CRA Art.14 enforcement) to get both programs running.
Two Separate Triggers
CRA Art.14 has two distinct reporting triggers that run on different clocks:
Trigger 1 — Actively exploited vulnerability:
- You discover a security vulnerability in your product that is being actively exploited in the wild
- Clock starts: when you become aware of active exploitation
Trigger 2 — Severe incident affecting security:
- An incident severely impacts your product's security (availability, integrity, confidentiality) with potential cross-border or sector-wide effects
- Clock starts: when you become aware of the incident
The Three-Step Process
Both triggers follow the same three-step reporting structure:
| Step | Timing | Content |
|---|---|---|
| Early warning | Within 24 hours | Alert: vulnerability identified / incident detected, actively exploited or severely impacting. Minimal detail required — this is a heads-up, not a full report |
| Notification | Within 72 hours | Substantive: product identification, nature of vulnerability/incident, preliminary assessment, any mitigations deployed or in progress |
| Final report | Vulnerabilities: 14 days after notification. Incidents: 1 month after notification | Full analysis: root cause, impact scope, remediation steps completed, prevention measures |
Where to Report
Reports go through the single reporting platform operated by ENISA (established under CRA Art.16), addressed to the CSIRT designated as coordinator for your sector/geography. ENISA also receives a copy. The single platform model is designed to avoid duplicative reporting — one submission routes to all relevant authorities.
NIS2 Art.23 — Reporting Obligations
Who It Covers
NIS2 Art.23 applies to essential entities and important entities as classified in Annex I and Annex II. For SaaS companies, the most common triggers are:
- Managed service providers (MSPs, managed security service providers) — essential or important depending on size
- Cloud computing service providers — essential entities
- Data centre service providers — essential entities
- DNS service providers, TLD registries — essential entities
If your SaaS provides infrastructure or managed services to other businesses, you may be classified as an important or essential entity under national law transposing NIS2. This was due October 2024 — check your classification with your national authority.
What Triggers Reporting
A "significant incident" under Art.23 is one that causes or can cause:
- Severe operational disruption of the services provided
- Financial loss for the entity
- Considerable material or non-material damage for service recipients
The threshold is calibrated to business-continuity disruption, not individual user harm — this is how NIS2 differs from the AI Act (individual harm) and CRA (product security).
The Four-Step Process
NIS2 Art.23(4) establishes four report stages:
| Step | Article | Timing | Content |
|---|---|---|---|
| Early warning | Art.23(4)(a) | Within 24 hours of awareness | Has a significant incident occurred? Yes/No. Was it malicious? Cross-border impact suspected? |
| Incident notification | Art.23(4)(b) | Within 72 hours of awareness | Full incident assessment: nature, impact scope, severity indicators, preliminary causes, mitigations applied |
| Intermediate report | Art.23(4)(c) | On request from CSIRT or authority | Status update — no fixed deadline, responds to authority inquiry |
| Final report | Art.23(4)(d) | Within 1 month of Art.23(4)(b) submission | Full post-incident: root cause analysis, detailed measures taken, cross-border impact assessment |
One important nuance: for trust service providers, the 72-hour notification is compressed to 24 hours (Art.23(4)(b) in fine).
Where to Report
Reports go to the CSIRT designated for your sector under national law (e.g., BSI in Germany, ANSSI in France, NCSC-NL in the Netherlands) and/or the national competent authority (which may be the same body). The reporting authority varies by member state — check your national NIS2 transposition law.
When All Three Regimes Apply Simultaneously
This is the critical operational scenario. Consider a SaaS company that:
- Provides an AI-powered credit-scoring feature (Annex III high-risk AI → AI Act Art.73)
- Ships a JavaScript SDK to client websites (product with digital elements → CRA Art.14)
- Is classified as a managed service provider under NIS2 (important entity → NIS2 Art.23)
Scenario: A zero-day vulnerability in the SDK is actively exploited, and the resulting incorrect credit scores lead to loan denials for a protected class (fundamental rights harm). The exploitation causes major service disruption.
All three clocks start simultaneously:
| Regime | First Deadline | What You Must Send | To Whom |
|---|---|---|---|
| CRA Art.14 | 24 hours | Early warning: vulnerability + active exploitation | CSIRT via ENISA Art.16 platform |
| NIS2 Art.23 | 24 hours | Early warning: significant incident + service disruption | National CSIRT / NCA |
| AI Act Art.73 | 15 days (or 10 if deaths, 2 if critical infra) | Serious incident report: fundamental rights harm | National NCA / market surveillance authority |
The 24-hour deadline arrives before your incident is fully understood. You are legally required to send preliminary reports to two different authority systems before you finish the root cause analysis.
Five Overlap Scenarios
| Scenario | AI Act Art.73 | CRA Art.14 | NIS2 Art.23 | Action |
|---|---|---|---|---|
| AI system outputs harm, no technical vulnerability | ✅ Yes | ❌ No | Possibly (if widespread service disruption) | Art.73 report, check NIS2 scope |
| SDK vulnerability, no AI involved, no service disruption | ❌ No | ✅ Yes | ❌ No | CRA Art.14 report only |
| Service outage, no AI, no product vulnerability | ❌ No | ❌ No | ✅ Yes | NIS2 Art.23 only |
| AI vulnerability actively exploited + harm | ✅ Yes | ✅ Yes | Possibly | CRA (24h) + AI Act (15 days) + check NIS2 |
| Ransomware hitting AI SaaS MSP | ✅ If AI harm | ✅ Yes (severe incident) | ✅ Yes | All three — 24h + 24h + 15-day deadlines |
Decision Tree: Which Regime(s) Apply?
START: You have an incident
│
├─ Is your product a "product with digital elements" (software with network connectivity)?
│ └─ YES → Does this involve an actively exploited vulnerability OR severe security impact?
│ └─ YES → CRA Art.14 applies → 24h early warning to CSIRT via ENISA platform
│
├─ Does your SaaS provide managed services / cloud / infrastructure (NIS2 Annex I/II)?
│ └─ YES → Does this cause operational disruption or financial damage at scale?
│ └─ YES → NIS2 Art.23 applies → 24h early warning to national CSIRT
│
└─ Does your product include a high-risk AI system (AI Act Annex III)?
└─ YES → Did the AI system output contribute causally to harm or disruption?
└─ YES → AI Act Art.73 applies → 15 days (or 10/2) to national NCA
When multiple paths answer YES, all applicable regimes must be reported independently. There is no consolidated reporting mechanism across all three (yet).
Building One Incident Response Process That Satisfies All Three
The practical approach is not to run three parallel response programs — that creates confusion and increases the chance of missing a deadline. Instead, build a single escalation process that checks all three regimes at each stage.
Stage 0: Awareness (Hour 0)
When an incident is detected, immediately log:
- Timestamp of awareness (this starts all clocks)
- Service affected (which product, which component)
- Preliminary harm type (availability / integrity / confidentiality / user harm / AI output harm)
Stage 1: Triage (Hour 0–2)
Check the three-regime checklist:
| Check | Answer | Implication |
|---|---|---|
| Is there an AI Annex III component involved? | Y/N | AI Act Art.73 clock may be running |
| Is there a network-connected software product involved? | Y/N | CRA Art.14 clock may be running |
| Are you an NIS2-classified entity? | Y/N | NIS2 Art.23 clock may be running |
| Is there active exploitation of a vulnerability? | Y/N | CRA Art.14 24h deadline confirmed |
| Is there operational disruption affecting service recipients? | Y/N | NIS2 Art.23 24h deadline confirmed |
| Is there user harm or fundamental-rights impact? | Y/N | AI Act Art.73 15-day clock confirmed |
Stage 2: Parallel Early Warnings (Hour 2–22)
For any regime with a 24-hour trigger confirmed in triage, prepare and send early warnings before Hour 22 (buffer for drafting/review):
- CRA Art.14: Brief notification to CSIRT coordinator via ENISA Art.16 platform — product name, nature of exploitation/incident, "formal notification to follow within 72 hours"
- NIS2 Art.23: Early warning to national CSIRT — service affected, estimated scope, "full incident notification to follow within 72 hours"
These are deliberately minimal — the regulation requires timely notice, not a complete analysis.
Stage 3: Full Notifications (Hour 22–70)
Send substantive notifications before Hour 70 (buffer before 72-hour deadline):
- CRA Art.14: Product identification, CVE if applicable, exploitation details, preliminary impact assessment, mitigations deployed
- NIS2 Art.23: Full incident assessment per Art.23(4)(b) fields
Stage 4: AI Act Report (Day 2–14)
For AI Act Art.73 incidents, you have more time but need more detail:
- Document the causal chain from AI output to harm
- Identify the AI system precisely (version, deployment scope, Annex III category)
- Assess whether this is a systematic failure or a one-off edge case
- Describe corrective actions taken or planned
- Confirm the incident is isolated or still evolving
Submit to your national NCA before Day 14 (buffer before Day 15 deadline, or Day 9/Day 1 for the accelerated tracks).
Stage 5: Final Reports
All three regimes require final reports. Stagger them:
| Report | Deadline | Key Content |
|---|---|---|
| CRA Art.14 final (vulnerability) | Day 14 after 72h notification | Root cause, full remediation, SBOM update if relevant |
| CRA Art.14 final (incident) | Month 1 after 72h notification | Root cause, impact scope, prevention measures |
| NIS2 Art.23 final | Month 1 after 72h notification | Full post-incident analysis, cross-border impact |
| AI Act Art.73 (if ongoing) | Ongoing updates to NCA | Status of corrective action, recurrence prevention |
Common Mistakes to Avoid
Confusing deadlines across regimes. AI Act Art.73 deadlines are in days (not hours). NIS2 and CRA deadlines are in hours for the first two steps. Using the wrong unit causes missed deadlines.
Treating the 24-hour early warning as optional. Both CRA Art.14 and NIS2 Art.23 require a 24-hour early warning even when you don't have full information. "We're still investigating" is a valid state for an early warning — the point is to put authorities on notice.
Reporting to the wrong authority for CRA. CRA Art.14 reports go through the ENISA Art.16 single platform, addressed to your sector's CSIRT coordinator. Do not report directly to your national NCA for CRA incidents — the routing goes via ENISA.
Forgetting the deployer-provider split for AI Act. If you are a deployer (not provider) of a high-risk AI system and you observe a serious incident, you must notify your provider — you don't typically report directly to the NCA. But you should have a contractual mechanism with your AI vendor to make sure they report within the mandatory window.
Missing the Art.14 enforcement date. CRA Art.14 applies from 11 September 2026, not the same date as the AI Act (2 August 2026). You have 40 days between the two enforcement dates to build your CRA reporting process after the AI Act goes live.
Key Dates Summary
| Date | Event |
|---|---|
| October 2024 | NIS2 national transposition deadline — NIS2 Art.23 already applies |
| 11 June 2026 | CRA Chapter IV (notified bodies for conformity assessment) applies |
| 2 August 2026 | EU AI Act full enforcement begins — Art.73 reporting live |
| 11 September 2026 | CRA Art.14 reporting obligations apply — vulnerability + incident reporting |
| 11 December 2027 | CRA full application (all manufacturer obligations) |
What to Do Now
If NIS2 applies to you (already):
- Verify your classification (essential vs important entity) with your national NCA
- Ensure your CSIRT reporting contact is documented and tested
- Run a tabletop exercise: can your team produce a 24-hour early warning within 2 hours of awareness?
For August 2 (AI Act):
- Map which of your product features fall under Annex III high-risk categories
- Build an Art.73 reporting template (see Post #1391 in this series)
- Document your NCA contact and preferred submission channel
- Define "awareness" internally — when does the clock start?
For September 11 (CRA Art.14):
- Identify all products with digital elements with network connectivity
- Register with the ENISA Art.16 single reporting platform when it opens
- Build your CSIRT coordinator contact list (varies by member state and sector)
- Draft your 24-hour early warning template — brevity is intentional
For the overlap scenario:
- Ensure your incident response runbook includes a three-regime triage at Hour 0
- Assign dedicated owners for each reporting stream (one person handling all three simultaneously is a recipe for missed deadlines)
- Pre-draft minimal early warning templates for CRA and NIS2 so the 24-hour window is achievable
Next in This Series
Post #5/5 (final): EU AI Act Art.73 Incident Response Toolkit — templates, runbooks, authority contact directory, and a JIRA/Linear incident workflow you can deploy in under a day.
This post is part of the EU AI Act Incident Reporting Operations 2026 series. All article citations verified against primary sources: EUR-Lex CELEX 32024R1689 (AI Act), 32024R2847 (CRA), 32022L2555 (NIS2).
Deadlines and enforcement dates accurate as of 2026-05-30. AI Act full enforcement: 2 August 2026. CRA Art.14 enforcement: 11 September 2026.
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.