DORA Evidence Index Template for EU Fintechs
DORA evidence index template for EU fintechs: how to organise ICT risk, incidents, testing, suppliers, board reporting and remediation evidence for review.
In this article ↓
- Short answer
- Why fintechs need an evidence index
- Evidence index template
- Example evidence index
- Scope evidence
- Governance evidence
- ICT risk evidence
- Incident evidence
- Testing and BCDR evidence
- Third-party evidence
- How to maintain the index
- Common mistakes
- Mistake 1: Creating a folder list instead of an evidence index
- Mistake 2: No owner
- Mistake 3: No review date
- Mistake 4: Mixing drafts with approved records
- Mistake 5: Sending the index without supporting artefacts
- Related reading
- FAQ
- What is a DORA evidence index?
- Is an evidence index required by DORA?
- Can a small fintech use a spreadsheet?
- What should be included first?
- Who should own the evidence index?
- How often should the index be reviewed?
- Primary sources
- Bottom line
Last reviewed: 5 May 2026
Key takeaways
- A DORA evidence index shows where current proof lives across ICT risk, incidents, suppliers, testing and board oversight.
- It prevents evidence from being scattered across policies, tickets, folders and owner inboxes.
- Supervisors and partners ask for current records, owners, review dates and remediation status.
- Fastest path: list required artefacts -> assign owners -> mark status -> review stale or missing evidence.
Short answer
A DORA evidence index is a review map.
It tells a supervisor, partner bank, auditor, investor or board member where the evidence lives, who owns it, when it was last reviewed and which DORA area it supports.
For an EU fintech, the evidence index should cover at least:
| Evidence area | What the index should point to |
|---|---|
| Scope | Entity, licence, NCA and critical-function mapping |
| Governance | ICT risk framework, board packs, approvals and decisions |
| ICT risk | ICT risk register, control map, risk acceptances and remediation |
| Incidents | Incident workflow, classification log, timelines and reports |
| Testing | Test plan, results, findings and closure evidence |
| BCDR | Continuity plans, recovery objectives and test reports |
| Third parties | Register of Information, supplier reviews and contract tracker |
| Remediation | Gap register, owners, due dates and closure records |
The index is not the evidence itself. It is the route into the evidence.
Why fintechs need an evidence index
DORA evidence usually exists before it is organised.
A payment institution may have incident records in a ticketing system, supplier reviews in procurement folders, ICT risks in a spreadsheet, board decisions in minutes, BCDR records in engineering documents and contracts in legal storage.
That becomes a problem when someone asks:
Show us your DORA evidence.
Without an index, the team sends a folder dump. With an index, the team sends a structured map.
Evidence index template
Use a simple table. The index should be understandable by compliance, technology, management and external reviewers.
| Field | Purpose |
|---|---|
| Evidence ID | Stable reference, e.g. DORA-GOV-001 |
| DORA area | Governance, ICT risk, incidents, testing, third parties, BCDR |
| Evidence name | Plain-language artefact name |
| Description | What the artefact proves |
| Owner | Accountable person or function |
| Storage location | Link or repository path |
| Last reviewed | Date of last meaningful review |
| Status | Current, stale, draft, missing, remediation open |
| Related risk/gap | Link to risk register or gap tracker |
| Next action | What needs to happen next |
For smaller fintechs, this can start as a spreadsheet. For larger entities, it can sit in a GRC tool. The structure matters more than the tool.
Example evidence index
| ID | Area | Evidence | Owner | Status | Last reviewed |
|---|---|---|---|---|---|
| DORA-SCOPE-001 | Scope | Entity and licence scope note | Compliance | Current | 2026-05-01 |
| DORA-GOV-001 | Governance | ICT risk management framework | Risk / CISO | Current | 2026-04-25 |
| DORA-GOV-002 | Governance | Quarterly ICT risk board pack | vCISO / COO | Current | 2026-04-30 |
| DORA-RISK-001 | ICT risk | ICT risk register | CISO / CTO | Current | 2026-04-29 |
| DORA-INC-001 | Incidents | Incident classification workflow | Security / Ops | Current | 2026-04-20 |
| DORA-INC-002 | Incidents | Incident decision log | Security / Legal | Needs update | 2026-03-15 |
| DORA-TPR-001 | Third parties | Register of Information | Procurement / Risk | Current | 2026-04-26 |
| DORA-TPR-002 | Third parties | Article 30 contract gap tracker | Legal / Risk | Remediation open | 2026-04-26 |
| DORA-TEST-001 | Testing | Annual resilience test plan | Security / CTO | Current | 2026-04-18 |
| DORA-BCDR-001 | BCDR | Backup restoration test report | Engineering | Current | 2026-04-12 |
This table is deliberately compact. The supporting evidence can be detailed, but the index should remain scannable.
Scope evidence
Scope evidence answers whether the entity knows why DORA applies and which services matter.
| Evidence | What it proves |
|---|---|
| Legal entity map | Which regulated entity is in scope |
| Licence register extract | Authorisation and entity type |
| NCA mapping | Which competent authority route is relevant |
| Critical-function map | Which services create resilience priority |
| ICT dependency map | Which systems and providers support those services |
This is the first section a reviewer should see. Without scope, the rest of the evidence is hard to interpret.
Building a DORA evidence index from scattered records?
A 15-minute call can identify which artefacts to prioritise first - no pitch, just inspection-ready gaps.
Book a free 15-min call →Governance evidence
Governance evidence shows that ICT risk is not only a technology issue.
| Evidence | What it proves |
|---|---|
| ICT risk management framework | Control model exists and is approved |
| Management-body minutes | Board or management body reviewed ICT risk |
| Board pack | Risks, incidents, suppliers and remediation are reported |
| Risk acceptance log | Decisions and residual risk are recorded |
| Training record | Management body received relevant ICT risk briefing |
The strongest governance evidence shows challenge and decisions, not only approval.
ICT risk evidence
ICT risk evidence should connect risks to services, controls, owners and remediation.
| Evidence | What it proves |
|---|---|
| ICT risk register | Risks are identified, scored and owned |
| Control owner matrix | Controls are assigned to accountable people |
| Asset inventory | Systems supporting regulated services are visible |
| Remediation tracker | Gaps are followed to closure |
| Risk methodology | Scoring is consistent and explainable |
Avoid treating the risk register as a static spreadsheet. The index should show when it was last reviewed and what changed.
Incident evidence
DORA incident evidence is timeline-sensitive. The index should point to records that preserve decisions.
| Evidence | What it proves |
|---|---|
| Incident policy | Roles, escalation and process are defined |
| Classification workflow | Major ICT incident decisions can be made |
| Incident log | Events and near misses are tracked |
| Timeline record | Detection, classification and approval timestamps are retained |
| Post-incident review | Root cause, remediation and lessons are captured |
| NCA reporting route note | Local submission route is known and verified |
For detailed incident timing and classification work, see DORA Incident Reporting 2026.
Testing and BCDR evidence
Testing evidence should show a closed loop: test, finding, owner, due date, closure.
| Evidence | What it proves |
|---|---|
| Annual test plan | Resilience testing is planned and risk-based |
| Vulnerability assessment | Technical weaknesses are identified |
| Tabletop exercise record | Decision-making and escalation are tested |
| Backup restore report | Recovery capability is evidenced |
| DR / BCDR test report | Recovery objectives are tested |
| Findings tracker | Weaknesses are assigned and closed |
A backup job screenshot is weak evidence. A restoration test with result, exceptions and remediation is stronger.
Third-party evidence
Third-party evidence is often where fintechs have the biggest gap.
| Evidence | What it proves |
|---|---|
| Register of Information | ICT third-party arrangements are mapped |
| Supplier criticality assessment | Critical or important dependencies are identified |
| Due-diligence records | Supplier controls have been reviewed |
| Contract gap tracker | Article 30 gaps are known and assigned |
| Concentration risk note | Dependency and substitutability risks are considered |
| Exit strategy | Critical supplier exit is considered |
The Register of Information should be a core section of the evidence index, not a separate year-end exercise.
How to maintain the index
The evidence index should be updated by events, not only before an audit.
| Trigger | Index update |
|---|---|
| New ICT supplier | Add supplier assessment and Register entry |
| New critical service | Update scope and dependency map |
| Major incident | Add timeline, classification and remediation evidence |
| Failed test | Add finding and action owner |
| Board review | Add pack, minutes and decisions |
| Contract renewal | Update contract tracker and Article 30 status |
| Risk acceptance | Link decision to risk and evidence |
This is how the index becomes a living operating record.
Common mistakes
Mistake 1: Creating a folder list instead of an evidence index
A folder list says where files are stored. An evidence index says what each artefact proves, who owns it and whether it is current.
Mistake 2: No owner
Evidence without an owner becomes stale. Every important artefact should have an accountable person or function.
Mistake 3: No review date
Regulatory evidence ages quickly. The index should make stale evidence visible.
Mistake 4: Mixing drafts with approved records
Drafts can be useful, but the index should distinguish draft, approved, operating and reviewed evidence.
Mistake 5: Sending the index without supporting artefacts
The index is a map. The reviewer still needs access to the underlying evidence where appropriate.
Related reading
- DORA Gap Analysis for Fintechs: What Should Be Delivered in 30 Days
- DORA Compliance Guide for EU Fintech SMBs: 2026 Evidence Roadmap
- DORA ICT Risk Register Template: 2026 Guide for Financial Entities
- DORA Register of Information: 2026 Guide for ICT Third-Party Risk
- Case Study: 90-Day DORA Gap Analysis for an EU-Licensed EMI
FAQ
What is a DORA evidence index?
A DORA evidence index is a structured map of evidence artefacts, owners, review dates, status and links. It helps reviewers understand the operating model without searching through disconnected folders.
Is an evidence index required by DORA?
DORA does not prescribe a document called "evidence index". The index is a practical operating artefact that helps demonstrate ICT risk management, incident readiness, testing, third-party risk and governance evidence.
Can a small fintech use a spreadsheet?
Yes. A spreadsheet is often enough if it is controlled, current, owned and linked to the actual evidence. The tool matters less than accuracy, ownership and review cadence.
What should be included first?
Start with scope, ICT risk framework, ICT risk register, incident workflow, Register of Information, testing evidence, board pack and remediation tracker.
Who should own the evidence index?
Compliance, risk, vCISO or PMO can own the index, but inputs must come from technology, security, operations, legal, procurement and business owners.
How often should the index be reviewed?
Quarterly review is a practical baseline for many fintechs, with event-driven updates after incidents, supplier changes, board reviews, contract renewals and resilience tests.
Primary sources
- Regulation (EU) 2022/2554 — DORA, EUR-Lex
- European Banking Authority — Digital Operational Resilience Act
- European Commission Implementing Regulation (EU) 2024/2956 — standard templates for the Register of Information
Bottom line
A DORA evidence index makes the operating model reviewable.
It does not replace policies, registers, incident records, board minutes or test reports. It connects them.
For a fintech SMB, that connection is often the difference between a confident evidence request and a last-minute search through folders.