How to Prove DORA Compliance to a Supervisor

The vendors all tell you to “be audit-ready.” None of them answer the question a supervisor actually asks. In 2026, with the tolerance period over, that question has a very specific shape — and it is not about your policies.

Ask a compliance vendor how to prove DORA compliance and you will be told to keep good documentation and be ready for an audit. That is not an answer. It is the question restated as advice. The regulation has been in application since 17 January 2025, the initial period of supervisory forbearance is over, and national competent authorities are now running active reviews. The question is no longer whether you can produce a binder. It is whether, when a supervisor names one operation and one provider, you can show that the control worked, when, and who signed for it — before the meeting ends.

I want to be concrete about what that looks like, because the gap between “we have a policy” and “we can prove it” is where firms are being caught.

What a supervisor is actually testing

Supervisors are not checking whether controls exist. They are checking whether controls work, are maintained, and are evidenceable on demand. In practice that means a review is reproducible: someone outside your team should be able to read your evidence and understand what happened, why, and who approved it. Auditors ask for “evidence” and mean something narrower than most firms hear — a small, coherent set of records that line up across policy, data, ownership, and execution. A thousand files with unclear relationships is worse than forty that reconcile.

The recurring finding across pre-application reviews is blunt: policies that describe controls which do not exist in practice. If your recovery plan states a four-hour recovery time objective and your last real test took three days, the written plan does not help you — it documents the gap. The paperwork becomes evidence against you.

The Register of Information is the live instrument

Nowhere is this clearer than the Register of Information under Article 28. It is not an annual filing you assemble and forget; the ESAs have been explicit that it is a live supervisory dataset, and authorities can request it outside the annual cycle. The first submission cycle exposed how hard “evidenceable” really is. Across the majority of banks, a third to a half of contract records had at least one mandatory field missing or invalid; roughly a third of submissions had missing or invalid legal entity identifiers; by one count, fewer than one in fifteen firms passed every data-quality check.

The register is fifteen inter-linked templates that form a relational model — change one table and the others must stay consistent. That relational integrity is precisely what lets supervisors cross-reference automatically: your record of a provider against that provider’s own filing, against your peers’ filings. A register that does not match reality is the single failure mode supervisors are already citing by name. You cannot talk your way past a data inconsistency that a machine flagged before the reviewer arrived.

The incident chain, and where it breaks

The reporting cadence is fixed: an initial notification within 24 hours of becoming aware (or within four hours of classifying an incident as major, if that comes later), an intermediate report within 72 hours, and a final report within one month. The common findings are not about the deadlines themselves — they are about the seam between awareness and action: delay between first awareness and the initial notification, incidents misclassified in either direction, and final reports that never establish root cause. Each of those is a proof failure, not a process failure. The process ran; it just left nothing behind that a supervisor can trust.

It comes down to your data model

Strip away the pillars and the artefacts and DORA proof reduces to one operational test: can you answer, by tomorrow morning, which function, which provider, what tolerance, whether you were inside it, who owns the control, and who signed off? That is the same standard I wrote about in the context of APRA’s CPS 230 — a proof standard wearing a policy standard’s clothes. If those answers live in people’s heads and spreadsheets, you do not have a compliance problem, you have a data-model problem, and no amount of policy drafting fixes it.

The upside is that the capability generalises. The same evidence discipline — obligations mapped to controls, controls traced to records, records owned and signed — answers more than one regulator. It is the through-line from DORA to NIS2 to the Cyber Resilience Act, and it is why I treat evidence as an architecture problem rather than a documentation exercise. I have set out that model in full on the evidence and assurance page.

DORA’s clock is one of several running simultaneously — see the board’s full incident-reporting map across every regime that might trigger at once.

Where this needs to extend into a genuine, ongoing third-party risk programme, that’s covered under DORA ICT Third-Party Risk.

If a supervisor asked you to prove one control tomorrow and you are not certain you could, that uncertainty is the finding. A technology control assessment tells you where the gaps are before a regulator does; as a fractional CTO I build the capability and stand behind it. See how engagements are scoped.