Regulation
//
18 Jun 2026

What DORA's four-hour clock really asks of your AI

DORA gives financial entities in the EU a short window to report a major ICT incident. The exact clocks and thresholds are for your counsel to read. But the shape of the obligation is not in dispute: when something serious happens, you have hours, not weeks, to produce an account a regulator will accept. That account has to say what happened, when, to what, with what effect. The writing is the easy part.

Proving what you wrote is true, from records you can stand behind, is where the hours go.

What DORA asks, at a high level

DORA is about operational resilience for financial entities and the ICT that supports them. Three themes matter for anyone running AI systems inside that perimeter. Keep operating through disruption. Report major incidents quickly and keep the account current as you learn more. And oversee the third parties you depend on, so a failure in a vendor or a model provider is still your incident to explain.

None of that is legal advice, and this article does not interpret DORA as a binding obligation for your situation; the specifics belong to your compliance and legal teams. The engineering question underneath is more durable: can you produce a defensible account of an agent's actions inside a tight window, without a scramble?

Why after-the-fact reconstruction fails under a clock

The default posture is reconstruction. When an incident is called, someone pulls application logs, someone exports the audit trail from a SaaS tool, someone checks what the agent actually did versus what it was asked. Then everyone lines up timestamps from clocks that disagree, and explains the gaps where nothing was logged. This is called an incident review, and everyone in the room would rather be somewhere else.

This works, slowly, when there is no deadline. Under a reporting clock it fails in predictable ways. Logs get rotated or were never captured at the granularity you now need. The AI part of the stack is the worst offender: a prompt, a tool call, a retrieved document, and a model response are often scattered across services never meant to be read together. Reconstruction spends the time you do not have to produce your weakest artifact: a narrative built backward from the outcome, which a reviewer is entitled to distrust.

What "ready evidence" looks like

The alternative is to produce the record at the moment of the action. When an agent takes a step, the system records what it did, what it acted on, and the decision that allowed it, and seals that record then and there. It exists before anyone knows whether the action will matter, which is what makes it credible. Three properties matter:

  • It is contemporaneous: created at the moment of the action, so its timestamp and content are not reconstructed.
  • It is tamper-evident: any later change is detectable. Not tamper-proof, which no honest system claims, but checkable: a reviewer can tell if a record was altered after sealing.
  • It is verifiable offline: hand someone the record and they recompute the proof themselves, with no call back to us and no trust in our infrastructure.

In Athena, each sealed record is canonicalized to a stable byte form (RFC 8785) and signed with ML-DSA-65 (FIPS 204). Checking a record is an offline recomputation over that single record: no network, no transparency log, no shared service you have to trust. If the bytes change, the signature fails to verify, and anyone with the public key can see it.

Mapping evidence to obligations without hand-wiring it

A sealed record is worth little to a compliance team if turning it into an answer means a bespoke integration for every framework. Translating between record and obligation by hand does not scale past the first audit.

Athena uses a reusable crosswalk in OSCAL, the open control-description format, to map the evidence a sealed record carries to the controls a given regime cares about. The same record can be presented against DORA-style resilience and incident questions, or against ISO 27001, SOC 2, or NIS2, without reshaping it each time: write the crosswalk once for a control family, reuse it across records. When a reviewer asks "show me the evidence for this obligation," the mapping already exists, pointing at records sealed when the action happened.

The honest boundary

Athena produces candidate evidence and a defensible record. It does not issue legal opinions, interpret DORA for your entity, or certify that you are compliant. No software can grant that. What it does is narrower and, under a clock, more useful: it makes sure the record you need already exists, already sealed, already checkable, before the incident forces you to reach for it. Whether that record satisfies a specific obligation is a judgment for your auditors and counsel; we give them something solid to judge.

The four-hour clock tests whether your evidence exists before you need it. If your record has to be assembled after the incident, from logs never meant to be read together, the clock will beat you. If it was sealed as each action happened, and a reviewer can check it offline, the report is transcription rather than archaeology. Archaeology is a fine discipline, and a poor one to practise with a regulator waiting.

Next steps

Want this on your own workflow?

Book a fixed-scope pilot, or read how Athena binds, seals and verifies the record.

//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
Fixed-scope pilot

/ Start with a fixed-scope pilot.
Prove it on your own workflow.
/

Four weeks, one workflow of yours, all three modules. You leave with AI running on real work and sealed records your own auditor can verify, whether or not you continue.

Book a demo
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE
//
ACCOUNTABLE
&
VERIFIABLE
//
PROVABLE
&
SEALED
//
SOVEREIGN
&
OFFLINE
//
ANSWERABLE
&
AUDITABLE