DORA Requirements in 2026

In this article ↓

DORA requirements at a glance
Who must care
1. Management-body responsibility
2. ICT risk management framework
3. Asset, function and dependency mapping
4. Protection and prevention controls
5. Detection capability
6. Response and recovery
7. Business continuity and disaster recovery
8. ICT-related incident reporting
9. Digital operational resilience testing
10. ICT third-party risk management
11. Register of Information
Proportionality
A one-week evidence test
Related reading
Bottom line
FAQ
What are the main DORA requirements in 2026?
Did DORA start in 2026?
Which DORA requirement should a fintech fix first?
Are smaller financial entities exempt from DORA requirements?
Is the Register of Information mandatory under DORA?
What evidence shows that DORA is operating?
Primary sources

Last reviewed: 29 April 2026

DORA requirements in 2026 are no longer a readiness checklist.

Regulation (EU) 2022/2554 has applied since 17 January 2025. Financial entities now need to show that the framework operates.

That distinction matters.

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.

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.

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.

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.

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

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.

DORA Requirements in 2026: Operating Controls and Evidence Checklist