DORA — digital operational resilience of the AI model

DORA (EU Regulation 2022/2554, applicable since 17 January 2025) establishes digital operational resilience requirements for EU financial sector entities. Within its per-system scope, the AI scoring model — or any AI system acting as a critical ICT asset — is subject to obligations for ICT risk management, protection, anomaly detection, and resilience.

Per-system scope: what part of DORA the engine governs

DORA covers a broad range of organisational obligations (management-body governance, incident reporting to the competent authority, threat-led penetration testing —TLPT— Art. 26, ICT third-party concentration management). Those obligations are organisational-level and belong in the QMS.

The froga engine covers only the governable per-system slice: the AI model as an ICT asset — its control hierarchy, threat estimation, artefact integrity, third-party component inventory, and the post-market monitoring plan. Everything organisational is an honestly declared gap.

Clause catalogue

The file crates/froga-core/resources/standards/dora-clauses.yaml declares the modelled clauses. The identifiers are semantic (dora.*) and anchored in the public articles of the base Regulation (Arts. 5-30), not in the Level-2 RTS/ITS numbering of 2024.

Clause	Short title	Regulatory anchor	`satisfied_by`
`dora.ict-risk-framework`	ICT risk management framework: coherent control hierarchy of the asset	Art. 5-6	`criterion: control_hierarchy`
`dora.ict-risk-identification`	Identification and classification of the model’s ICT risks	Art. 8	`criterion: risk_estimation`
`dora.ict-risk-assessment`	ICT risk assessment: aggregate residual evaluated against the declared criterion	Art. 6(2)	`criterion: criteria_applied`
`dora.ict-protection`	ICT protection/prevention measures: integrity, quality and confidentiality	Art. 9	`measures_citing: true`
`dora.ict-system-resilience`	ICT system integrity and resilience: minimum stability/accuracy of the model	Art. 9	`measures_citing: true`
`dora.ict-detection`	ICT anomaly detection and continuous monitoring of model behaviour	Art. 10	`measures_citing: true`, `evidence: monitoring_plan`
`dora.backup-resilience`	ICT asset reproducibility and recovery: artefact anchored in signed bundle	Art. 12	`evidence: signed_bundle`
`dora.ict-risk-review`	Periodic review of the ICT risk framework	Art. 6(5)	`evidence: monitoring_plan`
`dora.resilience-testing`	Digital operational resilience testing per-system (not TLPT)	Art. 24-25	`measures_citing: true`
`dora.third-party-register`	Raw material for the ICT Third-Party Information Register: signed CycloneDX BOM with purls	Art. 28(3)	`evidence: signed_bom`
`dora.incident-management`	Detection and channelling of the model’s ICT incidents via monitoring	Art. 17	`evidence: monitoring_plan`

How the `satisfied_by` model works

A clause is evaluated as COVERED, PARTIAL, or GAP based on the mechanism declared in satisfied_by:

criterion: <name> — the clause is covered when the named criterion (e.g. control_hierarchy, risk_estimation, criteria_applied) is satisfied in the signed bundle.
measures_citing: true — the clause is covered when at least one signed measure cites it in its frameworks and the associated control passes. Without a citing measure, it emits GAP.
evidence: <type> — the clause is covered when evidence of the indicated type is present in the bundle: signed_bundle (the signed bundle itself), monitoring_plan (a declared post-market monitoring plan), signed_bom (a signed CycloneDX BOM with purls).

froga conformance --standard eu/dora@2022 evaluates each catalogue clause against the project’s signed bundle and emits the report grouped by ICT cycle phase.

Honest gaps

🟡 Partial — The engine covers the governable per-system slice of the ICT asset. DORA's organisational obligations are out of scope by design. See Status & gaps.

dora.third-party-register / third-party inventory: the engine certifies “signed BOM present” (signed_bom), not “complete Information Register with provider LEIs”. Materialising the Register (ITS Reg. EU 2024/2956 field B_05.01: purl → LEI) is done by the cloud plane (doraRoiCsv), not the local engine. Without a signed BOM in the bundle, this clause is a GAP.

dora.incident-management: the engine certifies that a monitoring plan exists that can detect and channel model deviations. It does not certify the reporting of major incidents to the competent authority (DORA Arts. 19-23), which is an organisational/operational obligation.

TLPT (Art. 26): threat-led penetration tests are exclusive to systemic financial entities and are organisationally executed. They are not in the per-system catalogue.

ICT third-party concentration and exit management (Arts. 28-30): organisational obligation. Outside per-system scope.

How to use `froga conformance` with DORA

# Evaluate the per-system DORA slice from the signed bundle
froga conformance --standard eu/dora@2022

# With history per RDD iteration
froga conformance --standard eu/dora@2022 --history

# Export to .froga/conformance/
froga conformance --standard eu/dora@2022 --out

The report emits COVERED / PARTIAL / GAP per clause. To evaluate all standards declared in applicable_standards:

froga conformance --out

Relation to other standards

ISO 23894 — the risk management process underlying the engine; the risk_estimation and control_hierarchy criteria that satisfy several DORA clauses are implemented there. See ISO 23894.
EU AI Act Art. 9 — the high-risk AI system risk management obligation; DORA is an orthogonal layer (sectorial ICT resilience). See EU AI Act.
prEN 18283 (bias) / prEN 18282 (cybersecurity) — draft harmonised catalogues for the fairness and cybersecurity dimensions; they complement DORA in financial systems.