DORA for software teams
What the EU Digital Operational Resilience Act asks of financial firms and their technology providers: managing ICT risk, reporting major incidents on a clock, testing, and controlling third-party providers.
What DORA is
Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (Digital Operational Resilience Act)
DORA, Regulation (EU) 2022/2554, is the EU law on digital operational resilience in finance. It has applied since 17 January 2025. It sets one set of rules for how financial firms manage the risk that their technology fails or is attacked.
It has five main parts: ICT risk management, ICT incident management and reporting, digital operational resilience testing, management of ICT third-party risk, and information sharing. The management body is responsible for all of it.
Technology providers are covered in two ways. Their financial customers must put DORA terms in their contracts and track them in a register. Providers designated as critical are also overseen directly by the EU supervisory authorities.
Who it applies to
Financial entities
Banks, payment and e-money institutions, investment firms, crypto-asset service providers, insurers, fund managers, trading venues, crowdfunding platforms and other firms listed in Article 2.
ICT third-party service providers
Cloud, software and data providers to those firms. They must accept DORA contract terms, support audits and exit plans, and report on subcontractors.
Critical ICT providers
Providers designated as critical by the European Supervisory Authorities are overseen directly, with inspections and recommendations.
Some small firms are out of scope or use a simplified ICT risk framework, such as small and non-interconnected investment firms and some exempted payment institutions. Microenterprises have lighter testing duties. Outside finance, the NIS2 Directive is the general EU cybersecurity law.
Key requirements, and what they mean for the build
Each row links the official text. Read the source for the exact wording before you rely on it.
Management body responsibility
The management body defines, approves and oversees the ICT risk management framework and carries final responsibility for ICT risk.
Give leadership regular, readable reporting on ICT risk, incidents and test results, not just raw dashboards.
ICT risk management framework
A documented framework to identify ICT assets and risks, protect and prevent, and detect anomalies. The classification of assets and the risk scenarios are reviewed at least yearly.
An asset and dependency inventory tied to business functions, hardened configuration, and monitoring with alerts that reach someone on call.
Response, recovery and backups
An ICT business continuity policy, response and recovery plans, and backup policies with restoration procedures based on how critical the data is.
Backups with tested restores, recovery time and recovery point targets per service, and runbooks that are rehearsed.
Incident management and classification
A process to detect, manage, log and classify ICT-related incidents by criteria such as clients affected, duration, geography, data loss and critical services hit.
One incident record per event with impact fields that map to the classification criteria, so a major incident is recognised quickly.
Major incident reporting clock
Major ICT incidents are reported to the competent authority. The initial notification is due within 4 hours of classifying it as major and no later than 24 hours after becoming aware, an intermediate report within 72 hours, and a final report within one month.
Time stamps for detection, classification and each report, with templates filled from the incident record.
Source: Delegated Regulation (EU) 2025/301: incident report content and time limits, EUR-Lex
Resilience testing programme
A risk-based testing programme with tests such as vulnerability scans, source code reviews where feasible, scenario, performance, end-to-end and penetration tests. Critical systems are tested at least yearly.
Security and resilience tests in the delivery pipeline, plus scheduled exercises with findings tracked to closure.
Threat-led penetration testing
Firms identified by their authority carry out threat-led penetration testing (TLPT) on live production systems at least every 3 years.
Know which of your systems support critical or important functions, because they will be in scope of the test.
Third-party risk and register of information
Firms stay fully responsible when they outsource, and keep a register of information on all contracts for ICT services, separating those that support critical or important functions.
If you are the provider, keep your own subcontractor list, service locations and service levels ready to hand to customers.
Key contract terms
ICT contracts set out the services, locations of data and processing, data protection, access and return of data, service levels, incident support, audit rights and exit terms.
Build data export, deletion on exit and audit logs into the product, so the contract terms can actually be met.
Engineering controls for DORA
How the rules change the way the software is designed.
- 01
Service and dependency map
Every service mapped to the business functions it supports, the assets it runs on and the providers it depends on.
- 02
Incident record with the clock
Detection, classification and report deadlines calculated on the record, with templates filled from the same data.
- 03
Tested recovery
Restores and failovers rehearsed against recovery time and recovery point targets, with results kept as evidence.
- 04
Testing in the pipeline
Dependency and code scanning, infrastructure checks and performance tests on every release, plus planned penetration tests.
- 05
Change management
Changes to production reviewed, approved and logged, with a way to roll back quickly.
- 06
Provider register export
Contract, service, location and subcontractor data kept in a form that can feed the register of information.
- 07
Exit readiness
Customers can export their data in a usable format and move to another provider within the agreed period.
- 08
Logging and monitoring
Central logs with retention, alerting on anomalies, and access to logs controlled and logged too.
Key dates
- 16 January 2023DORA entered into force.
- 17 January 2025DORA applies to financial entities.
Much of the detail sits in technical standards adopted after the Regulation, such as the rules on incident report content and time limits. Check the European Supervisory Authorities' pages for the current set.
Checked against the official sources on 2026-10-25.
8 OceanLab product builds cite DORA
Counted from our published case studies: a build counts when DORA is in the list of rules it was built for.
Skanse - GRC Platform for Risk, Controls and DORA Incident Reporting
Designed and built a clickable GRC platform for a Danish bank and pension group: a risk register scored inherent and residual against the board's appetite, a dashboard with DORA readiness, and an ICT incident log that classifies incidents against the DORA criteria and runs the reporting clock to Finanstilsynet.
Riegel - Institutional MPC Custody Platform with Quorum Approvals and Client Policies
Designed and built a clickable client console for a German crypto custodian's MPC custody platform: institutions see their vaults and holdings, follow every transaction from request to final confirmation, approve with a security key against a quorum per approver group, and test their own first-match withdrawal policy before it goes live.
Lotse - Open Banking Aggregator Operations Console
Designed and built a clickable operations console for a Hamburg account information service provider that connects fintechs to German bank accounts under PSD2: bank connector health, incidents, and every consent from grant to the 180-day re-authentication.
Kindlus - Smart Contract Admin Console with Reviewed, Simulated and Multi-Signed Changes
Designed and built a clickable smart contract admin console for a Tallinn infrastructure company that serves protocol teams and token issuers: a registry of deployed contracts across chains, a role map that flags single keys with admin power, and a queue where every upgrade, role change, parameter change or pause is reviewed, simulated and signed through a Safe and a timelock.
Sonde - LLM Evaluation and Observability Platform with Release Gates
Designed and built a clickable LLM evaluation and observability platform for the AI team of a French health mutual: redacted production traces span by span, release gates that block a prompt or model change when quality regresses, alerts with owners and ageing, and the monitoring record its risk and compliance teams can show a supervisor.
Pegel - Incident Management and Status Page for a Payroll SaaS
Designed and built a clickable incident management console for a Vienna payroll SaaS serving about 1,400 employers in Austria, Germany and Switzerland: one alerts inbox, an incident room with roles, timeline and update cadence, and a regulatory tracker that keeps GDPR, NIS2 and DORA contract notices on their deadlines.
Check your product
Other frameworks and industries
Build with DORA in mind from day one
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
DORA questions
We are a SaaS vendor to banks. Does DORA apply to us?
Not directly, unless you are designated as critical. But your bank customers must put DORA terms in your contract, list you in their register and assess you, so in practice you must support audits, incident reporting, data access and exit.
How fast must a major incident be reported?
The initial notification is due within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours and a final report within one month.
Does DORA replace other ICT rules?
For financial entities in scope, DORA is the main EU rule on ICT risk. National supervisors still issue guidance, and data protection rules such as the GDPR still apply to personal data.
How does OceanLab approach DORA on a build?
We map each service to the functions it supports, build the incident record and its reporting clock into the product, and make backups, exports and logs testable. The builds below list DORA in the rules they were built for.
