Frameworks · Laws and regulations

qodiqa and DORA

qodiqa checks each AI request before the call and keeps tamper-evident, offline-verifiable evidence. This page shows where that evidence supports DORA, and where it does not.

Law
European Union
Applies since 17 Jan 2025.
Verified 2026-11-01

Read the official text Back to all frameworks

Overview

What it is

Issuer: European Union
Type: Law
Status: Applies since 17 Jan 2025
Official text: eur-lex.europa.eu

Regulation (EU) 2022/2554, the Digital Operational Resilience Act. DORA sets uniform rules for the digital operational resilience of EU financial entities: an ICT risk management framework, incident management and reporting, resilience testing and the management of risk from ICT third-party providers, including AI providers.

Who it applies to. Banks, insurers, investment firms, payment and crypto-asset service providers and other EU financial entities, and their critical ICT third-party providers.

Where it meets qodiqa

The parts of DORA where the evidence matters.

Record-keeping and logging

A tamper-evident record of what the gateway decided and why.

Robustness and security

Checks run before the call, and a missing record means no answer.

Traceability

Each decision is tied to a request id, a provider and a hash.

Risk management

Detection, metrics and alerts for the AI layer.

Accountability

Records an assessor can verify offline, without trusting the operator.

Human oversight

A kill switch and revocation let operators stop AI use quickly during an incident.

Mapping

What qodiqa provides, and what stays with you.

Requirement or control	What qodiqa provides	What stays with you
`Art. 9(4)(c)` Policies that limit logical access to information and ICT assets to what is needed for legitimate functions.	Per-actor signing keys and role-based operator access, with a consent check on every request.	Access control for the rest of your ICT estate.
`Art. 10(1)–(3)` Detection: mechanisms to promptly detect anomalous activities, with alert thresholds and resources to monitor user activity.	Anomaly detection on signature and request bursts, rate limits, metrics, alert rules and an export schema for security tooling.	A detection capability for your whole ICT environment, and staffing to run it.
`Art. 17(2) and 17(3)(b)` Incident management: record all ICT-related incidents and identify, track, log, categorise and classify them.	A tamper-evident record of blocked requests and reasons, and incident-response runbooks.	Classification of incidents under Art. 18, reporting under Art. 19, and the process around them.
`Art. 6 and Art. 9` ICT risk management framework, and protection and prevention measures.	Enforcement before the call, fail-closed behaviour and signed, request-bound artifacts as a concrete prevention control.	The framework, strategy and resilience testing.
`Art. 28 and Art. 30` Management of ICT third-party risk and key contractual provisions.	Explicit provider routing, and the signed artifact payload names the provider the request is for.	The register of information, due diligence and contracts with AI providers.

The specification’s Regulatory Alignment Matrix does not cover DORA. This page maps the gateway documentation only.

How it fits

What DORA asks, and what qodiqa produces.

Detect anomalies (Art. 10) is supported by Burst detection and alerts (Metrics and SIEM export).
Record incidents (Art. 17) is supported by Tamper-evident record (Blocked requests and reasons).
Third-party risk (Art. 28) is supported by Provider named per request (In the signed artifact).

Evidence

Evidence you can hand to an auditor.

Five artifacts, each checkable on its own

Consent artifact Signed with Ed25519, bound to one request, single use.
INTENT entry The audit entry written before the provider call.
Receipt A signed decision record that checks offline.
Audit export Hash-chained entries with a Merkle inclusion proof.
Anchor proof A signed checkpoint pinned outside the gateway.

Verify offline, from a clone of qodiqa-verify

node bin/verify.bundle.external.js \
  --keys examples/front-half/keys.json \
  --transparency-keys examples/front-half/transparency-keys.json \
  examples/front-half/bundle-with-proof.json

The example files ship with the repository and are signed with throwaway keys. The command exits 0 and prints "valid": true. For your own evidence, take keys and anchors from a source other than the gateway that wrote it.

Scope and limits

Technical evidence, not a compliance outcome

qodiqa produces verifiable technical evidence that supports parts of DORA. It is not a compliance certification, it is not legal advice, and no regulator or standards body has endorsed it. Whether your use meets DORA is a decision for you and your advisers.

What qodiqa does not address:

Governance, the ICT risk-management framework and resilience testing.
Third-party provider contracts and the register of information.
Classifying and reporting major ICT incidents to the authority.
Only requests that pass through the gateway are checked, and a receipt proves a decision was recorded, not that it was correct.

Sources

Article, clause and control references were read in the official texts listed first. The remaining links are qodiqa’s own documents. Checked on 2026-11-01; rules change, so read the current text.

Regulation (EU) 2022/2554 (DORA), EUR-Lex accessed 2026-11-01
qodiqa-gateway: enforcement flow accessed 2026-11-01
qodiqa-gateway: incident response accessed 2026-11-01
qodiqa-gateway: SIEM export schema accessed 2026-11-01

Next steps

See the evidence for yourself.

Read the spec section Run a simulation Quickstart