DORA: explained for the people who have to keep the systems running.

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) applies to financial entities in the EU. It establishes requirements for ICT risk management, ICT-related incident reporting, digital operational resilience testing (including threat-led penetration testing for significant entities), ICT third-party risk management, and information sharing on cyber threats. DORA became applicable on 17 January 2025. Acuna covers DORA requirements across all four panes: framework mapping in Comply, ICT controls and asset inventory in Implement, incident and third-party management in Operate, and TLPT findings and corrective actions in Assure.

DORA Chapter IV requires financial entities to maintain a digital operational resilience testing programme. This includes vulnerability assessments, network security testing, gap analysis, and software security reviews. Significant entities must also conduct threat-led penetration testing (TLPT) at least every three years, simulating real-world attacks against live production systems using threat intelligence. TLPT must be performed by qualified testers and results reported to the National Competent Authority. Acuna tracks TLPT planning, findings, and corrective actions in the Assure pane.

The DORA register of information is the record, required by Article 28 of Regulation (EU) 2022/2554, of all your contractual arrangements for the use of ICT services provided by third parties. Every financial entity must keep it current, maintain it at entity and, where relevant, sub-consolidated and consolidated group level, and make it available to its competent authority on request. It is the backbone of DORA's third-party risk regime: supervisors use it to see, across the financial sector, which providers the system depends on. The register is not a one-time inventory. It is a living record that has to reflect your ICT supply chain as it actually is, including which arrangements support critical or important functions, because those carry stricter contractual and oversight requirements. That distinction, critical-or-important versus the rest, drives much of what DORA asks of the relationship. The register documents each ICT contractual arrangement: the provider, the service, whether it supports a critical or important function, and the contractual terms DORA requires. The European Supervisory Authorities set the detailed template and fields through technical standards, so the precise columns are defined centrally rather than left to each entity. The register has to be complete and consistent enough that a supervisor can read your ICT dependency map from it. A register maintained as a spreadsheet, separate from the vendor relationships it describes, is accurate the day it is built and wrong the week a contract changes and nobody updates the file. That is the failure mode DORA's "keep it current" requirement is aimed at, and it is why the register cannot be a document you refresh before an inspection.

DORA requires financial entities to detect, manage, classify, and report ICT-related incidents. Major incidents must be reported to the competent authority in stages: an initial notification, followed by an intermediate report as the situation develops, and a final report once the root cause is known. The classification of what counts as "major" is based on criteria set out in the regulation and its technical standards, covering factors such as the number of clients affected, duration, geographic spread, data losses, and economic impact. Entities may also notify significant cyber threats voluntarily. Before you report, you classify. DORA and its technical standards define the thresholds that separate a major incident from a routine one, using materiality factors. Getting classification right matters because it determines whether the reporting clock starts at all. This is where a running incident process earns its place: if you cannot quickly assemble which clients, systems, and data an incident touched, you cannot classify it, let alone report it on time. DORA structures reporting in stages: an initial notification once you determine an incident is major, an intermediate report as handling progresses, and a final report with root-cause analysis. The precise deadlines for each stage are set by the regulatory and implementing technical standards and should be verified against the current published standard before you rely on them.

Threat-led penetration testing (TLPT) is the advanced form of resilience testing that DORA requires of financial entities identified as significant. Unlike routine vulnerability scanning or standard penetration tests, TLPT simulates the tactics, techniques, and procedures of real threat actors against an entity's live production systems, covering the critical or important functions that support its business. It is performed by qualified external testers, scoped and validated with the competent authority, and carried out at least every three years. TLPT draws on the TIBER-EU framework for threat-led testing. TLPT sits at the demanding end of DORA's testing pillar. Most in-scope entities run a general resilience testing programme; significant entities additionally run TLPT, because the regulation treats their disruption as a bigger systemic risk. A standard penetration test checks whether known weaknesses can be exploited. TLPT is intelligence-led: it starts from a picture of the threats that realistically target your kind of entity, then tests whether your live systems and your people would withstand those specific adversary behaviours. It runs against production, not a test environment, which is what makes it a genuine test of operational resilience rather than of a lab setup. TLPT is a structured engagement: scoping the critical or important functions to be tested, developing threat intelligence, running the red-team test against live systems, and producing findings that feed remediation. Tester qualification, scoping, and the outcome are handled with the competent authority.

DORA applies to a broad range of financial entities established in the EU, including credit institutions, payment and electronic money institutions, investment firms, insurance and reinsurance undertakings and intermediaries, crypto-asset service providers, fund managers, trading venues, and more. It also reaches the ICT third-party service providers those entities depend on, and it creates a dedicated oversight regime for providers designated as critical, who become subject to direct supervision by a lead overseer. Scope is deliberately wide, so an EU financial entity should assume it is in scope until it confirms otherwise. DORA is not one-size-fits-all. Smaller and less complex entities apply a simplified version of the ICT risk management framework, calibrated to their scale and risk. Simplified is not exempt: the obligation still applies, at a proportionate depth. The largest and most systemically important entities carry the fullest requirements, including advanced testing. Certain ICT providers, judged critical to the EU financial system, are designated and brought under direct oversight by a lead overseer among the European Supervisory Authorities. This extends supervision to firms that are not themselves financial entities but on which the sector depends. For a financial entity, it means the concentration risk in your ICT supply chain is now a supervisory concern, not only a commercial one, which is exactly why the [third-party risk management](/supplier-shield) register matters.

NIS2 and DORA are two EU frameworks for cybersecurity and operational resilience that came into force around the same time and overlap heavily, but they are not interchangeable. NIS2 (Directive (EU) 2022/2555) is a cross-sector cybersecurity directive covering many industries; DORA (Regulation (EU) 2022/2554) is a finance-specific regulation for digital operational resilience. Where both could apply to the same organisation, DORA generally takes precedence for ICT risk in financial services as the more specific law, the lex specialis principle. A financial entity can therefore be in scope for both, with DORA governing its ICT risk and NIS2 relevant to the extent DORA does not cover. The two differ on instrument, scope, and specificity. NIS2 is a directive, so it is transposed into each member state's national law and its details can vary by country. DORA is a regulation, so it applies directly and uniformly across the EU without transposition. NIS2 spans many sectors; DORA is confined to financial entities and their ICT providers. DORA is also more prescriptive on ICT specifics, such as the register of information and threat-led penetration testing, than NIS2's more general risk-management measures. Where a financial entity would fall under both, DORA is treated as the more specific regime for its ICT risk, and it prevails on the matters it covers. NIS2 recognises this relationship, so the two are designed to fit together rather than duplicate. In practice, a bank manages its ICT risk under DORA and does not also apply NIS2's general measures to the same ground. For a financial entity in scope for both: determine your DORA obligations for ICT risk first, since they are the more specific and prescriptive. Then confirm what, if anything, NIS2 adds beyond DORA's coverage for your organisation, which depends partly on your member state's transposition. The efficient path is to map the shared requirements once, as most of the risk-management and supply-chain substance is common, and only maintain the genuinely distinct pieces separately.