# DORA Requirements in 2026: What the Regulation Mandates and How to Evidence It

Source: https://www.cyadviso.com/dora-requirements-2025
Last reviewed: 2026-04-29
Tags: DORA

DORA requirements in 2026: the regulatory obligations — ICT risk, incident reporting, resilience testing, third-party risk and board-level operating evidence.

---

**Last reviewed: 29 April 2026**

**Key takeaways**

- DORA has applied since 17 January 2025 and now requires operating evidence across core resilience areas.
- The practical requirements cover ICT risk, incidents, third-party risk, testing, continuity and governance.
- Supervisors ask whether controls operate, findings close and management receives current reporting.
- Fastest path: confirm scope -> map requirements -> assign owners -> maintain evidence and review cadence.

DORA requirements in 2026 are no longer a readiness checklist.

[Regulation (EU) 2022/2554](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554) has applied since 17 January 2025. Financial entities now need to show that the framework operates.

That distinction matters.

This page covers what the regulation mandates by obligation area. For the practical step-by-step checklist, see [DORA Compliance Checklist 2026](/dora-compliance-guide). For the full fintech SMB implementation guide, see [DORA Compliance Guide for EU Fintech SMBs](/comprehensive-guide-dora-compliance-fintech-smb).

A policy can say the right thing and still fail a supervisory review if:

- no one owns the risk;
- incidents are not classified;
- suppliers are not monitored;
- recovery has not been tested;
- the management body never sees useful ICT risk reporting.

The practical DORA question in 2026 is:

> Can the financial entity show current evidence that ICT risk, incident response, resilience testing and ICT third-party oversight are working?

## DORA requirements at a glance

| Requirement area | What DORA expects | Evidence to keep current |
| --- | --- | --- |
| Management body | Clear responsibility and oversight of ICT risk | Board minutes, approvals, risk decisions, training records |
| ICT risk framework | Policies, roles, controls, risk appetite and review cadence | ICT risk policy, control map, owner list, risk register |
| Asset and function mapping | Understanding of ICT assets and critical or important functions | Asset inventory, service map, criticality assessment |
| Protection and prevention | Controls to prevent avoidable ICT disruption | Access reviews, vulnerability reports, configuration baselines |
| Detection | Ability to detect abnormal activity and service degradation | Monitoring coverage, alert logs, escalation records |
| Response and recovery | Ability to contain, restore, communicate and learn | Playbooks, incident records, recovery evidence, post-incident reviews |
| BCDR | ICT continuity and disaster recovery for critical services | BCP/DR plans, RTO/RPO evidence, restoration test reports |
| Incident reporting | Classification and reporting of major ICT-related incidents | Classification log, reporting decision record, submitted reports |
| Resilience testing | Risk-based test programme and remediation tracking | Test plan, results, remediation tracker, tabletop records |
| Third-party ICT risk | Lifecycle control over ICT providers | Due diligence, contracts, monitoring records, exit plans |
| Register of Information | Structured ICT third-party arrangement register | Current RoI, update process, reconciliation evidence |

For the advanced testing branch, see [DORA TLPT: 2026 Guide to Threat-Led Penetration Testing](/dora-tlpt-threat-led-penetration-testing).

## Who must care

DORA applies to a broad set of financial entities listed in Article 2.

For fintech and financial services, this includes:

- payment institutions;
- electronic money institutions;
- investment firms;
- credit institutions;
- crypto-asset service providers;
- other regulated financial-sector entities.

For fintech SMBs, the frequent mistake is assuming DORA is only a legal or compliance project. In practice, requirements cut across management, security, engineering, operations, procurement, legal and vendor management.

| Internal owner | DORA responsibility |
| --- | --- |
| Management body | Approves and oversees ICT risk framework |
| CEO / COO | Ensures resources, ownership and operating cadence |
| CTO / engineering | Maintains technical controls, resilience and remediation |
| CISO / vCISO | Owns ICT risk model, incident readiness and security reporting |
| Compliance | Tracks obligations, evidence and supervisory communication |
| Legal / procurement | Ensures ICT contracts contain required provisions |
| Vendor owner | Monitors supplier performance, incidents and exit risk |

## 1. Management-body responsibility

DORA puts ultimate responsibility for ICT risk management on the management body. The board or equivalent body does not need to run technical controls, but it must approve, oversee and challenge the ICT risk framework.

| Evidence | What it should show |
| --- | --- |
| ICT risk framework approval | The management body approved the framework and receives updates |
| Board reporting pack | ICT risks, incidents, suppliers, testing and remediation are reported clearly |
| Decision log | Material risk acceptances and remediation decisions are recorded |
| Training records | Management body members receive ICT risk awareness appropriate to their role |
| Follow-up tracker | Open actions from board-level ICT risk discussions are closed or escalated |

A weak board report says "DORA implementation is progressing". A useful report shows open ICT risks, critical supplier dependencies, incident trends, testing results, overdue remediation and decisions needed.

## 2. ICT risk management framework

The ICT risk management framework is the centre of DORA. It should connect risks, assets, controls, owners, evidence and review cycles.

The framework should answer:

- which ICT systems support critical or important functions;
- what risks could disrupt those systems;
- which controls reduce those risks;
- who owns each control;
- how exceptions are approved;
- how incidents and test results feed back into risk treatment;
- what evidence proves the framework is operating.

| Framework element | Practical artefact |
| --- | --- |
| Risk appetite | Board-approved ICT risk appetite and thresholds |
| Risk identification | ICT risk register with owners and review dates |
| Control model | Control library mapped to DORA areas |
| Asset dependency | Asset and service map linked to critical or important functions |
| Review cadence | Monthly or quarterly risk review rhythm |
| Exception process | Accepted-risk register and expiry dates |

## 3. Asset, function and dependency mapping

Many DORA gaps start with poor mapping.

If the entity cannot identify the systems, vendors and processes behind a financial service, three other tasks become weak:

- incident classification;
- resilience testing;
- supplier oversight.

| Mapping question | Why it matters |
| --- | --- |
| Which services are critical or important? | Drives incident impact, testing priority and supplier criticality |
| Which ICT assets support each service? | Supports risk assessment and recovery planning |
| Which providers support those assets? | Feeds the Register of Information and third-party risk |
| Where is data processed? | Supports security, privacy, incident and continuity decisions |
| What are the recovery assumptions? | Supports BCDR and restoration testing |

## 4. Protection and prevention controls

DORA expects financial entities to protect ICT systems and prevent avoidable disruption. This includes access control, vulnerability management, secure configuration, data protection, backup protection and change management.

| Control area | Evidence |
| --- | --- |
| Identity and access management | User access reviews, privileged access records, MFA coverage |
| Vulnerability management | Scan results, risk rating, remediation SLA and closure evidence |
| Secure configuration | Hardening baseline, configuration review, exception log |
| Change management | Change approvals, testing evidence, rollback plans |
| Backup protection | Backup configuration, immutability or segregation evidence, restore tests |
| Data protection | Encryption, access controls and data handling records |

The operating test is simple: can the entity show that high-risk findings, access exceptions and failed changes are tracked to closure?

## 5. Detection capability

Detection connects prevention to incident response. Without reliable monitoring and escalation, major-incident classification becomes guesswork.

For smaller entities, DORA does not mean building an internal 24/7 security operations centre by default. It does mean having a clear detection model.

| Detection evidence | What to verify |
| --- | --- |
| Monitoring scope | Critical systems and third-party signals are covered |
| Alert triage procedure | Alerts are reviewed by named roles |
| Escalation matrix | Material events reach incident owners quickly |
| Logging assumptions | Logs needed for investigation are retained |
| Sample alerts | Recent examples show triage and closure |

## 6. Response and recovery

Incident response is not just a plan. The team must be able to classify, contain, communicate, restore and learn.

| Requirement | Evidence |
| --- | --- |
| Classification | Severity model and DORA major-incident decision path |
| Escalation | Contact tree, roles and decision authority |
| Containment | Playbooks for common incident scenarios |
| Communication | Internal, customer, supplier and authority communication templates |
| Recovery | Restoration procedures and recovery objective tracking |
| Lessons learned | Post-incident reviews and remediation records |

The common weakness is timestamp quality. Incident records should show detection time, classification time, escalation time, key decisions, restoration time and final closure.

## 7. Business continuity and disaster recovery

Business continuity and disaster recovery under DORA should be tied to critical or important functions, not written as a generic IT document.

| BCDR item | Evidence to maintain |
| --- | --- |
| ICT continuity policy | Approved scope and responsibilities |
| RTO/RPO definitions | Recovery objectives per critical service |
| Recovery procedures | Step-by-step restoration instructions |
| Backup and restore tests | Evidence that restoration actually worked |
| Scenario exercises | Exercises involving operations, technology, compliance and suppliers |
| Remediation tracker | Failed test findings assigned and closed |

Testing backups is not enough. The stronger evidence is a restoration test that shows whether business recovery objectives were met.

## 8. ICT-related incident reporting

DORA requires financial entities to manage ICT-related incidents and report major ICT-related incidents. Reporting depends on classification, and classification depends on facts gathered quickly.

| Reporting capability | Evidence |
| --- | --- |
| Incident register | All material ICT incidents and near misses tracked |
| Classification logic | Criteria and decision record for major ICT-related incidents |
| Internal escalation | Named roles for legal, compliance, technology and management |
| Authority route | Local competent authority submission process identified |
| Report templates | Initial, intermediate and final report inputs prepared |
| Third-party incidents | Supplier notification and escalation captured |

For timing and templates, use the current DORA incident-reporting technical standards and the competent authority's submission process. For detailed timing, see [DORA Incident Reporting 2026](/dora-incident-reporting).

## 9. Digital operational resilience testing

DORA testing is broader than penetration testing. It should be risk-based and proportionate, covering the ability to prevent, detect, respond to and recover from ICT disruption.

| Testing type | DORA purpose |
| --- | --- |
| Vulnerability assessment | Identifies exposed weaknesses |
| Scenario/tabletop exercise | Tests decision-making, escalation and communications |
| Backup restoration test | Proves recovery capability |
| Application/security assessment | Tests key systems and controls |
| Gap analysis | Identifies missing controls and evidence |
| End-to-end test | Confirms a critical process works across systems and providers |
| TLPT | Applies to financial entities identified by competent authorities under DORA criteria |

Threat-led penetration testing should not be presented as universal for every small fintech. It is required for selected entities, while all entities need a proportionate testing programme.

## 10. ICT third-party risk management

DORA third-party risk is not only procurement. It is lifecycle governance over ICT providers, especially those supporting critical or important functions.

| Lifecycle stage | Evidence |
| --- | --- |
| Strategy | ICT third-party risk policy and risk appetite |
| Due diligence | Security, resilience, financial and subcontracting review |
| Contract | Article 30 clauses where applicable |
| Onboarding | Service owner, criticality, data and access mapping |
| Monitoring | Performance, incidents, assurance and concentration review |
| Exit | Exit plan, transition support and data return/deletion evidence |

Outsourcing does not outsource accountability. The financial entity remains responsible for managing the risk.

## 11. Register of Information

The Register of Information is the structured record of contractual arrangements with ICT third-party service providers. It should be maintained continuously, not rebuilt before a reporting window.

| RoI control | Evidence |
| --- | --- |
| Ownership | Named RoI owner and backup |
| Update trigger | Contract change, new supplier, termination, service change |
| Reconciliation | Check against procurement, contract and finance records |
| Criticality mapping | Link to critical or important functions |
| Data quality | Validation checks before submission |
| Change history | Audit trail of material updates |

For a deeper guide, see [DORA Register of Information: 2026 Guide for ICT Third-Party Risk](/dora-register-of-information).

## Proportionality

Proportionality changes depth, not accountability. A smaller payment institution should not copy a global bank's control environment, but it still needs risk ownership, incident classification, supplier oversight, testing and evidence.

| Requirement | Smaller entity approach | Larger/complex entity approach |
| --- | --- | --- |
| ICT risk register | Fewer risks, clear owners, quarterly review | Detailed risk taxonomy, KRIs, committee reporting |
| Testing | Focused tabletop, restore test, vulnerability assessment | Multi-year testing programme, broader scenario coverage |
| Third-party risk | Critical supplier focus | Tiered supplier framework and concentration analysis |
| Board reporting | Concise decision pack | Formal committee pack and management dashboards |
| Evidence | Lightweight but current | More formal evidence repository and assurance cycle |

## A one-week evidence test

If you want to know whether DORA is operating, ask for these artefacts within one week:

| Artefact | Good sign | Weak sign |
| --- | --- | --- |
| ICT risk register | Current owners, review dates and treatments | Static spreadsheet with no decisions |
| Board report | Shows risks, incidents, suppliers and test results | Says "DORA on track" without evidence |
| Incident classification log | Shows rationale and timestamps | No documented decisions |
| Recovery test report | Shows objective, result and remediation | Backup job screenshot only |
| Supplier criticality list | Links services, providers and functions | Vendor list only |
| Register of Information extract | Reconciled and owned | Rebuilt manually for submission |
| Remediation tracker | Owners, due dates and closure evidence | Unprioritised findings |
| Tabletop record | Decisions and gaps captured | Attendance list only |

## Related reading

- [DORA Compliance Guide for European Fintech SMBs](/comprehensive-guide-dora-compliance-fintech-smb)
- [DORA Incident Reporting 2026: Initial Notification, Intermediate Report and Final Report Timeline](/dora-incident-reporting)
- [DORA Business Continuity and Disaster Recovery: Articles 11-12 Roadmap for 2026](/dora-business-continuity-and-disaster-recovery)
- [DORA ICT Risk Register Template: 2026 Guide for Financial Entities](/dora-compliant-ict-risk-register)
- [DORA Register of Information: 2026 Guide for ICT Third-Party Risk](/dora-register-of-information)
- [EBA Guidelines on ICT and Security Risk Management After DORA](/ebas-guidelines-on-ict-and-security-risk-management)
- [DORA National Competent Authorities — selected jurisdictions hub](/dora-national-competent-authorities)

## Bottom line

DORA requirements in 2026 are operating requirements. The entity needs to show that ICT risk is owned, controls are maintained, incidents are classified, recovery is tested, suppliers are governed and management receives useful reporting.

The firms that do this well will not have perfect documentation. They will have current evidence, named owners and a rhythm for closing gaps.

## FAQ

### What are the main DORA requirements in 2026?

The main requirements cover ICT risk management, management-body oversight, incident management and major incident reporting, digital operational resilience testing, business continuity, ICT third-party risk management, the Register of Information and proportionate evidence maintenance.

### Did DORA start in 2026?

No. DORA has applied since 17 January 2025. In 2026, financial entities should treat DORA as an operating regime and maintain current evidence, not as a future implementation deadline.

### Which DORA requirement should a fintech fix first?

Start with scope, ownership and evidence. A fintech should know which entity is in scope, which authority supervises it, who owns ICT risk, where incident decisions are recorded and which third-party dependencies support critical or important functions.

### Are smaller financial entities exempt from DORA requirements?

No. Proportionality can change the depth and complexity of controls, but it does not remove the need for ICT risk ownership, incident classification, resilience testing, supplier oversight and management-body reporting.

### Is the Register of Information mandatory under DORA?

DORA requires financial entities to maintain a Register of Information for contractual arrangements with ICT third-party service providers. The register should be kept current and reconciled against supplier, contract and finance records.

### What evidence shows that DORA is operating?

Useful evidence includes an ICT risk register, incident classification log, board or management-body pack, resilience test reports, Register of Information, supplier contract tracker, remediation tracker and records of decisions or risk acceptances.

## Primary sources

- [Regulation (EU) 2022/2554 — Digital Operational Resilience Act, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [European Banking Authority — Digital Operational Resilience Act](https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act)
- [EBA — Regulatory Technical Standards on the ICT risk management framework](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/regulatory-technical-0)
- [EBA — Joint Technical Standards on major incident reporting](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-technical-standards-major-incident-reporting)

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/dora-requirements-2025