DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), became applicable on 17 January 2025. It puts ICT operational resilience on a single legal footing across the EU financial sector - banks, insurers, payment institutions, crypto-asset providers, fund managers, and the ICT third parties that serve them.
If you build software for EU financial entities, DORA is in your contracts now. This guide focuses on the parts that land on engineering teams: secure SDLC, change management, incident reporting, and third-party flow-down. It complements the broader NIS2 guide and the UK Cyber Essentials guide.
Who is in scope
Direct scope: EU financial entities - credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers (MiCA), central securities depositories, central counterparties, trading venues, trade repositories, AIFMs, UCITS managers, insurers, reinsurers, intermediaries, ratings agencies, crowdfunding service providers, securitisation repositories, and a few more.
Indirect scope: ICT third-party service providers to those entities. Critical providers (designated by the European Supervisory Authorities) face direct oversight. Everyone else faces contractual flow-down from their financial-entity customers - in practice, the same controls but enforced through the contract instead of by a regulator.
The five DORA pillars
| Pillar | Articles | What it covers |
|---|---|---|
| ICT risk management | 5-15 | Governance, framework, policies, asset management, secure SDLC |
| ICT-related incident management | 17-23 | Detection, classification, reporting timelines, root-cause analysis |
| Digital operational resilience testing | 24-27 | Vulnerability assessments, scenario-based tests, threat-led pen testing |
| ICT third-party risk | 28-44 | Register of arrangements, due diligence, contract content, exit plans |
| Information sharing | 45 | Voluntary cyber threat intelligence sharing |
For software teams the load lands mainly in pillars 1, 2, and 3.
Article 9 secure SDLC, in developer terms
Article 9 (Protection and prevention) and the supporting RTS require ICT systems to be developed and maintained using a secure development lifecycle. Translated to engineering practice:
| Requirement | Concrete control |
|---|---|
| Configuration management | Infrastructure as code; reviewed change requests; no manual production drift |
| Secure coding standards | Documented coding standard; security checks in code review; SAST in CI |
| Vulnerability management | SCA in CI; documented patch SLAs (e.g., 14 days for Critical, 30 days for High) |
| Segregated environments | Distinct dev / test / pre-prod / prod with no shared credentials or data |
| Source control and traceability | Every change tied to a ticket and a reviewer; protected branches; signed commits where practical |
| Testing before deployment | Automated tests, security tests, and a documented release approval |
| Change management | Risk classification on changes; rollback plan; production change window controls for critical systems |
If you already operate a mature CI/CD with reviewed PRs, dependency scanning, and segregated environments, you are most of the way there. The DORA-specific work is evidencing it: writing the policy, mapping it to the regulation, and producing artefacts on request.
Incident reporting timeline
DORA classifies ICT-related incidents by criteria including clients affected, data losses, duration, geographic spread, and economic impact. For major incidents:
| Stage | Deadline | Content |
|---|---|---|
| Initial notification | As soon as possible, no later than 4 hours after classification (and no later than 24 hours after detection) | Basic facts, classification, affected entities |
| Intermediate report | 72 hours after initial notification | Updated assessment, indicators of compromise, mitigations |
| Final report | 1 month after intermediate report | Root cause, total impact, remediation, lessons learned |
For engineering this means:
- Detection must surface incidents in minutes, not hours.
- Classification criteria must be pre-mapped to your service catalogue so on-call can decide quickly.
- Logs must be queryable in real time for affected-clients and data-loss assessment.
- The 4-hour notification clock starts at classification - your incident commander needs a clear classification rubric, not a debate.
Operational resilience testing
DORA Article 24-27 mandates a programme of digital operational resilience testing. For most entities that means:
- Vulnerability assessments - scanning, patch reviews, configuration audits - at appropriate frequency.
- Scenario-based tests - tabletop exercises, business-continuity drills, restore tests.
- Performance and capacity tests of critical ICT systems.
- End-to-end tests of incident detection, response, and recovery.
Significant credit institutions and other large players additionally face threat-led penetration testing (TLPT) every three years, conducted by approved testers under the TIBER-EU framework.
For software vendors supplying these entities, expect to:
- Cooperate with TLPT that targets your service.
- Provide vulnerability assessment evidence on request.
- Participate in your customers' incident exercises as part of the contract.
Third-party register and contract content
Financial entities must keep a register of all ICT third-party arrangements and report it to the regulator. They will only contract with you if you can supply, at minimum:
- A description of services and any sub-outsourcing.
- Service levels including security KPIs and reporting cadence.
- Incident notification commitments aligned to DORA's 4-hour clock.
- Audit and access rights for the financial entity and its regulator.
- Data location and processing details.
- Exit and termination assistance.
If you do not have this evidence ready, your contract will not progress. A standard "DORA addendum" is now table-stakes in EU financial procurement.
How DORA, NIS2, and Cyber Essentials interact
| Framework | Scope | Status when overlap |
|---|---|---|
| Cyber Essentials | UK baseline, voluntary or contract-driven | Floor - does not satisfy DORA on its own |
| NIS2 | EU essential and important entities | DORA prevails for EU finance (lex specialis) |
| DORA | EU finance and their ICT providers | Wins where it overlaps with NIS2 |
The pragmatic order for a software vendor selling into the UK and EU finance:
- Achieve Cyber Essentials Plus to clear the UK procurement floor.
- Layer NIS2-aligned supply-chain and incident-reporting evidence for general EU enterprise.
- Layer DORA-specific secure-SDLC evidence and contract terms for EU financial customers.
A pragmatic readiness checklist
- Documented secure SDLC mapped to DORA Article 9 and the RTS on ICT risk management.
- CI pipeline running SAST and SCA with documented patch SLAs.
- Segregated dev / test / pre-prod / prod environments, with no shared credentials.
- Incident classification rubric pre-mapped for the 4-hour clock.
- Standing tabletop exercise schedule, with at least one DORA-aligned scenario per year.
- DORA-ready third-party contract addendum approved by legal.
- Public security contact and vulnerability disclosure policy.
- Threat models for in-scope services, refreshed when the architecture changes - the Threat Model Tool is the fastest way to produce these.
- AppSec Scorecard baseline run, with the next two improvements scheduled.
DORA is enforceable today. Treat the controls as part of how you ship software, not as a binder. The vendors who win EU financial business in 2026 are the ones whose engineering practice already maps to the regulation - and who can show that on request.