DORA for Engineering Teams: Resilience Architecture

Q: What is DORA and who does it apply to?

DORA is Regulation (EU) 2022/2554, the Digital Operational Resilience Act, which has applied since 17 January 2025. It sets uniform requirements on the security of network and information systems supporting the business of financial entities in the EU: credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, central securities depositories, trading venues, insurers and reinsurers, pension institutions, fund managers and others listed in Article 2, with lighter treatment for microenterprises and some small entities. It also creates an oversight framework for ICT third-party providers designated as critical, which the European Supervisory Authorities did for the first time on 18 November 2025. Its five pillars are ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk, and information sharing. It should not be confused with the DevOps Research and Assessment metrics that share the acronym; those measure software delivery performance and have no regulatory status.

Q: What are the DORA incident reporting deadlines?

The time limits are set in Commission Delegated Regulation (EU) 2025/301, the regulatory technical standard on major ICT-related incident reporting. The initial notification must be submitted as early as possible and in any case within four hours from the moment the entity classifies the incident as major, and no later than 24 hours from the moment the entity became aware of the incident. If an incident is classified as major only later than 24 hours after awareness, the initial notification is still due within four hours of that classification. The intermediate report is due at the latest 72 hours after the initial notification, even where the status or handling of the incident has not changed, and an updated intermediate report is due without undue delay when regular activities are recovered. The final report is due no later than one month after the intermediate report or the latest updated intermediate report. The standard forms and procedures are in Implementing Regulation (EU) 2025/302. The engineering consequence is that awareness and classification must be recorded as timestamps in the incident tooling and the reports generated from the incident record.

Q: How should an engineering team decide whether an incident is "major" under DORA?

By computing the classification criteria from data the platform already has and presenting a candidate decision for a named person to confirm. The RTS on incident classification uses criteria including the number and relevance of clients and financial counterparts affected, the duration of the incident and the downtime of services, the geographical spread, any data losses in terms of availability, authenticity, integrity or confidentiality, the criticality of the services affected, and the economic impact. Affected clients can be derived from the service's traffic and customer mapping, duration from the SLO breach window, criticality from the service catalogue's critical-or-important flag, and geography from the entity's footprint per service. The classifier runs continuously against the open incident, the incident lead confirms or rejects the candidate classification, and that confirmation is the timestamp the four-hour clock starts from. Leaving classification to a periodic risk meeting is how entities discover the 24-hour outer bound from awareness has already elapsed.

Q: What is the DORA register of information and how should it be built?

Article 28 requires every financial entity to maintain and update, at entity, sub-consolidated and consolidated level, a register of information covering all contractual arrangements for ICT services provided by third-party providers, distinguishing those that support critical or important functions, and to make it available to the competent authority on request. Implementing Regulation (EU) 2024/2956 lays down the standard templates, and competent authorities collect the registers for the ESAs, who use them to identify which providers to designate as critical. The register is best treated as a report generated from a dependency graph maintained in the systems: function, system, ICT service, contract, provider and subcontractor, with criticality flowing down from the function and concentration computed by aggregating up to the provider. That makes the subcontracting assessment required by Delegated Regulation (EU) 2025/532 a traversal rather than a survey, reveals when two apparently different vendors depend on the same hyperscaler, and keeps the register reconciled to what actually runs rather than to what procurement recorded last quarter.

Q: What is threat-led penetration testing (TLPT) under DORA and who must do it?

TLPT is advanced testing required by Article 26 for financial entities identified by their competent authority under the criteria in Delegated Regulation (EU) 2025/1190, typically the larger and more systemically important ones; other entities are not required to perform it. It must be carried out at least every three years, cover several or all critical or important functions, and be performed on live production systems, with threat-intelligence-led scenarios, a red team, and formal closure and remediation stages. The RTS was drafted in accordance with the TIBER-EU framework and mirrors its methodology, and entities may apply TIBER-EU or a national implementation where consistent with the regulation. Internal testers may be used under conditions but threat-intelligence and testing providers are held to independence and competence standards. For the platform, TLPT requires a service catalogue that can scope the systems behind a function, production telemetry the blue team is not told to disable, segmentation that enforces the agreed scope, and a remediation tracker that carries findings into the next cycle. It is the audit of resilience; the annual testing programme under Article 25 is where the resilience is built.

Q: What does DORA require for exit strategies and concentration risk with cloud providers?

Article 28 requires financial entities to assess ICT concentration risk before contracting and to have exit strategies for ICT services supporting critical or important functions, so that they can exit an arrangement without disrupting business activities, breaching regulatory requirements or harming service continuity; Article 30 requires the contracts for such services to include termination rights and exit-support obligations alongside service levels, incident assistance, and audit and access rights. The designation of hyperscale cloud providers as critical ICT third-party providers does not transfer any of these obligations to the ESAs; it gives the entity leverage to obtain audit evidence and subcontractor information. An exit strategy that says "migrate to another provider" is a paragraph, not a plan. The workable approach decides an exit class per function: a warm second provider that the deployment pipeline can already target for stateless services; a restore-elsewhere path from immutable backups with a measured time for stateful systems; and a contractual data-return format with a tested import for SaaS. Each is rehearsed and the rehearsal results are the evidence.

Q: How does DORA relate to NIS2 and the Cyber Resilience Act?

DORA is lex specialis for the financial sector: where a financial entity falls within both DORA and the NIS2 directive, the DORA requirements on ICT risk management, incident reporting, testing and third-party risk apply in place of the corresponding NIS2 provisions, although NIS2's national transpositions may still govern some aspects such as supervisory cooperation. The Cyber Resilience Act sits on the other side of the relationship: it places product-security obligations, including vulnerability handling, security updates and reporting of actively exploited vulnerabilities, on the manufacturers of products with digital elements, which means the software vendors and providers that appear in a financial entity's register of information. In practice an engineering team at a financial entity designs to DORA, expects its providers to be subject to the CRA and, where relevant, NIS2, and should write the evidence it needs from those providers, such as vulnerability disclosure commitments and incident assistance, into the key contractual provisions required by DORA Article 30.

Q: What is the single most important engineering investment for DORA compliance?

A service catalogue that is generated from the systems rather than maintained by hand, with three fields that every DORA obligation depends on: whether the function the service supports is critical or important, which ICT services and providers the service depends on, and an owner that resolves to a real team. Incident classification needs the criticality flag to compute the criteria and the owner to confirm the decision; the register of information and the concentration analysis are reports over the dependency edges; TLPT scoping needs the systems behind a function; backup and exit rehearsals need to know which functions to prioritise and where their state lives. Almost every DORA engineering failure traces back to that catalogue being a spreadsheet, stale, or absent, and almost every other capability, from routing alerts to the right on-call team to sequencing a restore after ransomware, needs the same object. Build it from infrastructure-as-code and deployment metadata with criticality as a first-class field, and the regulation's artefacts start to fall out of the system as by-products of operating it.