EU AI Act Article 73: CISO Incident Reporting Guide 2026

EU AI Act Article 73 serious incident reporting is live on August 2, 2026. Unlike the Annex III high-risk technical obligations, which were delayed to December 2, 2027 by the May 2026 Digital Omnibus agreement, Article 73 was not postponed. If your organization provides or deploys a high-risk AI system and a serious incident occurs after August 2, you have a mandatory reporting obligation to national market surveillance authorities with deadlines as short as two days.

Most of the Article 73 guidance published by law firms correctly identifies what the regulation says. What is missing is the operational layer: how a CISO translates three legal deadlines and a four-outcome definition into monitoring rules, escalation procedures, and a reporting workflow that works under time pressure. That is what this guide covers.

What Article 73 Actually Requires

Article 73 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems placed on the EU market to report serious incidents to the national market surveillance authority of the member state where the incident occurred. This is not a cybersecurity breach notification law. The reporting threshold is the outcome the incident produces, not the technical mechanism of the attack.

A serious incident under Article 73 is an incident or malfunction of a high-risk AI system that directly or indirectly leads to:

Death of a person, or serious harm to a person's health.

Serious and irreversible disruption of the management or operation of critical infrastructure.

Infringement of obligations under EU law intended to protect fundamental rights.

Serious damage to property or the environment.

"Malfunction" includes unintended outputs, failures to produce required outputs, and behavior that falls outside the system's intended purpose as documented in the technical documentation. An adversarial attack that causes the system to produce a harmful outcome is a malfunction under this definition, even if the system itself is not technically broken.

The official Article 73 text and EC guidance published in September 2025 clarify that providers can file an initial incomplete report at the deadline, with supplementary analysis to follow. This is critical for security teams: you file at the deadline even if investigation is ongoing, then supplement.

The Three Reporting Deadlines in Practice

The three-tier deadline structure is the hardest operational challenge. Time starts from when the provider (or deployer) becomes aware of the incident, not from when the incident occurred.

15-day deadline (default): Standard serious incidents involving harm to health, safety, or fundamental rights. This is the baseline for most AI incidents that meet the seriousness threshold. In practice, 15 days is not a long window when you factor in root cause analysis, legal review, technical documentation, and coordination with market surveillance authorities who may ask follow-up questions.

10-day deadline (death cases): If a death may have been caused by the AI system. The causal link does not need to be confirmed at the time of filing. If there is a reasonable likelihood of a link between the AI system's output or malfunction and a death, the 10-day deadline applies.

2-day deadline (widespread or critical infrastructure): For incidents that are widespread (affecting multiple users or causing systemic impact) or that constitute a serious and irreversible disruption to critical infrastructure management or operation. Two days from discovery to regulatory filing is an emergency response timeline. Any organization with systems in critical infrastructure categories needs an automated alert that triggers within hours of detection.

For all three tiers, the clock starts when the provider or deployer becomes aware of the potential link between the AI system and the serious outcome. A deployer who discovers a serious incident must notify the provider immediately (within 24 hours per the draft guidance). That 24-hour deployer-to-provider notification is effectively the start of the provider's 2-day window for infrastructure cases.

Who Is Obligated: Providers, Deployers, and Embedded AI

Providers carry the primary Article 73 reporting obligation. A provider is the entity that develops the high-risk AI system and places it on the EU market, whether under its own name or a third-party label. This includes non-EU companies if their system is used in the EU.

Deployers (organizations that put a provider's AI system to use in their own operations or for end users) are secondarily obligated. If a deployer identifies a serious incident, they must inform the provider immediately. If the provider fails to report, the deployer must file directly with authorities.

Embedded AI systems are where the obligation gets complex. If you embed a third-party AI component into your product, the entity controlling the AI function that caused the incident typically carries the Article 73 obligation. In practice, this means organizations integrating foundation models (via API) into high-risk applications should contractually require the model provider to notify them of any serious incident the model contributes to, and should maintain their own monitoring for serious outcomes that may result from model behavior in their application layer.

If your system qualifies as a high-risk AI system under Annex III categories including biometric identification, credit scoring, employment screening, medical triage tools, and law enforcement AI, Article 73 applies to you. The full Annex III list covers eight categories of high-risk use cases.

Mapping Security Incidents to Article 73 Thresholds

Security teams need a classification framework that maps the incidents they already detect to Article 73 reporting triggers. The key mental model: the regulation asks about outcomes, not attack vectors.

Incidents that may trigger Article 73 (outcome-dependent):

• Prompt injection on medical triage AI: If a prompt injection attack causes the system to misclassify a patient condition and that patient suffers serious health harm, Article 73 is triggered. The attack vector (prompt injection) is not what matters. The outcome (serious health harm to a person) is what triggers the obligation.
• Data poisoning on a credit scoring model: If poisoned training data causes the model to systematically deny credit to a protected group, this may constitute an infringement of fundamental rights (non-discrimination). Article 73 would apply.
• Model failure in a critical infrastructure safety AI: If a high-risk AI system providing safety oversight for an energy grid fails and causes disruption to grid management, the critical infrastructure outcome triggers the 2-day deadline.
• Adversarial example causing biometric misidentification: If an adversarial input causes a border control or law enforcement biometric system to misidentify a person in a way that results in wrongful detention, this implicates fundamental rights obligations.

Incidents that do not trigger Article 73 on their own:

• A prompt injection attack that is detected and blocked before producing a harmful output.
• A model accuracy degradation that does not result in a serious outcome.
• A data breach of AI training data where no high-risk system output caused harm.
• LLM hallucinations in a general-purpose AI system that does not qualify as high-risk under Annex III.

Your incident classification workflow should include a mandatory Article 73 screening gate: for every AI security incident detected, run through the outcome checklist. If the outcome could be death, serious health harm, critical infrastructure disruption, fundamental rights violation, or serious property damage, escalate immediately to the reporting workflow.

Article 73 and the Article 15 Cybersecurity Connection

Article 15 of the EU AI Act requires high-risk AI systems to achieve appropriate cybersecurity resilience. It specifically enumerates five attack categories that high-risk AI systems must be designed to withstand: data poisoning during training, model poisoning via pre-trained components, adversarial examples designed to cause incorrect outputs, confidentiality attacks targeting training data extraction, and systematic model flaws.

The connection to Article 73 is direct: a successful attack in any of these five categories against a high-risk AI system that produces a serious outcome requires Article 73 reporting. Article 15 is the prevention obligation. Article 73 is the disclosure obligation when prevention fails.

For CISOs, this means your cybersecurity testing program for high-risk AI systems should be explicitly mapped to these five categories, and your monitoring must be capable of detecting when a successful attack in any category has occurred. Our guide on AI security posture management covers the detection layer in detail.

DORA, NIS2, and MDR: Avoiding Double Reporting

A major concern for organizations in regulated sectors is simultaneous reporting obligations across multiple regimes, each with different timelines and regulatory recipients. The EU AI Act addresses this through a simplified procedure.

For organizations covered by sectoral law, the simplified procedure works as follows:

If your high-risk AI system operates in a sector with equivalent incident reporting obligations, including financial services under DORA, critical infrastructure under NIS2 or CER, and medical devices under EU MDR, then:

• Incidents causing harm to health, safety, or property: Report exclusively under the applicable sectoral law. Article 73 is not additionally required for these categories.
• Incidents involving fundamental rights violations: Article 73 applies in addition to sectoral reporting.

In practice, this means a bank using a high-risk AI credit scoring system that suffers a discrimination incident (fundamental rights) must report under Article 73. A malfunction causing financial harm would be handled under DORA. An incident touching both domains requires both reports.

The November 2025 Digital Omnibus proposal introduced a single incident reporting point concept intended to reduce this burden further. As of July 2026, this mechanism is not yet operational, so organizations should plan for parallel filings with appropriate cross-references.

The EC reporting template includes a field titled "Information about other incident obligations" specifically to document parallel sectoral reports. File this field on every Article 73 report involving a regulated sector.

SIEM Integration: Building Article 73 Detection Capability

Article 73 imposes a detection obligation as well as a reporting one. You cannot report within 2, 10, or 15 days if you do not know the incident occurred. CISOs need to instrument their high-risk AI systems with monitoring that can surface serious outcomes in time to meet the shortest applicable deadline.

Minimum monitoring requirements for Article 73 readiness:

AI-specific log collection: High-risk AI systems must generate audit logs under Article 12 of the EU AI Act. These logs should capture input/output pairs, confidence scores, user identifiers, timestamps, and system state. Feed these logs into your SIEM alongside your standard infrastructure logs.

Outcome-aware alerting rules: Configure alerts that detect serious outcomes, not just attack attempts. For a medical AI system, this means alerting on outputs that contradict clinical protocols. For a credit scoring system, this means statistical monitoring for demographic output disparities. For a critical infrastructure AI, this means output-to-action correlation that can detect decisions causing physical system state changes.

Anomaly detection on agent action chains: For agentic or automated high-risk AI systems where the system takes actions (not just provides outputs), monitor the action sequence for deviations from expected patterns. An autonomous AI taking an unexpected action in a critical infrastructure context may indicate a serious incident in progress.

Cross-reference with outcome data: In many high-risk AI deployment contexts, the outcome (harm to a patient, wrongful credit denial) may not be visible to the AI system operator. Set up data-sharing agreements or feedback loops with deployers so that serious outcomes can be correlated back to AI system outputs within reporting timeframes.

2-day deadline alert tier: Create a separate, high-priority alert tier for potential critical infrastructure incidents or widespread events. This tier should page on-call staff immediately, not wait for morning triage.

For SIEM platforms, label all high-risk AI system events with a tag that routes them through the Article 73 screening workflow. Your playbook should include a checklist that the analyst runs within the first hour of any high-risk AI incident alert.

The EC Reporting Template: What You Need to File

The European Commission's draft guidance published September 2025 includes a reporting template with five sections. Prepare template drafts in advance. Filing under time pressure with no template is the most common failure mode in regulatory reporting.

Section 1: Administrative information

• Notifying party (provider or deployer)
• Contact person for the market surveillance authority
• Date and time of incident discovery
• Estimated date of occurrence
• Member state(s) affected

Section 2: AI system data

• Name and description of the AI system
• Annex III category under which the system qualifies as high-risk
• Technical specification reference number and version
• EU AI Act database registration number (if applicable from August 2026)
• Whether the system is used in a sector covered by sectoral law (DORA, NIS2, MDR)

Section 3: Incident description

• Description of the incident or malfunction
• Type of serious outcome: health/safety harm, critical infrastructure disruption, fundamental rights violation, or property damage
• Number of people affected (or estimate)
• Geographic scope

Section 4: Preliminary analysis

• Initial assessment of the causal link between the AI system and the serious outcome
• Immediate corrective actions taken
• Status of investigation at time of filing
• Information about other incident obligations (parallel sectoral reports)

Section 5: Additional comments

• Any other information relevant to the investigation

Note that Sections 3 and 4 may be incomplete in an initial filing at the 2-day or 10-day deadline. The regulation and draft guidance explicitly permit this. File what you know, state what is still under investigation, and update.

Provider-Deployer Coordination Protocol

For organizations that both deploy AI systems built by third-party providers and are themselves providers of AI systems used by downstream deployers, a two-track protocol is needed.

As a deployer of third-party high-risk AI:

Establish contractual notification requirements with all high-risk AI providers. Require them to notify you within hours of any serious incident involving your deployment.

Maintain your own monitoring for serious outcomes in your deployment, independent of provider monitoring.

When you identify a serious incident: notify the provider in writing within 24 hours with full incident details. Record the notification timestamp.

If the provider does not confirm that they are filing within your assessment of the applicable deadline, file directly with the market surveillance authority yourself.

As a provider of high-risk AI to downstream deployers:

Contractually require deployers to notify you immediately (within 24 hours) of any serious incident.

Maintain a centralized incident intake function that receives and triages deployer notifications.

Upon receiving a deployer notification, start the Article 73 clock immediately.

Brief the compliance team within two hours of any notification that may qualify as a widespread or critical infrastructure incident.

Pre-August 2 Readiness Checklist

Even with the Annex III technical obligations delayed to December 2027, Article 73 is live on August 2. The minimum readiness requirement before that date:

1. Map your AI system inventory to Article 73 scope. Identify every AI system in production that qualifies as high-risk under Annex III. If you have not completed your AI asset inventory, start there. Our EU AI Act High-Risk Systems checklist covers classification.

2. Assign Article 73 incident ownership. Designate a named individual responsible for Article 73 reporting decisions. This should not be an undefined "legal team" or "compliance function." One person must own the decision to file, and they must be reachable at any hour for a potential 2-day filing.

3. Identify your national market surveillance authority. Each EU member state has designated a market surveillance authority for the AI Act. Know which authority you report to for each jurisdiction where your high-risk AI systems operate.

4. Pre-draft your reporting templates. Fill in the static sections of the EC reporting template for each of your high-risk AI systems. When an incident occurs, you complete only the incident-specific sections.

5. Configure your monitoring and alerting. As described above, instrument your high-risk AI systems with outcome-aware monitoring and create the Article 73 screening gate in your incident triage workflow.

6. Brief your incident response team. Run through a tabletop scenario using our AI incident response playbook as the base, with Article 73 reporting as an explicit phase. The first time your team practices filing under a 2-day deadline should not be during a real incident.

7. Document your provider-deployer coordination agreements. If you have third-party high-risk AI providers, confirm in writing that notification agreements are in place and tested before August 2.

Post-Incident Investigation Requirements

Article 73 reporting is not the end of the obligation. Following any serious incident report, providers must perform an investigation that includes a risk assessment of the incident and corrective action. The investigation should:

• Establish or confirm the causal link between the AI system and the serious outcome.
• Identify the root cause (attack, malfunction, design flaw, or data quality issue).
• Assess whether other users or deployments face the same risk.
• Document corrective actions taken or planned, including system updates, retraining, configuration changes, or deployment restrictions.
• Update technical documentation and post-market monitoring plans.
• Report investigation findings to the market surveillance authority.

The market surveillance authority may request additional information, require the provider to restrict or withdraw the system, or initiate their own investigation. Providers must cooperate with these requests. For organizations with systems across multiple EU jurisdictions, the AI Office in Brussels has a coordination role.

Why the Law Firms Alone Are Not Enough

Legal analyses from Taylor Wessing, Freshfields, Linklaters, and Hunton clarify the regulatory text accurately. What they do not provide is the security operations layer: the SIEM rules, the escalation runbook, the monitoring architecture, and the provider-deployer coordination protocol that translate a 2-day legal deadline into an operational capability.

The gap we consistently see in enterprise AI security programs is not ignorance of Article 73. It is organizations that know about the obligation but have not closed the detection-to-reporting workflow. Knowing you must report within 2 days is different from having a workflow that can produce a valid EC report within 2 days of a Sunday-night incident discovery.

Our AI security assessment process includes an Article 73 readiness review as part of the EU AI Act compliance module, covering monitoring coverage, reporting workflow maturity, and provider-deployer agreement completeness. For organizations operating in regulated sectors, we map the simplified procedure against your existing DORA or NIS2 reporting processes to identify gaps rather than create duplicate workflows.

Conclusion

EU AI Act Article 73 incident reporting is a security operations problem as much as a legal compliance problem. The 2-day deadline for widespread or critical infrastructure incidents is shorter than many organizations' standard breach notification workflows under GDPR. The detection requirements, classification framework, and reporting workflow need to be operational before an incident occurs.

The August 2, 2026 enforcement date is now. Organizations with high-risk AI systems in production need to complete their monitoring instrumentation, assign reporting ownership, pre-draft templates, and brief their incident response teams this week.

For a review of your current Article 73 readiness posture and a gap assessment against the EC reporting requirements, contact BeyondScale or start with a Securetom scan to understand your high-risk AI system attack surface.

Authoritative sources:

• EU AI Act Article 73, official text
• EC draft guidance and reporting template, September 2025
• Taylor Wessing: deep dive into Article 73 obligations
• ENISA: AI security and cybersecurity requirements under the EU AI Act