DORA Article 17 and 18 — incident classification when the AI subsystem fails

DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — became applicable on 17 January 2025 and covers approximately 22,000 financial entities across the EU. The regulation's premise is straightforward: financial entities depend on ICT, ICT fails, and the supervisory framework has to be designed for when ICT fails rather than assume it won't.

For entities running AI-driven decisioning — credit scoring, fraud detection, KYC automation, claims processing — DORA's ICT-incident framework applies the moment the AI misbehaves. This post walks through the two most relevant articles (17 + 18), shows how AI-decisioning failures map into DORA's classification scheme, and explains what the per-decision audit log has to contain so the financial entity can answer the supervisor's questions in the 24-hour notification window.

DORA's architecture, briefly

DORA's articles cluster into five workstreams:

• Articles 5-15: ICT risk management. The financial entity must have a documented ICT risk-management framework. Articles 6-7 specify what the framework contains; Article 8 defines the protection + identification + detection cycle.
• Articles 17-23: ICT-related incident management and reporting. This is where AI-decisioning failures most directly land.
• Articles 24-27: Digital operational resilience testing. Penetration testing + threat-led penetration testing (TLPT) for designated entities.
• Articles 28-44: ICT third-party risk management. The model-vendor relationship lives here.
• Articles 45-50: Information sharing arrangements. Voluntary cyber-threat-intel sharing.

Articles 17 + 18 + 28 do most of the work for AI decisioning. The rest of this post focuses on those.

Article 17 — ICT-related incident management

The opening line:

Financial entities shall have an ICT-related incident management process to detect, manage and notify ICT-related incidents.

— DORA Article 17(1)

Article 17(2) lists what the process must do: classify incidents based on impact criteria (deferring to Article 18), assign causes, record all incidents and findings, take appropriate corrective measures, and notify management.

For AI decisioning, the implementation is about getting from "the model misbehaved" to "incident X, severity Y, scope Z" quickly + with evidence. The L12 chain is the evidence primitive that lets this happen: the chain captures every decision, every fallback firing, every schema violation, every reviewer verdict. Once you have the chain, classifying an incident is a query rather than a forensic exercise.

Article 18 — Classification of ICT-related incidents

Article 18(1) requires financial entities to classify incidents and determine their impact using these criteria:

• Clients affected — number + share of the entity's client base.
• Reputational impact — likelihood the incident becomes public.
• Duration — from detection to resolution.
• Geographic spread — member states affected.
• Data losses — including confidentiality/integrity loss.
• Criticality of services affected — is this a core function or a tangential one?
• Economic impact — direct + indirect cost.

Each criterion has a quantitative threshold in the Commission Delegated Regulation (the supplementary RTS). Cross those thresholds and the incident becomes "major" — triggering the 24-hour notification obligation under Article 19.

Mapping AI failure modes to Article 18 criteria

Three failure modes worth distinguishing:

Failure mode 1: systematic misclassification

The model has been misclassifying a particular pattern for N decisions before anyone noticed. For a fraud classifier this might mean letting through a class of fraudulent transactions; for a credit decision system it might mean wrongly denying credit to a demographic.

From the L12 chain:

• Count entries between the suspected onset and detection where the schemaValid was true but the verdict was wrong. That's clients affected.
• Compute the duration as max(recordedAtMs) − min(recordedAtMs) across the affected entries. That's duration.
• If the misclassifications spread across the operator's merchants/clients (via the tenantId field on multi-tenant deployments), that's geographic spread or the proximate proxy for it.
• The financial impact is the operator's loss calculation — but the count of affected decisions feeds it.

Failure mode 2: hallucinated output (LLM generation)

The model generated content that violated the closed-enum outputSchema. With the substrate's design, this fires the fallback handler, and the L12 entry records schemaValid: false + fallbackTriggered: true.

Hallucination in itself is rarely a major incident — the fallback handles it. The incident triggers when the fallback rate itself spikes, suggesting the model drifted or the operator's vendor swapped models without notification. Promethean's chain captures the model-identity per entry, so a sudden change in the fallback rate correlated with a model-identity change is forensically obvious.

Failure mode 3: chain-integrity failure

Less common but worth noting: the L12 chain itself fails verification — a hash mismatches, a signature doesn't validate, the chain head doesn't match the last anchor. Under DORA Article 17 this is "an event that compromises the integrity of decisioning data" — the most severe class of ICT incident.

The substrate detects this on the next anchor cron run (or the next verify.mjs invocation). The detection latency is bounded by the anchoring cadence: 24h on Team tier, 1h on Production, 30min on Scale, 15min on Enterprise. Choosing a cadence is a substantive DORA decision; the substrate publishes the cadence in workspace.json + the regulator handoff packet so a supervisor sees what the operator committed to.

Six questions an incident postmortem has to answer

DORA-required answer                 L12 field that provides it
─────────────────────────────────────────────────────────────────
When did it start?                   first entry's recordedAtMs
                                     with the anomaly pattern
Which AI spec was active?            specHash (workspace
                                     publishes spec history)
Which model was running?             modelIdentity per entry
How many decisions affected?         count of matching entries
Did fallback handle it?              fallbackTriggered counts
Did reviewers catch it?              reviewerVerdict distribution

All six computable from the chain export, without depending on the financial entity's observability stack. The chain export is suitable evidence for the regulator notification in Article 19's 24-hour window — the entity can attach the relevant entries directly.

Article 28 — Third-party model vendor risk

DORA Article 28 requires financial entities to manage ICT third-party risk integrally with ICT risk. For AI decisioning, the principal third-party is the model vendor. Article 28(3) requires a register of all ICT third-party providers; Article 28(4) requires contracts to include specific clauses (service-level descriptions, locations, sub-outsourcing controls, exit terms, audit rights).

Promethean records the model identity per L12 entry. This is the operational evidence supporting the Article 28 register: the financial entity can prove, per transaction, which third-party service was actually invoked. The contract itself (with Anthropic, OpenAI, Azure, etc.) is the operator's. The substrate provides the per-transaction attribution.

Article 28's concentration-risk requirement is also worth noting: a financial entity can't rely on a single critical third-party without considering substitutability. The L12 chain's model-identity field lets the entity demonstrate diversity quantitatively — how often is each vendor invoked, what fraction of decisions depend on each.

Article 19 — Notification timeline

For incidents classified as major under Article 18:

• Initial notification within 24 hours of becoming aware.
• Intermediate report within 72 hours.
• Final report within one month.

The 24-hour deadline is where having a verifiable chain already in production matters most. Constructing an audit log retroactively against the clock + then convincing a regulator it isn't backdated is the worst possible position to be in. Having a continuous L12 chain that has been anchored externally before the incident means the evidence for "decisions X-Y had this character" is already settled.

Actionable summary

• Inventory every AI decisioning component in scope of DORA. Anything making per-transaction decisions is in scope.
• Decide on an OpenTimestamps anchoring cadence proportional to your tier's detection-latency budget. Document the choice.
• Pre-compute the Article 18 thresholds for your business (X clients affected = major; Y duration = major; etc.). Make the threshold calculation part of your incident runbook.
• Practice the 24-hour notification with a tabletop using a real chain export. The first time should not be a live incident.
• Maintain the Article 28 ICT-third-party register and cross-reference it against the model-identity field counts in your chain. Discrepancy is a signal.

Promethean's DORA framework template ships on the Enterprise tier and surfaces each article's evidence kind alongside the operator gap. Free Dev tier produces a real signed chain suitable for evaluating the audit-trail mechanics locally; paid tiers add hosted anchoring + the framework templates.

Sector-specific guidance