Case Study: 90-Day DORA Gap Analysis for an EU-Licensed EMI
Anonymised DORA case study for an EU-licensed EMI: gap analysis, ICT risk framework, incident workflow, supplier evidence and board-ready remediation plan.
In this article ↓
- Short answer
- Client context
- The problem
- Work delivered
- Evidence produced
- What changed
- What was deliberately not claimed
- Reusable lessons
- Related reading
- FAQ
- Is this a named client case study?
- What was the main DORA outcome?
- Did this replace a formal audit?
- Why is an evidence index important?
- Can a smaller EMI run this without a full-time CISO?
Last reviewed: 5 May 2026
This is an anonymised engagement note. Client names, jurisdictions, systems and commercial details are withheld under engagement confidentiality. The structure reflects the type of work CyAdviso performs for EU-licensed fintechs; it should not be read as a public audit opinion or legal advice.
Short answer
An EU-licensed electronic money institution needed to move from scattered DORA preparation to a defensible operating model.
The useful outcome was not a longer policy set. The useful outcome was a review-ready evidence baseline:
| Area | Before | After |
|---|---|---|
| Scope | DORA applicability understood informally | Entity, licence, NCA and critical-function scope note |
| ICT risk | Risks spread across tickets and documents | ICT risk register with owners, residual risk and actions |
| Incidents | Escalation known by people, not evidenced | Classification workflow, timestamps and reporting decision tree |
| Third parties | Supplier list existed, DORA mapping incomplete | Register of Information starter and supplier criticality map |
| Governance | Board updates were high-level | Management-body pack with risks, decisions and remediation |
| Evidence | Documents existed but were hard to review | Evidence index with owners, status and review dates |
Client context
The client was a regulated EMI operating with a lean security and compliance team. The company had already started DORA preparation, but the work was distributed across compliance documents, engineering tickets, supplier folders and board materials.
The management question was simple:
If a supervisor, partner bank or auditor asked for DORA evidence next month, could the team show a coherent operating model?
The initial answer was: partially, but with too much manual reconstruction.
The problem
The client did not lack effort. It lacked an evidence architecture.
Common gaps included:
- no single DORA scope note linking licence, services, NCA and critical functions;
- ICT risks written at different levels of detail;
- incident response documentation that did not preserve classification timestamps;
- supplier reviews not mapped to critical or important functions;
- contract gaps not visible in one tracker;
- board materials that did not show risk movement, decisions or overdue remediation.
These are typical fintech SMB problems. They do not mean the firm is careless. They mean DORA evidence has not yet been turned into an operating cadence.
Work delivered
The engagement was structured as a focused 90-day programme.
| Phase | Workstream | Output |
|---|---|---|
| Days 1-15 | Scope and evidence baseline | DORA scope note, evidence inventory, initial gap view |
| Days 16-30 | ICT risk model | Risk register structure, scoring method, owner map |
| Days 31-60 | Incident and supplier evidence | Incident workflow, supplier criticality map, Register of Information starter |
| Days 61-90 | Governance and remediation | Board pack, remediation tracker, evidence index |
The work was designed for a small internal team. The client team reviewed decisions and approved artefacts; CyAdviso structured the evidence, challenged weak assumptions and converted scattered inputs into reviewable records.
Evidence produced
The final evidence pack included:
| Evidence artefact | Purpose |
|---|---|
| DORA scope note | Shows why the entity is in scope and which services matter |
| Critical-function map | Links regulated services to systems and suppliers |
| ICT risk register | Shows top ICT risks, controls, residual risk and owners |
| Incident classification workflow | Preserves detection, classification, approval and reporting decisions |
| Register of Information starter | Creates the ICT third-party inventory baseline |
| Supplier criticality assessment | Identifies providers supporting important services |
| Article 30 contract gap tracker | Shows supplier contract remediation priorities |
| Board reporting pack | Gives the management body a risk and decision view |
| Evidence index | Gives reviewers one route into the evidence set |
What changed
The main change was reviewability.
Before the engagement, the client could answer many DORA questions, but answers depended on the memory of specific people. After the engagement, core answers had evidence:
- who owns ICT risk;
- which systems support critical or important functions;
- which suppliers matter most;
- how incidents are classified;
- which contract gaps remain open;
- what the management body has reviewed;
- which remediation actions are overdue.
That is the practical difference between "DORA project in progress" and "DORA operating model under control".
What was deliberately not claimed
This engagement did not produce an external audit opinion. It did not replace legal advice. It did not guarantee a future supervisory outcome.
The goal was narrower and more useful: make the current DORA posture understandable, evidenced and manageable.
Reusable lessons
| Lesson | Why it matters |
|---|---|
| Start with scope | Without scope, evidence becomes generic |
| Keep incident timestamps | DORA reporting depends on facts and timing |
| Link suppliers to functions | A vendor list is not a resilience map |
| Give the board decisions | "Noted" is weaker than recorded challenge |
| Maintain an evidence index | Reviewers need a map, not a document dump |
Related reading
- DORA Compliance Guide for EU Fintech SMBs: 2026 Evidence Roadmap
- DORA Compliance Checklist 2026: Practical Implementation Guide
- DORA ICT Risk Register Template: 2026 Guide for Financial Entities
- DORA Register of Information: 2026 Guide for ICT Third-Party Risk
- DORA Board Responsibilities 2026: Management Body Evidence Checklist
FAQ
Is this a named client case study?
No. It is anonymised. Client names, jurisdictions, systems and commercial details are withheld under confidentiality.
What was the main DORA outcome?
The main outcome was a review-ready evidence baseline: scope, ICT risks, incident workflow, supplier mapping, board pack, remediation tracker and evidence index.
Did this replace a formal audit?
No. The engagement supported DORA readiness and evidence quality. It did not produce an external audit opinion or legal advice.
Why is an evidence index important?
An evidence index helps supervisors, partner banks, auditors and internal reviewers understand the operating model without searching through disconnected folders.
Can a smaller EMI run this without a full-time CISO?
Yes, if internal owners are available for decisions and approvals. The vCISO role structures the work, challenges assumptions and produces evidence; the regulated entity remains accountable.