DORA and AI Operational Resilience: Proving It With Signed, Replayable Evidence

The Digital Operational Resilience Act, DORA, asks a deceptively simple question of every regulated financial entity in the European Union: prove that your critical systems can withstand disruption, respond when they fail, and recover without losing the thread of what happened. For decades that proof lived in change logs, incident tickets, and a manager's word that the runbook was followed. As artificial intelligence takes on real work inside banks and insurers, that kind of proof quietly stops being enough.

A model that reasons, decides, and acts is not a static piece of infrastructure you can point a scanner at once a quarter. It changes behaviour with its inputs and reaches into other subsystems. When a regulator asks what it did during a stress event, and why, the honest answer under most architectures is a shrug and a partial log. We built Mickai so that the answer is a signed, replayable record instead. This is how operational resilience should be proven when the system under scrutiny is one that thinks.

What DORA actually demands of a thinking system

DORA is not a checklist bolted onto existing security policy. It is a resilience regime built on five pillars: information and communication technology risk management, incident reporting, resilience testing, third-party risk oversight, and information sharing. Each pillar assumes you can answer questions about your systems with evidence, not assertion. What was the state before the disruption? What action was taken? Who or what authorised it? Can you reconstruct the sequence for a supervisor months later?

When the acting system is an artificial intelligence, these questions get harder in three specific ways. The decision boundary is no longer a person with a signature. The behaviour is probabilistic, so yesterday's passing test does not guarantee today's outcome. And the system reaches across data domains, so resilience evidence has to survive being pulled apart by people who were never in the room. DORA does not exempt AI from any of this. If anything, an intelligent system in the critical path raises the bar, because the potential for silent, cascading failure is greater.

Why screenshots stopped being evidence

Most organisations still assemble resilience evidence the way they always have. Someone runs the test, captures the console, exports a log, and files it in a folder that will be trusted because the organisation is trusted. This works right up to the moment it is challenged. A log can be edited. A screenshot proves nothing about the state of the wider system at that instant. A ticket records that a human believed something happened, not that it did. Under the adversarial scrutiny DORA's testing and incident pillars invite, this material is closer to testimony than to proof.

The gap widens the moment an AI subsystem is involved, because the interesting failures are the ones nobody anticipated. If your evidence is only the moments you chose to capture, you have no answer for the moment you did not. Durable resilience evidence has to be produced automatically, continuously, and in a form that cannot be quietly rewritten after the fact. That is a cryptographic requirement, not a documentation one.

Attestation before the action, not after

The primitive we lean on hardest is the Operation Attestation Record, the OAR. Every action a Mickai subsystem takes is described, signed, and recorded before it executes, not after. The record captures what is about to happen, which brain is proposing it, the relevant state, and the authorisation that permits it. Only then does the action run. Evidence written after an event can always be accused of being written to fit the event. Evidence written before it cannot.

For DORA, this changes the character of the whole conversation. Resilience testing becomes a matter of replaying attested records rather than re-running fragile scripts and hoping the environment matches. Incident reporting draws on a record that already exists at the required granularity, captured at the moment of action. And for a high-stakes action, we require multi-brain agreement and voice-biometric approval before the OAR is signed, so the authorisation itself is part of the permanent record.

Chains that hash-link and verify offline

Individual signed records are necessary but not sufficient. A supervisor needs to know the sequence is complete and unbroken, that nothing was removed between the entry they are reading and the one before it. We chain every attestation into a tamper-evident ledger using SHA-3-512 hash linking, so each record cryptographically commits to the one before. Remove or alter a single entry and the chain visibly breaks. No version of the history reconciles except the true one.

The signatures themselves use post-quantum cryptography, the FIPS 204 ML-DSA-65 standard, so the evidence stays defensible against future computational threats, not only present ones. Crucially, all of this verifies offline. An auditor, a regulator, or a resolution authority can confirm the integrity of the entire chain without calling back to us and without trusting the environment it was produced in. Resilience evidence that depends on a running system to be believed is not resilient. Ours does not.

Resilience on hardware the customer owns

DORA's third-party risk pillar exists because concentration in a handful of external providers is itself a systemic vulnerability. The regulation wants firms to understand, test, and where necessary exit their critical dependencies. This is precisely the boundary the public cloud cannot cross on the customer's own terms, and it is the boundary Mickai was built for. The public cloud giants are allies operating at a different layer. Mickai runs on hardware the customer owns, air-gapped or on-premise, with zero data egress.

That posture turns several DORA obligations from ongoing anxieties into settled facts. Data residency is not a contractual promise, it is a physical property of where the system runs. Exit strategy is not a fire drill against a provider who holds your data hostage, because the data never left. And resilience testing can be as adversarial as the firm dares, because the whole system, including its signed ledger, sits inside its own control perimeter. Every brain is revocable, so a subsystem that behaves outside expectation can be withdrawn without dismantling the rest.

The evidence a supervisor can replay

The test of any resilience claim is whether an independent party can reconstruct events and reach the same conclusion you did. Because every action was attested before it ran, because those attestations are hash-linked into a signed chain, and because that chain verifies offline, a Mickai resilience record is not a report about what happened. It is a replayable reconstruction of it, carrying its own proof.

For a DORA incident report, the timeline is not assembled after the fact from partial sources, it is lifted from a record that already holds the full sequence at the moment each decision was made. For resilience testing, results are reproducible by design rather than by luck. And for the ISO 42001 and NIST AI RMF governance frameworks that increasingly sit alongside DORA, the same ledger answers the AI-specific questions: which brain acted, under what authorisation, and whether that authority was still valid at the time.

The bottom line

DORA asks regulated finance to prove operational resilience, and artificial intelligence in the critical path raises the standard of proof rather than lowering it. Screenshots, editable logs, and assurances do not survive the scrutiny the regulation invites. We built Mickai so that resilience is produced as a signed, replayable record: attested before every action, hash-linked into a tamper-evident chain, signed with post-quantum cryptography, and verifiable offline on the customer's own hardware.

The shift is from telling a supervisor what your systems did to letting them replay it and check the proof themselves. That is what durable evidence looks like when the system under examination is one that reasons, and it is the standard we hold ourselves to. Micky Irons, founder and CEO of Mickai.