MICKAI®ArticlesDORA and the document trail your …
Article · 31 July 2026

DORA and the document trail your firm must be able to prove

DORA turns operational resilience into a documentary obligation, and the firms that can produce a provable trail of registers, contracts and incident records on demand are the ones that will face inspection calmly.

Author
Micky Irons
Published
31 July 2026
Follow Micky Irons
LinkedInX
dora-compliancefinancial-servicessovereign-aioperational-resilienceaudit-trail
DORA and the document trail your firm must be able to prove

DORA requires financial firms to prove operational resilience on paper, not merely to practise it, and that proof takes the form of a document trail (registers, contracts, incident logs, test results and board approvals) that a regulator can ask to inspect at any time. The firms that struggle under it will not be the ones with weak controls. They will be the ones that cannot produce the evidence of strong ones.

The EU Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It reaches banks, insurers, asset managers, payment institutions and a long list of other financial entities, and the European supervisory authorities, including EIOPA, oversee its rollout. The regulation's stated aim is that financial entities can withstand, respond to and recover from ICT disruption, and can evidence that ability with registers and documentation that competent authorities are entitled to inspect. Responsibility sits with the management body, not the IT department, which is why the documentation question has moved from the compliance team's agenda to the board's.

What does DORA actually require us to document?

DORA expects documentary evidence across five areas: ICT risk management, incident handling, digital operational resilience testing, third party risk and information sharing arrangements. Each area produces artefacts that must exist, stay current and be producible on request. In practice the evidence base includes:

  • The ICT risk management framework itself, with its periodic reviews and board approvals
  • The register of information covering every contractual arrangement with every ICT third party service provider
  • Incident classification records, logs and the reports filed for major incidents
  • Resilience testing plans, results and the remediation that followed
  • Exit strategies and contingency plans for critical ICT providers
  • Evidence that the management body has reviewed, challenged and approved all of the above

None of this is exotic. It is contract review, cross referencing, log keeping and evidence assembly, which is to say it is document work, done continuously, at volume, under inspection.

Why is the register of information the hard part?

The register of information is the hard part because it must map every ICT contractual arrangement the firm holds, including the subcontracting chains beneath them, and it must be accurate whenever the competent authority calls for it. Behind each register entry sits a contract, a criticality assessment, an exit plan and, for arrangements supporting important functions, evidence of ongoing oversight. Keeping the register reconciled against the agreements it summarises is exactly the kind of patient cross referencing that human teams do slowly and machines do well, provided the machine can be trusted with the documents.

Can we put DORA evidence through a cloud AI?

You can, but you would be creating the very thing DORA asks you to control: a new ICT third party dependency, which itself belongs in the register you are trying to manage. There is a second problem beyond the circularity. Contract registers, incident records, network documentation and exit plans are among the most sensitive documents a financial firm holds, because together they describe precisely where the firm is fragile. Routing them through an external AI service means an external party processes your map of your own weaknesses. That is a hard position to defend comfortably in front of a risk committee, and a harder one to defend in front of a supervisor.

How does on premise review change the evidence picture?

Review that runs on hardware the firm owns changes the evidence picture in two ways at once: the documents never leave the estate, and every action taken on them is sealed into a tamper evident record as it happens. Our document review capability reads the contract packages behind a register, cross references each entry against the underlying agreements and certificates, drafts the paperwork a supervisor would expect to see, and holds anomalies (a lapsed subcontractor disclosure, an exit plan that no longer matches the contract it covers) for a person to resolve. Consequential actions wait for a person's clearance. Nothing executes on its own authority.

The seal matters as much as the review. Every action is written to the Open Audit Record, a cryptographically signed, post-quantum, tamper evident record that is sealed before the action runs and can be verified offline years later. A conventional system logs what happened after the fact, and post incident forensics routinely finds such logs incomplete or editable. A sealed record is different in kind. It is evidence, not recollection.

A regulator does not ask whether you managed the risk. It asks you to show the record. The firms that answer fastest are the ones whose record was sealed as the work happened, not reconstructed after the request arrived.

Mickai

What should we do before the next evidence request arrives?

Treat the request as a certainty and build the record now, because supervision under DORA is only tightening. The oversight framework for critical ICT third party providers is standing up, competent authorities can call for registers and documentation, and the UK runs its own operational resilience regime with the same underlying expectation: show us, do not tell us. Firms that keep their evidence continuous, cross referenced and sealed will answer a supervisory request in days. Firms that reconstruct it will spend far longer doing so, under scrutiny, at the worst possible time.

We think the direction of travel is clear across every regulated sector, not just finance: accountability regimes are converging on provable records rather than asserted compliance. That is why we build for the hardest version of the requirement, sovereign review on the customer's own hardware, air gapped where the firm demands it, with a sealed audit record designed to outlast the systems that wrote it. The document trail is becoming the compliance programme itself, and the firms that treat it that way will be the calm ones in the room when the inspection letter lands.

Frequently asked questions

When did DORA start applying?

DORA has applied since 17 January 2025. From that date, in scope financial entities are expected to meet its requirements on ICT risk management, incident reporting, resilience testing and third party oversight, and to hold the documentation that evidences them.

Does DORA apply to UK financial firms?

DORA is EU law, so it applies to a UK group's EU entities and to firms doing in scope business in the EU. The UK operates its own operational resilience regime under the FCA and PRA with a similar evidential expectation, so the discipline of a provable document trail serves firms on both sides of the Channel.

Is a cloud AI service an ICT third party under DORA?

In substance, yes. An external AI service that processes a firm's documents is an ICT service arrangement, which belongs in the register of information with the risk assessment and oversight that entails. Software that runs entirely on the firm's own hardware does not add an external processing dependency, which is a materially simpler posture to document and defend.

Can software make a firm DORA compliant?

No. Compliance belongs to the firm and its management body, and no vendor can carry that responsibility for it. What software can honestly do is keep the evidence continuous, cross referenced and provable, so the distance between a supervisory request and a complete, defensible answer stays short.

What is MICKAI?

MICKAI is a Sovereign Intelligence Operating System (a SIOS) that runs entirely on the customer's own hardware, on premise and air gapped, so no document or prompt ever leaves the building. Every consequential action is sealed into the Open Audit Record, a cryptographically signed, post-quantum, tamper evident record that is sealed before an action runs and verifiable offline. The system comprises 87 studios, with ten production ready at launch and 77 in development, and its architecture is protected by 104 filed UK patent applications across 2,340 claims, filed rather than granted.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/dora-document-trail-financial-services. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles