The Digital Operational Resilience Act (DORA) became enforceable on 17 January 2025. By now most in-scope financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and many others — have a DORA programme of some kind. Few of them have one their supervisor would assess as fully aligned. The regulation is detailed enough that misreadings stay hidden until the first joint examination, and the cost of fixing them after that is materially higher than building correctly the first time.
DORA Is Not "GDPR for ICT"
A common mental shortcut treats DORA as the next major EU regulation in the same shape as GDPR. The structure is similar — directly applicable EU regulation, supervisory authorities, significant penalties, broad scope across regulated entities. The substance is different. DORA is closer in spirit to operational risk regulation than to data protection. Its central concern is whether financial entities can withstand, respond to, and recover from ICT-related disruption, including disruption that originates outside their own systems.
The Five Pillars and Where Programmes Drift
DORA organises its requirements into five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Each pillar has detailed requirements and has been further specified by the European Supervisory Authorities through Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS). The drift in most programmes happens at the boundary between general framework adoption and the specific RTS-level expectations.
ICT Risk Management: Beyond the Existing ISMS
Many entities started their DORA programme by mapping their existing ISO 27001 or NIST CSF implementation against the regulation. The mapping is mostly favourable — much of pillar one overlaps with mature security management practice. The mistake is assuming the overlap is sufficient. DORA imposes specific governance requirements (the management body has named ICT risk responsibilities), requires a documented ICT risk management framework, and expects a defined ICT business continuity policy that is more prescriptive than a typical BCM document.
Incident Reporting: The Definition of "Major" Matters
DORA requires reporting of major ICT-related incidents to the relevant competent authority within timeframes set by RTS. The RTS define what makes an incident "major" using thresholds across multiple criteria — clients affected, services impacted, geographic spread, data losses, criticality of services, economic impact, reputational impact. Programmes that have not built incident classification specifically against these criteria tend to over-report (operationally expensive) or under-report (regulatorily dangerous) — and either is visible to a supervisor reviewing the incident log.
A pattern that surfaces during examinations: the entity has a perfectly good incident response process inherited from its existing security programme, but the criteria for whether to escalate to the competent authority were never explicitly mapped to the DORA RTS thresholds. Incidents get classified by the security team using internal severity scales, then someone has to retroactively decide whether a regulatory notification was required. Build the regulatory classification into the runbook from the start.
Resilience Testing: TLPT Is Not Optional Where It Applies
Pillar three covers digital operational resilience testing. Most entities are required to perform a defined programme of testing that scales with their size and risk profile. Significant entities — and entities specifically designated by their competent authorities — are also required to perform Threat-Led Penetration Testing (TLPT) every three years. TLPT is not the same as a regular pen test. It follows the TIBER-EU framework, requires specific provider qualifications, and involves the competent authority and threat intelligence providers. Programmes that treated TLPT as "we already do pen tests" find out during scoping that the requirements are substantially more demanding.
Third-Party Risk: The Pillar with the Largest Operational Cost
Pillar four — ICT third-party risk management — has imposed the largest operational cost across most DORA implementations. The requirements include maintaining a register of contractual arrangements with ICT third-party providers, performing risk assessments before entering arrangements, ensuring contracts include specific terms (audit rights, exit strategies, sub-contracting controls, security requirements), and additional controls for arrangements supporting critical or important functions. For organisations with hundreds of vendor relationships, the contract remediation alone has been a significant programme.
- Build a single register of ICT third-party arrangements — not multiple, even temporarily
- Classify each arrangement by support of critical or important functions, with explicit criteria
- Treat the contractual provisions as a remediation programme, not a one-time audit
- Plan for the oversight regime — critical ICT third-party providers will be designated and directly supervised
- Document concentration risk explicitly — supervisors are looking for it, not just for individual relationships
How Mature DORA Programmes Operate
The entities furthest along in DORA implementation share a few characteristics. The programme is owned at executive level, not delegated to security or risk alone. Existing frameworks (ISO 22301, ISO 27001, NIST CSF) are integrated rather than replaced. The incident classification is hard-wired into the response runbook with explicit RTS-aligned thresholds. The TLPT plan is in place years ahead of the testing window, not assembled the quarter before. And the third-party register is treated as a living artefact maintained alongside procurement, not a snapshot updated annually for the regulator.
DORA is genuinely substantial and the supervisory expectations are still settling. The programmes that hold up are the ones that treated the first 18 months as foundation-building rather than compliance theatre — and the supervisors are starting to be able to tell the difference.