The Evidence Chain: DORA's Implicit Requirement That Most Institutions Miss
The Invisible Pillar
DORA is structured around five explicit pillars: ICT risk management, incident management, digital operational resilience testing, third-party risk management, and information sharing. Evidence management is not listed among them. There is no "Article 26: Evidence Requirements." No Regulatory Technical Standard dedicated to evidence governance.
Yet evidence is the substrate on which every other pillar depends. A testing programme without documented results is an assertion, not a programme. An incident report without supporting data is a narrative, not compliance. A third-party risk assessment without evidence of due diligence is a checkbox, not risk management.
The numbers confirm this gap. Aggregated data from internal audit and supervisory examination findings across European financial institutions indicates that approximately 60% of adverse findings relate to missing, incomplete, or unverifiable evidence — not to the absence of controls themselves, but to the inability to prove those controls exist and function.
Institutions are doing the work. They are running tests, managing incidents, assessing third parties. What they are not doing — at scale, consistently, and with integrity — is preserving the evidence that proves they did.
Where DORA Demands Evidence (Without Saying So)
A systematic reading of DORA reveals evidence requirements embedded in virtually every substantive article. The following mapping extracts the implicit evidence obligations from the regulation text.
Pillar I: ICT Risk Management (Art. 5-16)
| Article | Requirement | Implicit evidence |
|---|---|---|
| Art. 5(2) | Management body approves ICT risk framework | Board minutes, approval records, dated framework document |
| Art. 5(4) | Management body follows specific ICT training | Training completion records, attendance logs, curriculum documentation |
| Art. 6(5) | Framework reviewed at least annually | Dated review report, change log, approval of updated framework |
| Art. 8 | Identification of all ICT-supported business functions | Asset register, dependency mapping, criticality classifications |
| Art. 9(4)(c) | Digital operational resilience awareness programmes | Training materials, completion rates, assessment results |
| Art. 11 | ICT business continuity plans | Plan documents, test results, update history |
| Art. 12 | Backup policies and restoration testing | Backup logs, restoration test records, verified RTO/RPO |
| Art. 13 | Learning and evolving | Post-incident review reports, implemented improvements, trend analysis |
| Art. 14 | Annual reporting to management body | Board report, presentation materials, meeting minutes |
Pillar II: Incident Management (Art. 17-23)
| Article | Requirement | Implicit evidence |
|---|---|---|
| Art. 17(1) | Incident management process | Process documentation, decision records, escalation logs |
| Art. 18 | Classification of ICT incidents | Classification records with criteria applied, severity justification |
| Art. 19 | Reporting major incidents | Filed notification records, timestamps, authority acknowledgments |
| Art. 20 | Content of incident reports | Supporting data: scope, impact assessment, timeline, root cause |
| Art. 23(2) | Client notification for payment services | Notification records, content, timing, channel documentation |
Pillar III: Testing (Art. 24-27)
| Article | Requirement | Implicit evidence |
|---|---|---|
| Art. 24(1) | Sound and comprehensive testing programme | Programme document, scope definition, schedule, methodology |
| Art. 25(1) | Testing produces "adequate evidence" | Test reports, findings, screenshots, logs, metrics |
| Art. 25(3) | Remediation of identified deficiencies | Remediation plans, completion evidence, retest results |
| Art. 26 | Advanced testing (TLPT) | TLPT report, red team documentation, control point evidence |
| Art. 27 | Requirements for testers | Tester qualification records, independence attestation |
Pillar IV: Third-Party Risk (Art. 28-30)
| Article | Requirement | Implicit evidence |
|---|---|---|
| Art. 28(3) | Register of information on ICT third parties | Complete register, update history, submission records |
| Art. 28(5) | Risk assessment before entering arrangements | Due diligence documentation, risk assessment records |
| Art. 28(8) | Exit strategies | Strategy documents, feasibility assessments, test results |
| Art. 29 | Concentration risk assessment | Concentration metrics (HHI), analysis documentation |
| Art. 30 | Key contractual provisions | Signed contracts, clause compliance verification |
The Evidence Chain of Custody
Evidence is not merely a document or file. It is a chain — from creation through collection, quality assurance, storage, retrieval, and presentation. A break at any point in this chain undermines the evidentiary value of the entire artifact.
The Five Links
1. Creation. Evidence is created when a control operates, a test executes, or a decision is made. The creation event must capture: what happened, when, who performed the action, and what system produced the record. Evidence created without a timestamp is undatable. Evidence without an actor is unattributable. Evidence without a system context is unverifiable.
2. Collection. Created evidence must be collected — transferred from the operational system where it was generated to the evidence management system where it will be governed. Collection must preserve integrity: the evidence in the management system must be bit-for-bit identical to the evidence at the point of creation. A hash value (SHA-256) computed at creation and verified at collection provides cryptographic proof that the evidence was not altered during transfer.
3. Quality assurance. Collected evidence must be reviewed for completeness, accuracy, and relevance. A test report that documents "test completed successfully" without including test parameters, execution logs, and measured results is incomplete. A quality assurance gate — where evidence is reviewed against expected criteria before being accepted — prevents incomplete evidence from entering the chain.
4. Storage. Accepted evidence must be stored with integrity protection, access control, and retention management. Integrity protection means the stored evidence cannot be modified without detection. Access control means only authorized personnel can view, download, or export the evidence. Retention management means the evidence is retained for the required period and deleted when the retention obligation expires.
5. Presentation. When evidence is needed — for internal audit, supervisory examination, or board reporting — it must be retrievable, presentable, and verifiable. An examiner should be able to request evidence for a specific control, receive a package that includes the evidence artifact and its chain-of-custody metadata, and verify that the evidence has not been altered since collection.
Integrity Verification
Each evidence artifact should carry integrity metadata:
| Metadata field | Purpose | Example |
|---|---|---|
| SHA-256 hash | Cryptographic integrity verification | a7f3b4c8d... |
| Created at | When the evidence was generated | 2026-01-15T14:30:00Z |
| Created by | Who or what system generated it | user:analyst-042 or system:backup-monitor |
| Collected at | When it entered the evidence management system | 2026-01-15T14:35:00Z |
| QA status | Whether it passed quality review | COMPLIANT / REJECTED |
| QA reviewer | Who reviewed it | user:qa-lead-017 |
| Locked at | When it was made immutable (if applicable) | 2026-01-16T09:00:00Z |
| Retention until | When it can be deleted | 2036-01-15 |
Evidence that is locked (made immutable) after QA review cannot be modified — only superseded by a new version. This immutability is critical for audit-relevant evidence: if an examiner requests the recovery test results from January 2026, the institution must be able to prove that the results presented today are identical to the results recorded in January 2026.
The 60% Problem: Why Evidence Findings Dominate
Six categories of evidence failure account for the majority of audit findings:
1. Evidence never created (25% of findings). The control operated, but no record was generated. A backup completed successfully, but the backup system was not configured to produce a completion report. A board meeting discussed ICT risk, but the minutes did not document the specific DORA-required decisions. The control existed; the evidence did not.
2. Evidence created but not collected (15%). The evidence exists in operational systems — log files, email threads, meeting notes — but was never collected into a governed evidence management system. When the auditor asks for the evidence, the team must reconstruct it from dispersed sources, producing a document that appears assembled after the fact rather than captured in real time.
3. Evidence incomplete (20%). The evidence was created and collected, but it is missing critical elements. A test report documents the pass/fail result but not the test parameters, execution environment, or measured recovery time. An incident report documents the timeline but not the classification criteria applied or the regulatory notifications sent.
4. Evidence integrity unverifiable (10%). The evidence exists, but there is no mechanism to verify it has not been modified since creation. A Word document in a shared drive with a "last modified" date that postdates the event it documents is not integrity-protected evidence. Without hashing and chain-of-custody metadata, the evidence is unverifiable.
5. Evidence unretrievable (5%). The evidence was created, collected, and stored — but cannot be found when needed. Naming conventions are inconsistent, search capabilities are limited, and the relationship between the evidence and the control it supports is not indexed.
6. Evidence retention expired (5%). The evidence existed and was stored correctly, but was deleted before the retention period expired — often because the retention policy was not applied consistently or because the evidence was stored in a system with a shorter retention period than required.
Building an Evidence-Ready Programme
An evidence management programme that prevents the 60% failure rate requires three capabilities: automated evidence creation, structured collection, and governed storage.
Automated Evidence Creation
The single most effective intervention is configuring operational systems to generate evidence automatically. Systems that already execute controls — backup systems, monitoring platforms, testing tools, workflow engines — should be configured to produce structured evidence records as a byproduct of normal operation.
Examples:
- Backup systems produce completion reports with timestamp, scope, success/failure, and data volume
- Vulnerability scanners produce reports with findings, severity, and affected assets
- Workflow engines produce state transition logs with actor, action, timestamp, and before/after states
- Meeting recording systems produce attendance logs and action item records
The key principle: evidence creation should be a side effect of control operation, not a separate manual activity. When evidence requires manual effort, it will eventually be skipped — and the missing evidence will become an audit finding.
Structured Collection
Automated evidence should flow into a centralized evidence management system through defined collection pipelines. Each pipeline should:
- Receive evidence from the source system (API, file drop, webhook)
- Validate the evidence against expected schema (required fields present, format correct)
- Compute and record the integrity hash
- Link the evidence to the relevant control, asset, or entity
- Route the evidence to the appropriate quality assurance queue
Manual evidence — board minutes, training records, risk assessment documents — should enter through a standardized upload process that enforces the same metadata requirements as automated pipelines.
Governed Storage
The evidence store must provide:
- Immutability: once evidence is accepted and optionally locked, it cannot be modified
- Access control: role-based access with audit logging of all evidence retrievals
- Retention management: automated retention enforcement based on evidence type and regulatory requirement
- Search and retrieval: indexed search by control, entity, date range, and evidence type
- Export capability: ability to produce audit packs — structured ZIP archives with evidence, manifest, and integrity checksums — for supervisory examination
The Audit Pack: Evidence Presentation at Scale
When a supervisor requests evidence — whether through a formal examination, a thematic review, or an ad-hoc information request — the institution must produce a structured package that demonstrates compliance. The audit pack is that package.
A well-structured audit pack contains:
| Component | Purpose |
|---|---|
| Manifest | Schema version, generation date, scope, item counts, checksums |
| Evidence index | List of all evidence items with metadata, linked controls, and chain-of-custody records |
| Evidence artifacts | The actual documents, reports, logs, and records |
| Missing items list | Explicitly identified gaps where evidence should exist but does not |
| Integrity verification | SHA-256 checksums for all artifacts, verifiable against the manifest |
The missing items list is critical. An audit pack that presents only the evidence that exists — without identifying the evidence that should exist but does not — creates the appearance of completeness while hiding gaps. A transparent missing items list demonstrates governance maturity: the institution knows what evidence it should have, tracks what it does have, and acknowledges what it lacks.
Actionable Takeaways
- Map your evidence obligations. Use the article-by-article mapping in this analysis to identify every DORA provision that implicitly requires evidence. Compare this map against your current evidence inventory. The gap is your evidence risk.
- Automate evidence creation. Configure operational systems to generate evidence as a byproduct of control operation. Every backup, test, scan, and workflow transition should produce a structured evidence record without manual intervention.
- Implement integrity hashing. Every evidence artifact should carry a SHA-256 hash computed at creation and verified at collection. When an examiner asks whether the evidence has been altered, the answer must be cryptographically provable — not anecdotal.
- Build the quality assurance gate. Evidence that enters the management system without review is evidence that may be incomplete, inaccurate, or irrelevant. A QA gate — where evidence is reviewed against completeness criteria before acceptance — prevents the 20% of findings caused by incomplete evidence.
- Practice the audit pack. Generate a mock audit pack quarterly. Test whether it can be produced within 48 hours, whether it is complete, whether the missing items list is accurate, and whether the integrity checksums verify. The institution that practices will perform; the institution that does not will scramble.
This analysis reflects DORA Regulation (EU) 2022/2554 evidence requirements as implicit across multiple articles. Evidence management practices described represent industry-aligned approaches to audit readiness.