DORA has been enforceable since 17 January 2025. The two delegated regulations that complete the framework — the ICT risk management RTS (Del. VO 2024/1774) and the sub-contracting RTS (Del. VO 2025/532) — followed shortly after. Banks spent much of the intervening year getting their ICT departments in order. The AI-governance layer — the category of vendor that sits between a regulated AI decision and the evidence trail a BaFin examiner reads — received less scrutiny. Articles 28 through 30 cover it.
Enforceable since January 2025. Not all vendors noticed.
The Digital Operational Resilience Act covers any entity the EU financial-services framework recognises: credit institutions, payment institutions, investment firms, insurance undertakings, and more. It does not cover their vendors directly. What it does is hold the financial entity responsible for ensuring that every ICT third-party service provider supporting a critical or important function is managed under the Art. 28–30 regime.
“Critical or important function” is defined by the bank, not the vendor. A bank that uses an AI system to make credit decisions, flag AML matches, or price underwriting risk has almost certainly classified that function as critical or important in its own risk assessment. Any platform whose failure would impair that function — including a platform that records the decisions, routes human reviews, and holds the audit trail — is in scope. AI-governance vendors are ICT third-party service providers when their platform supports those functions.
The category label the vendor uses does not change the analysis. “AI governance” is not a DORA carve-out. The question is functional.
Article 28 doesn't ask what category you're in. It asks what function you support.
Article 28 sets the general frame. Financial entities must manage ICT third-party risk. Before signing with any vendor supporting a critical or important function, the bank must conduct due diligence: assess the vendor's security posture, data handling, and operational resilience. That assessment must be documented and reviewed at least annually.
Article 28(8) adds a harder obligation. The financial entity must adopt — and regularly review — a strategy on ICT third-party risk. That strategy must include an exit plan for every critical ICT third-party dependency. The exit plan is not a clause in a contract. It is an operational document that the bank can hand to a BaFin examiner and say: here is how we would continue operating the function if this vendor were no longer available tomorrow.
“Tomorrow” is the operative word. Art. 28(8) does not contemplate a clean six-month transition. It contemplates a disappearance.
Article 29 builds the floor. The floor is not the ceiling.
Article 29 specifies the minimum content a contract with an ICT TPSP supporting a critical or important function must include. Written agreement. Defined service levels. Termination rights. Data access rights on termination. Sub-processor disclosure. Audit and inspection rights.
Each provision addresses a specific post-exit scenario. Termination rights: you can end the relationship. Data access on termination: you can retrieve your data. Audit rights: you can verify what happened to your data during the engagement. These are necessary. They are not sufficient.
Termination rights are exercised in writing. Data access on termination is exercised via a request to the vendor. Both require the vendor to be operating. Article 30 asks a different question: what happens when the vendor is not operating?
Article 30 goes further. The exit must work without the vendor.
Article 30 governs exit strategies specifically. For contracts covering critical or important functions, the contractual arrangements must include documented exit provisions that allow for an orderly transition — with or without the vendor's active cooperation.
The key phrase, which procurement teams consistently miss, is the vendor-unavailability scenario. The exit plan must be effective even if the ICT third-party provider becomes unavailable. Not “if we decide to leave.” Not “if we negotiate a transition.” If the vendor stops existing. A startup that shuts down. An acquisition that takes the product off the market. An API deprecated without notice. A data-centre incident that takes the vendor offline for longer than the bank can absorb.
Under that framing, BaFin examiners will want to see three things. First, the exit plan document itself. Second, evidence that the plan has been tested — that someone ran through it, found the gaps, and closed them. Third, and most important: proof that the evidence chain the bank relies on for regulatory purposes would survive the vendor disappearing between the last export and the audit date.
The third requirement is where most AI-governance vendors quietly fail.
Login-mediated evidence fails the disappearance test.
Most AI-governance platforms store their audit trail behind a dashboard. To export evidence — to produce the audit records that a BaFin examiner, an internal compliance team, or an Article 30 review would require — the bank must authenticate, request an export via the vendor's API or UI, and receive a vendor-formatted file. Every step in that sequence requires the vendor to be operating.
This is not a criticism of any vendor's intent. It is a structural property of platforms built on the assumption that access is always mediated through a live system. Under that assumption, a CSV export from the dashboard is useful day-to-day. Under the Article 30 vendor-unavailability scenario, it is worth nothing. The vendor is unavailable. The authentication fails. The export endpoint returns nothing.
What the bank then holds is an audit trail it cannot read, administered by a company that no longer exists. The procurement team signed a contract with Art. 29 data-access provisions. The vendor is gone. The provisions are unenforceable. The BaFin examiner is waiting.
A CSV export from a UI is not an exit plan. It is a vendor-cooperation agreement. Article 30 requires something different.
The chain export is the evidence bundle the examiner keeps offline.
GET /api/v1/hash-chain/export returns a self-contained JSON bundle: every HashChainEntry in the organisation's chain, with every field the verify algorithm needs. Sequence number, previous hash, payload digest, chain hash, creation timestamp.
The published verify algorithm is four steps. For every entry, recompute the chain hash from sha256(prevHash || payloadDigest || sequence || createdAt) and compare it to the stored value. If every comparison passes, the chain is intact. If one fails, the algorithm returns the sequence number of the first break. The result is either verified: true or brokenAt: <sequence>. There is no third state.
That verification runs against the downloaded bundle. No Adjudon login. No Adjudon endpoint. No Adjudon infrastructure of any kind. The bundle and the published algorithm are the complete verification environment. An auditor can run it on a laptop with no internet access, against a bundle exported weeks or months earlier.
Under the Article 30 vendor-disappearance scenario: the bank has a scheduled export bundle on disk. Adjudon goes dark. The bank's compliance team runs the published algorithm against the bundle. The chain verifies. The evidence is intact. The BaFin examiner receives a complete, tamper-evident record of every AI decision the system made while the vendor was operating — without Adjudon in the room.
The register is yours. The row is ours.
DORA requires the bank to maintain a register of all contractual arrangements with ICT third-party service providers. That register is the bank's responsibility. Adjudon does not file the register. Adjudon does not manage the register. The bank assembles the register entries from the evidence it holds.
What Adjudon contributes to that entry is specific and bounded: the hash-chain export bundle, the geographic location of the infrastructure (Frankfurt eu-central-1, published and stable), and the sub-processor disclosure (five EU-resident sub-processors; OpenAI was removed from the list on 2026-05-11 when the Confidence Engine's embedding generation was migrated to a self-hosted TEI sidecar in the same Frankfurt region). The bank takes those inputs, assembles the register entry under its own Art. 28 strategy document, and files it.
There is no “DORA-ready” button. We document this explicitly so procurement does not arrive expecting a one-click compliance pack that does not exist. The compliance work is the bank's. The evidence infrastructure is ours.
The exit scenario, run end to end: the bank holds a scheduled export bundle. The vendor — any vendor, including Adjudon — goes dark. The compliance team runs the published algorithm against the bundle. The chain verifies. The BaFin examiner receives a complete, unbroken record of every AI decision made while the vendor was operating. No login required. No transition negotiation. No vendor cooperation of any kind.
That is the Article 30 test. That is the chain.