What DORA Is
Regulation (EU) 2022/2554—the Digital Operational Resilience Act—strengthens the ability of the EU financial sector to withstand, respond to and recover from ICT disruption. It has applied since 17 January 2025.
DORA is supported by Regulatory Technical Standards and Implementing Technical Standards that define details for ICT risk management, incidents, testing and third-party registers. By 2026 the reporting regime is operational; the ESAs published their first annual overview of major ICT-related incidents in June 2026.
Who Is In Scope
DORA covers a broad range of regulated financial entities, including credit institutions, payment institutions, investment firms, insurers and other categories in the Regulation. It also establishes oversight for designated critical ICT third-party service providers.
Applicability and proportionality vary by entity type and size; map each legal entity and service rather than applying one identical control set to every affiliate.
ICT Risk Management Framework
| Capability | Implementation focus |
|---|---|
| Identify | ICT assets, business functions, information, dependencies and risk scenarios |
| Protect | Security architecture, access, change/configuration, vulnerability management |
| Detect | Monitoring, anomaly detection, logging and escalation |
| Respond/recover | Incident response, continuity, backup/restore and crisis coordination |
| Learn | Post-incident review, testing lessons, control/risk updates |
The framework should connect management governance to an accurate inventory of systems, data, critical/important functions and external dependencies.
ICT Incident Management and Reporting
DORA requires financial entities to manage, classify and report major ICT-related incidents according to harmonized criteria and processes. Define evidence collection before incidents occur: affected services, clients, duration, geographic spread, data impact and economic/reputational effects need reliable sources.
Regulatory reporting should not depend on manually reconstructing facts from scattered logs. Define technical and legal/compliance handoffs and rehearse them.
Digital Operational Resilience Testing
DORA requires a testing program proportionate to risk. Testing goes beyond annual penetration testing and can include vulnerability assessments, scenarios, end-to-end tests, recovery exercises and other methods. Certain entities are subject to threat-led penetration testing requirements.
Test critical functions and dependencies—not only individual controls. Include identity providers, APIs, cloud platforms and third-party communications.
ICT Third-Party Risk Management
DORA emphasizes the entire lifecycle of ICT third-party arrangements: pre-contract due diligence, contract provisions, subcontracting, monitoring, concentration risk and exit strategies. Arrangements supporting critical or important functions receive particular scrutiny.
- Know which business functions depend on each provider.
- Document data locations/subcontractors/concentrations.
- Define security, incident, audit/access and exit requirements.
- Monitor risk after onboarding.
- Exercise exit/reversibility for critical dependencies.
Register of Information
DORA technical standards define structured templates for a register of contractual ICT third-party arrangements. Keep it connected to procurement, architecture and service ownership; a stale spreadsheet weakens both regulatory evidence and incident response.
Management Body Responsibilities
DORA explicitly makes ICT risk a governance responsibility. Management bodies approve/oversee the framework, resources and accountability and need sufficient understanding to challenge resilience decisions.
Boards do not operate security tools, but they need reliable information about risk appetite, dependencies, incidents, testing and remediation.
APIs and DORA
APIs frequently support critical financial functions and third-party integrations. Include API inventories, gateways, authentication, dependencies and providers in ICT maps. API outages, account takeover or business-logic abuse can become resilience events.
Related Ammune reading: API security incident response playbook and Enterprise API monitoring best practices.
From Critical Function to Resilience Scenario
A practical DORA program begins with the business function, not the security tool. For each critical or important function, identify the applications, APIs, identity services, databases, networks, cloud regions and external ICT providers required for delivery. Then model credible disruptions across those dependencies.
For example, a payment function may depend on an external identity provider and an API gateway. A useful resilience scenario is not simply 'gateway unavailable'; it asks what happens if authentication is healthy but the gateway is partially degraded, transaction queues build, monitoring is delayed and one third-party provider cannot meet its recovery objective. The exercise should test detection, customer impact assessment, fallback decisions, communications, recovery and post-incident learning.
This dependency-centric approach also improves incident classification and third-party risk management because the organization already knows which technical failures map to important business functions.
| Scenario evidence | Why it matters |
|---|---|
| Dependency map | Shows which ICT services support the critical function |
| Recovery objectives | Defines acceptable disruption/data loss |
| Monitoring/alert timeline | Shows how quickly degradation is detected |
| Decision log | Shows governance and escalation |
| Provider communications | Tests contractual/operational coordination |
| Post-test actions | Demonstrates learning and control improvement |
DORA’s Five Operational Pillars
A practical DORA program can be organized around five connected pillars: ICT risk management; ICT-related incident management/reporting; digital operational-resilience testing; ICT third-party risk management; and information-sharing arrangements. Governance cuts across all of them rather than existing as a separate paperwork stream.
| Pillar | Operational question |
|---|---|
| ICT risk | Do we know critical functions, assets, dependencies and recovery controls? |
| Incidents | Can we classify impact and produce reliable facts quickly? |
| Testing | Have we proven critical functions survive realistic disruption? |
| Third parties | Do contracts, concentration and exit plans match criticality? |
| Information sharing | Can relevant threat intelligence be shared lawfully and operationally? |
Organizing evidence this way reduces duplicate compliance work because one dependency map can support risk assessment, test scenarios, third-party registers and incident classification.
DORA Evidence Map by Operational Outcome
DORA evidence is strongest when it proves an operational outcome rather than the existence of a policy. A critical-function map should connect to tests and incidents; a third-party register should connect to due diligence, contracts and exit plans; incident procedures should connect to real classification and reporting records.
| Outcome | Evidence examples |
|---|---|
| ICT risk is understood | Asset/dependency inventories, critical-function mapping, risk assessments |
| Incidents are detected/classified | Monitoring coverage, escalation records, classification decisions and timelines |
| Services can recover | Recovery objectives, restore/failover tests, resilience-exercise results |
| Third parties are governed | Register, due diligence, contracts, monitoring and exit evidence |
| Management governs resilience | Approvals, reporting, decisions, remediation tracking and resource actions |
Designing evidence around outcomes also helps reduce parallel compliance silos because the same validated artifact can support risk, testing, third-party and management reporting workflows.
DORA Checklist
- Confirm applicability/proportionality.
- Map critical functions to ICT assets/providers.
- Maintain ICT risk-management framework.
- Define incident classification/reporting workflows.
- Exercise resilience testing.
- Maintain the third-party register.
- Govern critical providers across lifecycle.
- Document subcontracting/concentration/exit risks.
- Preserve incident/testing/governance evidence.
- Include APIs/cloud dependencies.
Frequently Asked Questions
When did DORA start applying?
January 17, 2025.
Is DORA only cybersecurity?
No. It addresses broader digital operational resilience including governance, testing, incident management and ICT third-party risk.
Does DORA require testing?
Yes. It requires a digital operational-resilience testing program, and certain entities are subject to threat-led penetration testing.
What is the DORA register of information?
A structured register of contractual arrangements with ICT third-party service providers.
Why are APIs relevant?
They often support critical financial functions and third-party dependencies and therefore belong in asset/dependency and incident mapping.
Primary References
Add Runtime API Evidence to Your DORA Program
Connect API discovery, monitoring and forensic evidence to the broader ICT risk, incident, resilience and third-party processes required by DORA.