DORA testing evidence management is the practice of capturing, organising and protecting records that show how an organisation tested its digital operational resilience and handled the results. Under the EU Digital Operational Resilience Act (DORA), this evidence helps a financial entity demonstrate that its resilience testing programme is risk-based, governed and followed through. DORA does not prescribe one evidence repository or file format.
What DORA testing evidence management covers
DORA requires financial entities to establish and maintain a digital operational resilience testing programme as part of their information and communication technology (ICT) risk management. The programme should use a risk-based approach and cover appropriate systems, tools and processes, including those supporting critical or important functions.
Evidence management provides a traceable record of the programme in operation. A useful evidence set can include the test objective and scope, the risk or requirement being addressed, approvals, test design, system and environment details, execution records, results, defects, remediation decisions and retest outcomes. For automated tests, execution logs and reports can be linked to the test definition, code or configuration version, and pipeline run.
The records should let a reviewer understand what was tested, when it was tested, under which conditions, what happened and how the organisation responded. For example, a passing result without the tested release version or environment details may be difficult to interpret after a system change.
How to manage evidence through the test lifecycle
Start by linking each planned test to the relevant ICT risk, service, system or resilience objective. That relationship makes gaps easier to identify: a critical service with no recent test evidence needs investigation, even if the overall test count looks healthy.
During execution, capture context alongside results. Record environment identifiers and material configuration, test data references, timestamps, execution identity, tool or script versions, and any deviations from the plan. Where records contain customer or security-sensitive information, restrict access and use appropriate masking or redaction.
After execution, classify findings, assign owners and record decisions. A failed test should link to its defect or risk record, remediation evidence and any retest. If the organisation accepts residual risk, retain the decision, rationale, approver and review conditions. Maintain an audit trail for changes to evidence and metadata so that later reviewers can distinguish original results from amended records.
Retention periods should follow the organisation's applicable legal, regulatory, contractual and internal requirements. DORA does not set one general retention period for all testing evidence. Define ownership, access controls, retention and disposal rules in the evidence process, and check that stored records remain readable and retrievable.
Practical example: payment service failover
A bank tests whether a payment service can continue processing when a dependency becomes unavailable. The evidence record identifies the service and resilience objective, the approved scenario, the release and environment, the dependency failure introduced, and the expected behaviour. It links to execution logs, observed payment outcomes, any reconciliation checks, and the recovery time recorded by the test team.
If payments are delayed or duplicated, the record links the finding to its owner and remediation. A later retest documents the changed configuration, repeats the relevant assertions and records whether processing recovered as expected. A reviewer can follow the chain from risk and scenario through result to closure without relying on a detached screenshot or an unreferenced report.
How to verify the evidence process
Sample records from recent tests and check that each can be traced from its risk or objective to the execution result and any follow-up action. Confirm that a person with appropriate access can retrieve the underlying records and understand the test conditions. Check that failed tests have a documented disposition, and that changes to evidence leave an attributable audit trail.
This process supports DORA compliance and audit review, while helping testing teams identify missing coverage and unresolved resilience weaknesses. Related practices include banking test evidence traceability and banking audit trail testing.
Frequently asked questions
Does DORA require every resilience test to be performed by an external provider?
No. DORA allows testing by internal or external parties, while requiring financial entities to ensure testing is carried out by independent parties. When internal testers perform the work, the entity must provide sufficient resources and avoid conflicts of interest in test design and execution.
Can one test record support evidence for several DORA-related risks?
Yes, if the record clearly identifies each risk or objective it addresses and explains how the test results apply to each one. Keep the scope and limitations visible so a shared record does not imply coverage that the test did not provide.
How should a bank handle evidence supplied by an ICT service provider?
The bank should assess whether the provider's records are relevant, sufficiently detailed and suitable for its own oversight. It remains responsible for understanding its ICT risks, so provider reports should be connected to the bank's affected services, risk assessments and follow-up decisions.