Practical guide ·

DORA: how do we demonstrate that our controls work?

A policy describes the intended way of working. Evidence shows what happened within a defined scope and period. A useful DORA review connects the requirement, owner, control, record and corrective action. Begin with one important service and follow that chain before collecting documents across the organisation.

Why does a folder of policies leave questions unanswered?

Imagine a recovery procedure naming a system, target time and responsible team. The document looks complete. During a review, nobody can show when the last test ran, which dependencies it included or whether the business accepted the recovered service. The missing item is operational evidence.

DORA addresses governance, ICT risk, continuity and testing. Apply its requirements to the entity’s actual scope. A document library cannot by itself establish that these arrangements operate effectively.

How do we build an evidence chain?

Choose a critical or important function, identify the supporting ICT service and name the control owner. Ask what record would allow another person to verify the action. A screenshot may show a setting at one moment; it usually cannot demonstrate that a recurring process ran throughout the review period.

Keep the source, date, scope and owner for each record. Document exceptions alongside successful results. A failed test followed by correction and retesting can be more informative than an unsupported declaration that everything is satisfactory.

Illustrative evidence map — not a complete DORA checklist
AreaEvidenceRemaining question
AccessDated review and resolved exceptionsWhich accounts were excluded?
RecoveryTest record and business acceptanceWere dependencies included?
IncidentsDecision log and exercise findingsCould the deputy act?
SuppliersReview linked to an actual serviceWhat happened to the gaps?

What can a recovery test reveal?

In an illustrative test, a finance application is restored and the team measures when its server starts. The business then discovers that an external data feed is unavailable. The technical activity finished, but the agreed business outcome did not.

The report should show both observations, the dependency owner and the follow-up decision. Define acceptance in advance: which transaction must a user complete, with which data, and who confirms the result?

How much evidence is enough?

Agree the period and coverage before collecting files. Sampling can support a review, but its limits must remain visible. Do not generalise from one account, office or test to the entire estate without a basis.

Maintain an index pointing to authoritative records instead of copying sensitive material into several folders. Limit access and remove unnecessary personal data. A reviewer should be able to understand the conclusion and trace its supporting record. Assign deadlines to gaps and keep the accepted residual risk visible to the responsible manager.

Explore in detail: The DORA Register of Information: what goes in it and where it goes wrong · You supply a bank or an essential entity. What they will ask of you.

How Dyasol can help

Dyasol’s readiness and evidence pack identifies gaps, reviews the agreed records and organises available evidence. Implementation and independent certification remain separate from the assessment.

Explore the readiness and evidence pack

Sources and context

Examples are illustrative. Practical recommendations should be adapted to the organisation.

General information as of 13 September 2026. Specific obligations depend on the entity, activity and applicable law.