Article 73 serious incident reporting: requirements

What Article 73 serious incident reporting asks providers to do

Article 73 requires a provider of a high-risk AI system to report a serious incident to the market surveillance authorities within fixed deadlines, and to investigate and take corrective action without altering the system in a way that could hide the causes. The duty exists because harm can spread quickly when the provider does not know about it. A system that produces unsafe outputs, misclassifies people at scale or disrupts a service can affect health, safety, fundamental rights or critical infrastructure before anyone outside the provider's team is aware. The obligation runs from the moment the clock starts, whether or not a fix is ready. Teams should decide in advance who can declare an incident, who assesses causality and who speaks to the authority.

The work is hard for three reasons. First, a serious incident is a defined term in the Act, so deciding whether an event meets it requires legal and technical judgment about the harm caused. Second, the 15-day period runs from the moment the provider becomes aware of the incident, and the report is due immediately after a causal link to the system, or its reasonable likelihood, is established. The timeline of the investigation therefore needs to be documented from the first alert. Third, the fastest fix is often a change to the system, while Article 73(6) asks the provider to avoid changes that could affect the evaluation of causes before the authorities are informed. Teams should agree in advance how they will preserve models, configurations, logs and data before any patch is deployed, and how interim containment steps are recorded.

The Commission published draft Article 73 guidance and a draft incident report template for consultation on 26 September 2025, with feedback accepted until 7 November 2025. Treat both as drafts. Before relying on them in a runbook, confirm the final text, any changes to the template and whether the AI Office reporting route under Article 75(1a) applies to your system. Legal counsel should also confirm whether a sectoral reporting regime limits your notifications to fundamental rights infringements under Article 73(9) and (10). Build the runbook so that a change in the final guidance updates a template and a contact list, not the whole incident process. The Commission consultation page is the natural starting point for tracking that status.

Which providers, systems and incidents fall under Article 73

Scope decisions set who must report, to which authority and on what clock. Before you scope, check the definition of serious incident against the text of Article 3, because every card below depends on that wording.

Non-EU providers under Article 2

Article 2 reaches providers established outside the EU when they place a high-risk system on the EU market, and when the output of their system is used in the EU. A provider in that position owes Article 73 reporting to the relevant market surveillance authority, so the duty does not depend on where the company or its servers sit. Map each system to its EU placement and to where its output is used before assuming the duty is absent. Confirm with counsel which authority receives each report.

Annex III systems from December 2027

Most high-risk systems listed in Annex III become subject to the high-risk rules on the date set by the 2026 amendment, which moved it from August 2026. The serious incident duty attaches to providers of these systems once those rules apply, so a system inventory tagged by Annex III category and placement date sets your reporting start point. Check how the amended Act treats systems already on the market before that date, and confirm the answer against the consolidated text.

Annex I product systems from August 2028

Systems that are safety components of products covered by Annex I legislation, such as medical devices or machinery, follow a later application date under the amended Act. Reporting then sits alongside the sectoral conformity and market surveillance rules for that product, so the product compliance team and the AI team should share one incident log. Identify which Annex I legislation applies to each product and which authority already receives its incident reports.

AI Office supervised systems

Under Article 75(1) as amended in 2026, the AI Office is exclusively competent for AI systems built on a provider's own general-purpose model and for AI in very large online platforms and search engines. Providers of high-risk systems in that group report serious incidents to the AI Office under Article 75(1a) instead of a national authority. Check whether your system runs on your own model or on an in-scope platform, because that answer changes the recipient of every report.

Equivalent Union reporting regimes

Article 73(9) and (10) limit notification to infringements of fundamental rights obligations for providers under equivalent Union reporting regimes, and for medical devices under Regulations (EU) 2017/745 and 2017/746. The limit narrows the Article 73 duty only, so other obligations under the sectoral regime may still apply. Confirm which regimes count as equivalent, and map the remaining sectoral reporting duties before you drop any incident from the Article 73 workflow.

Deployer duty to inform providers

Deployers who identify a possible serious incident involving a high-risk system they operate must inform the provider, which then assesses the event and decides on reporting. Set up a route from operations, security and business users to the provider's contact, and record when the deployer first noticed the event. Confirm the deployer's notice duty in the Article 73 and Article 26 text, then agree the channel and response expectations in the contract.

When the reporting clock starts and which deadline applies

The clock starts when the provider becomes aware of the incident, but awareness alone does not trigger reporting. The report is due once the provider has established a causal link between the high-risk system and the incident, or the reasonable likelihood of one. That makes the awareness point a documented decision. Keep a written incident record that captures when the first signal reached the organization, who triaged it, when the causal question was assessed and who approved the conclusion. Market surveillance authorities will look at these timestamps first, so the record should be written as events unfold, not reconstructed afterward.

The general deadline is 15 days after awareness. Two shorter deadlines apply to specific events: 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure, and 10 days where the incident involves a death. The shortest applicable deadline governs, so the first triage question is whether the event fits one of the shorter categories. Map each incident class in your procedure to a deadline before an incident occurs, and name the person who makes the classification. The 15-day period is an outer limit. Article 73 also requires reporting immediately once the causal link is established, so the full period should not be treated as the working target.

Article 73(5) allows an incomplete initial report to be followed by a complete one, so the first filing can go in on time with the facts known at that point. Design a two-stage template: the initial report covers identification, the affected system, the date of awareness, the suspected causal link and the immediate corrective step, while the follow-up covers root cause and investigation status. Confirm the exact wording of Article 73(1) to (5) in the consolidated Article 73 text before building the procedure, and check whether the Commission's draft guidance and template, published for consultation on 26 September 2025, have been finalized.

How an assessor tests Article 73 compliance

This table compares each area an assessor samples under Article 73, the test approach, the evidence requested and the findings that recur. Read it as a sampling plan: pick a set of incidents, then walk each one through the procedure, the clocks and the investigation record. The main takeaway is that the awareness date and the evidence capture order are where most files fail.

Test area	Test approach and evidence requested	Common findings
Written incident procedure and triggers	Review the procedure for defined serious incident triggers, named owners, escalation paths and the link to the causal-link test. Ask for the approved version and its revision history.	Procedure omits the causal-link or reasonable-likelihood test, or names no owner for the reporting decision.
Awareness and classification record	Sample incidents and check for a dated record of when the provider became aware, who classified the event and why it met the serious incident definition.	No record of the awareness date, so the 15, 10 and 2 day clocks cannot be verified.
Timeliness against 15, 10 and 2 day deadlines	Recalculate each deadline from the awareness date, then compare with submission timestamps. Confirm which deadline applies to each sampled event.	Clocks started late, or the wrong deadline was applied to a death, a widespread infringement or critical infrastructure disruption.
Initial and complete reports	Check that initial reports were filed on time and that any later complete report followed the initial one. Ask for the submission receipt or authority acknowledgement.	Initial report filed without a follow-up plan, or no proof of submission kept in the file.
Investigation and root cause record	Review the investigation file for the risk assessment, the causal analysis, the timeline and the people involved. Confirm the record is dated and versioned.	Root cause stated without supporting evidence, or investigation notes edited after the fact without version history.
Evidence preservation and no alteration	Ask for logs, snapshots or hashes showing evidence was captured before any change. Compare the change record with the incident timeline to see whether the system was altered before causes were recorded.	Fixes deployed before evidence was captured, so the cause analysis can no longer be reproduced.
Corrective action records	Trace each corrective action to a root cause and a verification step. Check that actions were approved, tracked to closure and reported where required.	Corrective actions logged without a link to the cause, or closed with no verification.
AI Office routing for Article 75(1) systems	For systems supervised by the AI Office, confirm the routing rule in the procedure and check that sampled reports went to the AI Office rather than a national authority.	Reports sent to the national authority by default, with no routing check in the procedure.

How to build an Article 73 reporting procedure

This sequence turns Article 73 into a working procedure: who decides a serious incident has occurred, how the clock starts, how the investigation preserves evidence, and how the report reaches the right authority before each deadline.

Define serious incident criteria and clocks
Write a short criteria document that maps the Article 3 definition of a serious incident to your own system types, failure modes and customer impact. Next, list the Article 73 deadlines that apply to each category: 15 days as the general period, 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure, and 10 days where a death is involved. Confirm with counsel which sectoral reporting regime, if any, applies to you. The output is an approved criteria sheet with a deadline table that engineering and support can apply without interpretation.
Set up detection and intake channels
Connect the sources that can reveal an incident: production monitoring and alerts for the high-risk system, support tickets, customer and deployer notifications, and reports from employees or researchers. Give every channel one intake point, such as a dedicated queue in your case management tool, and require a timestamp and source on each entry. Deployer contracts should require deployers to forward suspected incidents to you quickly. The output is a documented intake map and a test entry that shows each channel reaches the queue.
Assign the awareness and classification decision
Name one accountable owner for the decision that you are aware of a serious incident, with a named deputy, and record the moment that awareness begins. The owner classifies each intake against the criteria sheet, decides whether a causal link or its reasonable likelihood exists, and documents the reasons, including decisions not to report. Because the deadlines run from awareness, the owner must be reachable outside business hours. The output is a classification record with timestamp, reasoning and approver for every case.
Prepare initial and complete report templates
Build two templates based on the Commission's draft incident report template published for consultation on 26 September 2025: an initial report that captures what is known at the first deadline, and a complete report that covers root cause, affected persons, corrective measures and risk assessment. Mark fields that may be incomplete at the initial stage, since Article 73(5) allows a complete report to follow. Track the template against the Commission's final guidance, which may change field definitions, and review the templates when that guidance is adopted. The output is versioned templates with an owner and a review date.
Run the investigation with an evidence freeze
Open a case for each classified incident and collect logs, configuration snapshots, model versions, data samples and communications before anything changes. Record a hash and chain-of-custody entry for each artifact. Only after the evidence is frozen may the team roll back, patch or retrain, and any change must be logged with the reason. Article 73(6) requires investigation and risk assessment without altering the system in a way that could affect evaluation of the causes before the authorities are informed. Tooling such as DFIR-IRIS can hold the case, timeline and evidence records. The output is a sealed evidence set and a timeline that can be shown to an authority.
Define corrective action and approval path
Set out who may approve a corrective action, what evidence must support it, and how it is recorded in the quality management system and the post-market monitoring file. Distinguish containment steps that keep people safe from fixes that change the system, and require the second approver to confirm that any change is documented against the evidence freeze. Where a corrective action affects conformity, link it to the procedures for non-conforming systems. The output is an approval matrix and a corrective action record template that closes each incident.
Route reports to the correct authority
Determine the recipient for each report before an incident occurs. In most cases the national market surveillance authority receives the report. Since the 2026 amendment, providers of high-risk systems supervised by the AI Office under Article 75(1) report serious incidents to the AI Office under Article 75(1a). Check whether a sectoral reporting regime or the medical device route in Article 73(9) and (10) limits your duty to fundamental rights infringements. Keep a contact register and a submission log with confirmation receipts. The output is a routing decision tree signed off by counsel.
Run a tabletop exercise against each deadline
Simulate at least one incident for each deadline category: a standard case, a widespread infringement, a critical infrastructure disruption and a death. Time the steps from intake to classification, initial report and complete report against the 15, 2 and 10 day periods, and record gaps in staffing, templates and routing. Repeat the exercise after each change to the templates, the Commission's final guidance or the authority contacts. The output is an exercise report with findings, owners and dates for fixes.

Investigating without altering the evidence

Article 73(6) asks a provider to do two things at once: investigate the incident, assess the risk and take corrective action, while not altering the high-risk system in a way that could affect the evaluation of the causes before the authorities have been informed. The practical answer is to preserve first, then contain. Before any patch, rollback or configuration change, capture the state of the system as it was when the incident occurred. That means the deployed model version and its weights reference, the system configuration, the data pipelines and retrieval sources in use, the prompts and system instructions, and the relevant logs. Record a hash for each artefact and store the copies in a location the engineering team cannot silently overwrite. Document who accessed each artefact, when, and for what purpose, so that the investigation trail can be explained to a market surveillance authority later.

Containment changes are sometimes unavoidable, for example to stop ongoing harm to people or to block a faulty output path. When that happens, the provider should write down why the change was needed, what alternatives were considered, who approved it, and what state the system was left in. Keep the change narrow and reversible, and run the investigation against the preserved snapshot rather than the live system. Confirm internally whether your change control process and incident procedure already define this decision point, and whether the people authorised to approve an emergency change are named in advance.

The logs the system generates are governed by Article 19, not only by the incident procedure. Article 19 requires providers of high-risk systems to keep automatically generated logs for at least six months where those logs are under their control, subject to sectoral rules and the financial-sector alternative. Confirm that log retention periods are set to meet Article 19 and that the incident investigation does not shorten or rotate away the evidence needed to answer an authority request under Article 21. Open-source components can help produce these records. For example, Nextcloud's admin_audit app can write additional event information to audit.log, and OpenBao audit devices keep JSON records of API requests and responses, with most sensitive values hashed. Check each component's retention and integrity settings in your own environment, and confirm them with the vendor or documentation before relying on them as evidence.

Evidence that shows an incident was reported on time

Article 73 deadlines run from the moment the provider becomes aware of an incident, so the evidence has to show when that awareness began, how the incident was classified, and what was submitted and when. The six artifacts below connect those points into one record that an authority or assessor can follow. Each should be reviewed on a schedule between assessments, not rebuilt when an incident occurs.

Incident register with awareness timestamps

The register lists every potential serious incident involving a high-risk system, with the date and time the organization first became aware of it. Article 73 counts its deadlines from that point, so the timestamp is the most important field in the record. Check that the register captures awareness separately from the date the incident occurred, that entries are not backdated, and that the person who logged each entry is recorded. Hold a standing review of open register entries so no incident sits unassessed.

Classification record and deadline reasoning

For each incident, a written classification shows whether it meets the serious incident definition, whether a causal link or its reasonable likelihood is established, and which deadline applies: 15 days, 10 days for a death, or 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure. An assessor will ask why a particular deadline was chosen and when that decision was made. Record the decision maker, the date of each reclassification, and the facts that drove the choice.

Initial and complete report copies with receipts

Keep a copy of every report sent to the market surveillance authority, including the initial report and any later complete report. Article 73 allows an incomplete initial report to be followed by a complete one, so the file should show what was known at each submission and what was added later. Store the submission receipt or confirmation alongside each copy with its date and time. Confirm with your national authority which channel it accepts and whether reports for AI Office-supervised systems follow a different route.

Investigation case file with timeline and assets

The investigation case file joins the facts gathered during the Article 73(6) investigation: the affected system and its components, the data and users involved, the consolidated timeline of events, and the tasks assigned to each responder. DFIR-IRIS keeps each case as a single record of assets, indicators of compromise, tasks and evidence, with a full audit trail of who changed what. Use the audit trail to show that the investigation ran alongside the reporting clock. Pair it with Nextcloud or OpenBao audit logs where those systems are in scope.

Chain of custody and hash records

Article 73(6) asks the provider not to alter the system in ways that could affect the evaluation of causes before informing the authorities. Preserved logs, model artifacts and configuration snapshots need a chain of custody showing who collected each item, when, and where it is stored. DFIR-IRIS logs evidence with SHA-256 verification, so each item can be checked against its recorded hash later. Confirm that hashes are recomputed on access and that any change to the system after the incident is documented as a corrective step.

Corrective action and post-incident review

Corrective action closes the incident and shows the authority that the risk was addressed. The record should link each corrective measure to the root cause found in the investigation, the owner, the verification step and the closure date. A post-incident review then asks whether the detection, classification and reporting steps worked within the deadline applied. Run tabletop exercises on the reporting process between audits, at an interval the organization sets and can sustain, and file the lessons learned with the incident record.

What meeting Article 73 costs in money and effort

This table lists the cost components of running serious incident reporting under Article 73, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read it as a checklist for building a quote: the software line is often the smallest, while staffing and integration usually decide the total.

Cost component	One-time or recurring	What drives it and how to keep it down
Procedure design and legal review	One-time, with periodic review	Number of AI systems in scope, how many reporting routes apply (national authority or AI Office), and whether sectoral carve-outs are involved. Reuse an existing incident procedure and ask counsel to review only the Article 73 deadlines and triggers.
Detection and intake integration	One-time build, recurring upkeep	Number of log sources feeding alerts and how many systems raise them. Start with the high-risk systems in scope and connect existing SIEM or monitoring feeds before adding new sources.
Investigation tooling (for example, DFIR-IRIS under LGPL-3.0-or-later)	Licence is zero for open source; hosting, setup and upkeep are recurring	Hosting in your own infrastructure, backup, access control and upgrades. The license removes license spend, but you still pay for installation, integration and maintenance. Confirm current licence terms with the project before adoption.
Staff time for on-call triage and reporting	Recurring	Hours needed to classify an incident against the Article 73 triggers and draft the initial and complete reports within the deadlines. Cross-train legal, product and security staff so the process does not depend on one person.
Tabletop exercises	Recurring, usually annual or after major change	Number of scenarios (for example, a widespread infringement or a death), number of participants, and whether an outside facilitator runs them. Internal facilitation lowers cost but may miss gaps an outside view would catch.
External incident response or forensic support	Retainer or per-incident, depending on the contract	Retainer size, response time commitments and the complexity of the incident. Ask for the scope of support in writing, and confirm whether the provider can work inside your environment without altering evidence.
Auditor sampling of incident files	Recurring, at each audit cycle	Number of incidents in the period and the completeness of case records, timelines and evidence logs. Keep one consistent record per incident so sampling takes less time.

Who owns the reporting duty, who can help and who must stay independent

Under Article 73, the provider is the party that must report a serious incident to the market surveillance authority. That duty cannot be handed to a consultant or a vendor by default. Your team decides whether an event meets the definition, records when it became aware of it, starts the clock for the 15, 10 or 2 day deadline, files the initial and any complete report, and carries out the investigation and corrective action.

Classification decision: A named role, such as the head of AI governance or the security lead, decides whether an event is a serious incident and documents the reasoning.
Awareness record: Keep a timestamped log of when the organization first became aware of the event, since the deadline runs from that point.
Filing and accountability: Your legal or compliance function signs and submits the report, and remains answerable to the authority for its content.
Investigation and corrective action: Engineering owns root cause analysis, risk assessment and fixes, without altering the system in a way that hides the cause.
Escalation rules: Agree in advance who must be contacted at any hour, including product owners and any deployer customers.

Before relying on this split, confirm with counsel which deadline applies to your system and which authority is competent for it.

Questions buyers ask about Article 73 reporting

How much effort and cost does an Article 73 reporting procedure take?

Most of the cost is internal staff time, because the provider owns the incident decision, the investigation and the report. Costs come from four components: time to define triggers and roles, time to build the reporting workflow and templates, tooling for case management and evidence handling, and recurring time for exercises and updates when the system or the guidance changes. Cost rises with the number of high-risk systems, the number of teams that touch them, and whether incidents must be traced across suppliers. The Act sets fines of up to EUR 15 million or 3% of worldwide annual turnover for most operator obligations, which is the exposure a procedure is meant to limit. Ask any quote to separate one-time build work from recurring exercise and retainer work, and to state which systems and teams are in scope.

How long does it take to build a serious incident reporting procedure?

The duration depends on scope and must be quoted from a written scope, because no reliable figure applies across organizations. The main drivers are the number of high-risk systems in scope, how many of them already log events and keep audit trails, how many suppliers and deployers must be coordinated, and whether the team has an incident response process to extend. Deadlines of 15, 10 and 2 days apply once a serious incident is identified, so the procedure must exist before a live event. Ask for a phased plan with the decision points, the named deliverables and the handover of templates and case records.

Can a small team run serious incident reporting in-house?

A small team can run it in-house if it has a clear owner, a written trigger definition and a tested path to the authority. The work is mostly decision-making and record keeping rather than heavy engineering. The team needs one person to own the reporting decision, a backup who can act within the short deadlines, and a way to preserve logs and system state without altering the evidence. Smaller organizations often struggle with the investigation step and with obtaining supplier data quickly. Ask whether your team can meet the two-day deadline in a tabletop exercise before deciding what to keep internal.

Do we need a partner for tabletop exercises or incident investigations?

A partner is optional for both, but the split of work should be explicit. An implementation partner can design the tabletop scenarios, run them with your staff, and record gaps in the procedure. For investigations, a partner can help set up a case management system, configure evidence logging with hashing and chain of custody, and build timelines from logs. The organization still owns the investigation, the risk assessment and the corrective action, and the authority receives the report from the provider. Independent auditors and certification bodies issue any assessment reports. Ask whether the partner is supporting exercises, investigations or both, and who keeps the records afterwards.

Does the AI Office route change how we report incidents?

Yes, for the systems it covers. Since the 2026 amendment, providers of high-risk systems supervised by the AI Office under Article 75(1) report serious incidents to the AI Office rather than to a national market surveillance authority. The deadlines and investigation duties stay the same. Systems built on a provider's own general-purpose model, and AI in very large online platforms and search engines, fall under this route. Confirm with your counsel or the authority which route applies to each system, and build the reporting template so it can be sent to either body without rework.

What does the draft Article 73 guidance mean for a procedure we build now?

The Commission published draft Article 73 guidance and a draft incident report template for consultation on 26 September 2025, with feedback until 7 November 2025. The draft is not final, so build the procedure around the Act's text, which is stable, and keep the reporting templates and triggers in configurable documents. Design the case record so that fields can be added when the final template is adopted. Track the final guidance through the Commission's AI Act pages and review the procedure once it is published. Ask any partner how they will update templates and exercises when the guidance changes, and whether that update is part of the fixed scope or a retainer.

How DeployOpen prepares Article 73 reporting for your systems

DeployOpen prepares the systems, records and evidence that let a high-risk AI provider meet the Article 73 reporting clock. The provider owns the reporting decision and the submission to the market surveillance authority, and DeployOpen works inside the client's own infrastructure to make that decision traceable and repeatable.

How we scope

Scope starts with a list of high-risk AI systems and the authority each one reports to.
The written scope names the incident sources, such as logs, monitoring alerts and user complaints, that feed the reporting process.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

How we build

We set up a case workflow in a self-hosted tool such as DFIR-IRIS, so each suspected incident becomes one record with assets, tasks and evidence.
We configure audit logging for the systems that hold incident evidence, so changes and access leave a traceable record.
We test the triage and escalation path with tabletop exercises that time the 2, 10 and 15 day deadlines against your own roles.

How we hand over

You receive the written incident procedure, the reporting decision log template and the escalation contact matrix.
Evidence handling steps cover hashing, chain of custody and a rule that the system is not altered before the root cause is preserved.
Your staff receive a runbook and a walkthrough so the team can run a real report without outside help.

How we support

Ongoing support can cover updates to the procedure when the Commission finalizes its Article 73 guidance and reporting template.
Retainers can include periodic tabletop exercises and review of incident records against the reporting timeline.
Any statement to an authority remains the provider's decision, and independent auditors or authorities assess the result, not DeployOpen.

Article 73 Reporting of serious incidents