DORA for ICT third-party AI providers

The split is the entire page. Adjudon is an ICT third-party service provider under the Digital Operational Resilience Act (Verordnung (EU) 2022/2554). Your bank is the financial entity. We ship the chain row your DORA Article 28(3) register requires; you file the register. We document this honestly so procurement does not arrive expecting a one-click DORA-ready button that does not exist.

Scope

This page applies to financial entities in the scope of DORA Article 2 — credit institutions, payment institutions, investment firms, insurance and reinsurance undertakings, central counterparties, and others — that integrate Adjudon as an ICT third-party service provider supporting an AI-driven function classified as critical or important by the bank's own risk assessment. AI-driven underwriting, AML alerting, fraud scoring, and transaction monitoring are common examples; the classification is the bank's, not ours.

DORA was enforceable from 17 January 2025. Two delegated regulations complete the framework: the ICT risk management RTS (Del. VO 2024/1774) and the sub-contracting RTS (Del. VO 2025/532).

Roles

Role	Party	DORA basis
Financial entity	Your bank / insurer / firm	Art. 2(1)
ICT third-party service provider	Adjudon	Art. 3(19)
Critical-or-important-function classifier	Your bank	Art. 28(2)
ICT register maintainer	Your bank	Art. 28(3)
Exit-strategy executor	Your bank	Art. 30
Evidence supplier	Adjudon	Art. 28(3), Art. 30(2)(d)

The single most-misread procurement question is "is Adjudon DORA-compliant?" DORA places its obligations on the financial entity, not on the ICT TPSP. Adjudon ships the technical artefacts the bank's compliance team uses to satisfy those obligations: the SHA-256 hash chain, the geographic anchor (Frankfurt eu-central-1), the sub-processor disclosure, the exit-bundle endpoint. The bank does the filing.

Article-by-article mapping

Article	Requirement	What Adjudon ships	What you do
Art. 5	Governance & internal control	Cardinal-Rule-anchored isolation (no cross-org leakage)	ICT-risk governance per Art. 5
Art. 6	ICT risk-management framework	EU-resident pipeline, AES-256 at rest, TLS 1.2+ in transit	Document the framework per Art. 6(8)
Art. 8	Identification	Trace ingestion records every AI decision via `POST /api/v1/traces`	Classify the function as critical-or-important
Art. 9	Protection & prevention	PII scrubber + per-org isolation + tamper-evident chain	Configure dashboard access, key rotation
Art. 10	Detection	Confidence Engine flags + Policy Engine `block`	Define alert thresholds dashboard-side
Art. 11	Response & recovery	Multi-Clock Incident Hub on every opened incident	Open the incident; mark checkpoints
Art. 17	ICT-related incident management process	`Incident` document carries severity, category, `triggerTraceIds`, regulator clocks	Run the process, escalate per Art. 17(3)
Art. 19	Major-incident reporting (4 h / 72 h / 30 d)	`IncidentClock` with `regulator: 'dora'` and `articleRef: 'Art. 19'`	File the 4h/72h/30d notifications with the supervisor
Art. 28	ICT third-party risk principles	Sub-processor disclosure (see data-residency)	Conduct pre-contract due diligence
Art. 28(3)	Register of contractual arrangements	Geographic anchor + sub-processor list + DPA = the row	File and maintain the register
Art. 28(8)	ICT-third-party-risk strategy + exit plan	The exit bundle is replay-verifiable offline	Adopt and yearly-review the strategy
Art. 29	Key contractual provisions	DPA covers the mandatory clauses	Sign the DPA before production
Art. 30	Exit-strategy provisions	`GET /api/v1/hash-chain/export` is the exit artefact	Document and test the exit plan
Art. 50	Administrative measures (proportionate fines)	Records of processing on demand	Operate within the supervisory framework

The Multi-Clock Incident Hub runs the DORA Art. 19 clock in parallel with four others off the same incident; see Multi-Clock Incidents for the five-regulator concurrent model.

Evidence

The DORA Art. 30 exit-plan obligation has one defining property: the plan must be effective even if the ICT third-party becomes unavailable. A login-mediated CSV export from a vendor dashboard fails this test; the endpoint stops responding when the vendor disappears. The chain export does not depend on us being reachable.

curl
curl https://api.adjudon.com/api/v1/hash-chain/export \
  -H "Authorization: Bearer $ADJUDON_API_KEY"

Python
import requests, os
r = requests.get(
    "https://api.adjudon.com/api/v1/hash-chain/export",
    headers={"Authorization": f"Bearer {os.environ['ADJUDON_API_KEY']}"}
)
bundle = r.json()

The response is a self-contained JSON document the auditor recomputes against the published algorithm at Audit Log & Security:

chainHash = sha256(prevHash || payloadDigest || sequence || createdAt)

No Adjudon login, no Adjudon endpoint, no Adjudon network is required for the verification step. That is the procurement-grade meaning of "exit plan effective if the vendor becomes unavailable" — the bundle on disk plus the published algorithm is the complete environment.

The chain is tamper-evident, not tamper-proof: any modification to a stored entry breaks the next entry's prevHash link, and verification returns brokenAt: <sequence>. Tampering is loud.

Multi-Clock for DORA Art. 19 (4 h / 72 h / 30 d)

When a major ICT-related incident is opened, the Multi-Clock Incident Hub creates an IncidentClock with regulator: 'dora', articleRef: 'Art. 19', and three checkpoints:

Checkpoint	Deadline	Purpose
Initial classification	4 hours	Notify the supervisor that a major incident occurred
Intermediate report	72 hours	Technical detail, scope, mitigation status
Final report	30 days	Root-cause analysis, full timeline, remediation

A breached checkpoint is not deleted. The clock's status flips to breached and nextCheckpointAt stays in the past so the post-incident audit can replay exactly which deadline was missed and when. Four other regulator clocks fire in parallel off the same Incident document (GDPR Art. 33, EU AI Act Art. 73, NIS2 Art. 23, CRA Art. 11) — five clocks, one detection event, one log.

Honest disclosures

The 99.9% uptime SLO covers Scale and Governance plans; the 99.99% SLO target for Enterprise / Custom plans is on the roadmap, not live.
Adjudon does not white-label, does not run on customer-cloud, does not offer on-premise. The SaaS deployment is the only deployment; see Data Residency & GDPR.
The OpenAI sub-processor (USA, GDPR Chapter V SCCs) is the one documented exception to EU residency; the embedding call is opt-in per organization.
There is no Adjudon-shipped "DORA Article 28 evidence pack" feature. The bank assembles the register entries from the chain export and the sub-processor list. We document this honestly so procurement does not arrive expecting a one-click DORA-ready button that does not exist.

What this page does NOT cover

Residency split + DPA + Article 28 sub-processor disclosure — see Data Residency & GDPR.
Multi-Clock Hub architecture and the five-regulator concurrent model — see Multi-Clock Incidents.
EU AI Act mapping (Art. 13 / 14 / 27 / 73) — see EU AI Act Compliance.
MDR Class IIa/IIb pseudonymisation — see Medtech Compliance.
The full chain export endpoint surface — see Hash Chain API.
Penetration testing status — see Penetration Testing.

Scope​

Roles​

Article-by-article mapping​

Evidence​

Multi-Clock for DORA Art. 19 (4 h / 72 h / 30 d)​

Honest disclosures​

What this page does NOT cover​

See also​