Audit-Ready from Day One: Evidence Management Under DORA

Evidence Is the Product of Compliance

A common misconception about regulatory compliance is that the primary deliverable is policies, frameworks, and governance documents. These matter, but they are inputs. The actual deliverable — what auditors examine, what supervisors evaluate, what determines whether an institution passes or fails — is evidence.

Evidence is proof that the institution does what it says it does. It is the test execution log that demonstrates recovery times were measured. It is the incident report with timestamps showing regulatory notification was delivered within four hours. It is the risk assessment with documented methodology and traceable inputs. It is the board minute recording the management body's review and challenge of the ICT risk framework.

Under DORA, the evidence expectation is explicit, pervasive, and demanding. Across all five pillars, the regulation repeatedly uses language that implies documentation, records, traceability, and demonstrability. Institutions that build evidence management as an afterthought discover during their first examination that the capability gap between "we do this" and "we can prove we do this" is the gap between passing and failing.

What Constitutes Evidence Under DORA

DORA does not define "evidence" as a standalone concept, but the regulation's documentation and record-keeping requirements collectively establish what auditors will expect.

Framework Documentation (Art. 6(8))

Art. 6(8) requires financial entities to "document and review at least once a year" the ICT risk management framework. The documentation itself is evidence — but so is the review record. Auditors will look for:

• The framework document with version history and approval records
• Annual review records showing who reviewed, what changed, and why
• Board or committee minutes approving the framework and its updates
• Evidence that the framework was communicated to relevant personnel

Incident Records (Art. 11(6), Art. 17-23)

DORA's incident management requirements generate some of the most scrutinised evidence. Art. 17(3) requires institutions to "record all ICT-related incidents and significant cyber threats." Art. 19 establishes specific reporting obligations. The evidence chain includes:

• Incident detection records with timestamps
• Classification decisions with documented rationale against Art. 18 criteria
• Regulatory notifications with delivery confirmation and timestamps
• Post-incident review reports (Art. 13) with root cause analysis
• Remediation tracking showing corrective actions through to closure
• Lessons learned documentation feeding back into the risk framework

The four-hour initial notification window (Art. 19(4)(a)) creates a particularly demanding evidence requirement. Auditors will examine whether the institution can demonstrate — through records, not assertions — that the timeline was met. This requires automated timestamping at each stage of the incident lifecycle.

Testing Evidence (Art. 24-27)

Resilience testing produces the most voluminous evidence, and auditors examine it with particular attention. Art. 25(4) requires that testing results and plans "be reviewed by the relevant internal functions and approved by the management body." The evidence chain includes:

• Test programme documentation with scope, methodology, and risk-proportionate justification
• Individual test plans with objectives, scenarios, and success criteria
• Test execution records with timestamps, participants, and observations
• Measured recovery times compared against stated RTO/RPO targets
• Deviation records for tests that revealed gaps (with severity classification)
• Remediation plans with owners, deadlines, and tracked progress
• Retest evidence demonstrating deviations were resolved
• Management body review and approval records

For TLPT under Art. 26, additional evidence requirements include the threat intelligence report, red team engagement records, NCA communications, and the formal attestation referenced in Art. 26(7).

Third-Party Register (Art. 28(3))

Art. 28(3) requires "a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers." This register is evidence — but it must be current, complete, and structured. Auditors will examine:

• Completeness: every ICT third-party arrangement, not just "major vendors"
• Criticality classification with documented rationale
• Contractual clause mapping against Art. 30 requirements
• Concentration risk assessment (Art. 29)
• Exit strategy documentation for critical and important arrangements
• Regular review and update records

Risk Management Records (Art. 5-16)

The risk management framework generates continuous evidence:

• Risk assessment records with methodology, inputs, and outputs
• Risk treatment decisions with rationale and approval
• Risk monitoring records showing ongoing evaluation
• Risk reporting to management body with evidence of discussion and challenge
• Change records when the framework is updated based on incidents, tests, or threat landscape changes

Evidence Integrity: The Non-Negotiable

Evidence that cannot be trusted is worse than no evidence at all. If an auditor doubts the integrity of evidence — whether records could have been altered, backdated, or fabricated — the evidentiary value collapses entirely. DORA does not explicitly prescribe evidence integrity controls, but the regulation's emphasis on documentation, records, and audit trails implicitly demands it.

Versioning and Immutability

Every piece of evidence must have:

• Version control: Who created or modified it, when, and what changed
• Immutability after approval: Once evidence is reviewed and accepted (particularly testing results and incident records), it should not be modifiable — amendments create new versions with clear lineage
• Tamper detection: Mechanisms to verify that evidence has not been altered after creation (checksums, digital signatures, hash chains)

Timestamps and Chain of Custody

Evidence must be temporally anchored:

• Creation timestamp: When was this evidence generated?
• Collection timestamp: When was it collected into the evidence management system?
• Custody chain: Who has handled, reviewed, or approved this evidence?
• Access log: Who has accessed this evidence and when?

For time-sensitive obligations (incident reporting, test execution), timestamps are not metadata — they are the evidence itself. An incident report without a reliable timestamp cannot prove compliance with the four-hour notification window.

Data Classification and Access Control

Evidence often contains sensitive information — security test results, vulnerability findings, incident details, vendor assessments. Access must be controlled based on need-to-know principles:

• Role-based access: Only authorised personnel can view, create, or approve specific evidence types
• Audit trail for access: Every access to evidence is logged and non-repudiable
• Data classification: Evidence inherits the classification of its subject matter (a penetration test report on critical infrastructure is highly confidential)

Retention: How Long to Keep What

DORA does not specify a universal retention period, but regulatory expectations and supervisory practices establish de facto standards:

These are editorial recommendations based on regulatory expectations across major EU jurisdictions. Institutions should verify retention requirements with their competent authority and legal counsel.

Common Audit Findings Related to Evidence

Based on patterns from supervisory examinations and internal audit reports across the European financial sector:

1. Evidence exists but is not retrievable. The test was conducted, the incident was managed, the risk was assessed — but the evidence is scattered across email archives, shared drives, team collaboration tools, and individual laptops. When the auditor requests evidence of a specific activity, the compliance team spends hours (or days) locating, assembling, and presenting it. This delay itself becomes a finding.

2. Evidence lacks timestamps or provenance. A test report exists, but there is no reliable record of when the test was conducted, who participated, or when the report was created. Without temporal anchoring, the evidence cannot demonstrate compliance with timeline-sensitive obligations.

3. Evidence quality is inconsistent. Some teams produce detailed, structured evidence. Others produce meeting minutes and sign-off forms. The auditor evaluates the institution's evidence management capability holistically — inconsistency signals a lack of governance over the evidence process itself.

4. Evidence is mutable after the fact. Test results, incident reports, or risk assessments that can be (or appear to have been) modified after approval undermine the entire evidence chain. If the auditor cannot trust that evidence reflects what actually happened at the time it was created, no volume of evidence will satisfy them.

5. Retention is ad hoc. Evidence from three years ago has been deleted, moved, or lost. Evidence from last quarter is in a different system than evidence from last year. There is no consistent retention policy, no lifecycle management, and no assurance that evidence will be available when needed.

6. Evidence does not map to requirements. The institution produces significant documentation but cannot easily demonstrate which DORA requirement each piece of evidence satisfies. Without a structured mapping between regulatory obligations and the evidence that satisfies them, the auditor must perform the mapping themselves — a process that invariably reveals gaps.

Building an Evidence Vault

An effective evidence management capability for DORA requires:

Taxonomy and Metadata

Define a structured taxonomy of evidence types mapped to DORA requirements:

• Governance evidence: Framework documents, policies, board minutes, approval records, training records
• Risk evidence: Risk assessments, treatment records, risk register snapshots, monitoring outputs
• Testing evidence: Test plans, execution logs, results, deviation records, remediation tracking, retest results
• Incident evidence: Detection records, classification decisions, regulatory notifications, post-incident reviews, remediation tracking
• Third-party evidence: Register entries, contract reviews, concentration analyses, exit strategies, vendor assessments
• Assurance evidence: Control effectiveness measurements, compliance scoring, continuous monitoring outputs

Each evidence item should carry structured metadata: type, linked entity (campaign, incident, vendor, risk), DORA article mapping, creation date, creator, classification, retention period, and integrity verification status.

Integrity Verification

Every evidence item should have:

• A SHA-256 hash computed at creation and verified on access
• Version history with cryptographic linking (each version references the hash of its predecessor)
• Immutability enforcement after QA review or approval
• Digital signatures for evidence packs submitted to regulators or auditors

Lifecycle Management

Evidence follows a lifecycle:

1. Creation/Collection: Evidence is generated or ingested with automatic metadata capture
2. Review/QA: Evidence is reviewed for completeness and accuracy by an authorised reviewer
3. Approval/Lock: Reviewed evidence is approved and locked against modification
4. Active retention: Evidence is maintained, accessible, and indexed for the defined retention period
5. Archival: After active retention, evidence is moved to long-term storage with reduced access
6. Disposal: After retention expiry, evidence is securely destroyed with a disposal record

Audit Pack Generation

When an auditor requests evidence, the institution should be able to produce a structured audit pack — a downloadable archive containing:

• All evidence items relevant to the audit scope
• A manifest listing every item with checksums and metadata
• A completeness report identifying any expected evidence that is missing or incomplete
• Integrity verification for every item in the pack

The ability to generate this pack in minutes rather than days is what separates audit-ready institutions from those that scramble. Platforms purpose-built for operational resilience evidence management — such as Valendir, which provides SHA-256 integrity verification, QA gates, chain-of-custody tracking, and one-click audit pack generation with manifest and checksums — transform audit preparation from a multi-week exercise into a routine operational task.

Practical Starting Points

For institutions building evidence management capabilities:

1. Start with testing evidence. Resilience testing (Pillar III) generates the most evidence and faces the most scrutiny. Build the evidence management discipline here first and extend to other pillars.

2. Automate timestamps. Every evidence item should have system-generated, non-modifiable timestamps for creation, modification, review, and approval. Human-entered dates are unreliable and auditors know it.

3. Map evidence to DORA articles. Create a matrix of DORA requirements and the evidence types that satisfy each. Use this matrix to identify gaps — requirements for which no evidence collection process exists.

4. Enforce retention from day one. Do not wait to define retention policies. Evidence lost before retention policies are established is evidence lost permanently. Start with conservative retention periods (10 years for all evidence types) and refine as regulatory expectations clarify.

5. Test your evidence retrieval. Conduct a mock audit: ask your compliance team to produce all evidence for a specific DORA article within 48 hours. The speed and completeness of the response will reveal exactly where your evidence management capability stands.

The institutions that build evidence management as a first-class capability — not an afterthought to compliance programmes — will pass their DORA examinations. Those that treat evidence as documentation to be assembled before audits will discover, under time pressure and supervisory scrutiny, that the evidence they need either does not exist, cannot be found, or cannot be trusted.

Evidence is not paperwork. It is proof. Build the proof from day one.

---

This guide provides practical guidance on evidence management for DORA compliance. It does not constitute legal or regulatory advice. Evidence retention requirements may vary by jurisdiction and institutional type. Consult your competent authority and legal counsel for institution-specific requirements.