When the Digital Operational Resilience Act took effect in January 2025, most UK financial services firms with EU exposure assumed it was a tidying-up exercise. They had GDPR, FCA Operational Resilience requirements (the PS21/3 framework), the Bank of England’s third-party risk regime, and ISO 27001 in the bag. DORA, the thinking went, would slot in around the edges.
Sixteen months in, that assumption has not aged well.
A handful of early enforcement actions and a much larger volume of supervisory dialogue has clarified what regulators actually expect — and where firms with pre-existing operational resilience programmes are still falling short. The pattern is consistent enough that we can describe it.
The first gap: ICT third-party register depth
Article 28 of DORA requires regulated entities to maintain a register of all ICT third-party arrangements, classified by criticality, and to report it to competent authorities annually. Most firms produced a register. Few produced a register that survives scrutiny.
The most common failure mode is breadth without depth. Firms list every supplier with an “ICT” tag in the procurement system — typically several hundred entries — without distinguishing between commodity suppliers, supporting infrastructure providers, and the small number of arrangements that genuinely support a critical or important function. Auditors then ask for the dependency mapping behind a critical function (say, retail payment processing), and find that the register lists three suppliers when the actual dependency chain involves seventeen.
The deeper failure is that most registers do not capture fourth-party concentration. Article 28 explicitly requires firms to consider “the chain of subcontracting”, but in year one we have seen multiple firms with no visibility into the cloud regions, identity providers, and underlying infrastructure their critical suppliers depend on. When a regulator asks “what happens if AWS eu-west-1 goes down for 48 hours”, and the answer is “we’ll ask our supplier”, that answer is no longer adequate.
The second gap: incident classification timelines
DORA’s incident reporting regime is more demanding than most firms appreciated going in. Major ICT-related incidents must be reported with an initial notification within four hours of classification, an intermediate report within 72 hours, and a final report within one month. The clock starts at classification — which is itself supposed to happen “without undue delay”.
In practice, year one has shown that most firms classify incidents too slowly to meet the four-hour window comfortably. The reasons are predictable: classification depends on impact assessment, impact assessment depends on incident response progress, and incident response in the first hours is necessarily noisy.
Firms that have handled this well have moved classification authority into the incident response function rather than keeping it as a separate compliance step. Their playbooks now treat classification as an early triage decision, made on conservative assumptions, and revised as facts develop. Firms that have struggled have left classification with risk and compliance teams who only get involved once the incident is “stable” — by which point the four-hour window is already lost.
The lesson is procedural, not technical. But it is one regulators have begun probing carefully.
The third gap: testing programme realism
Article 24 requires regulated entities to maintain a digital operational resilience testing programme proportionate to their size, business risk, and ICT complexity. For firms classified as significant, Article 26 introduces threat-led penetration testing (TLPT) on a three-yearly cycle.
The testing gap we see most often is not a failure to test. It is a failure to test the failure modes that actually matter. Firms continue to commission annual penetration tests against their externally-facing infrastructure, vulnerability scans against their estate, and disaster recovery drills against their data centres. These remain useful, but they were already part of the FCA operational resilience playbook. DORA’s expectation is broader.
What firms have under-tested in year one:
- The interaction between ICT failures and business continuity processes that depend on ICT
- The recovery of data and services to a known-good state (rather than just “to running”)
- The dependency of incident response capabilities on the systems they are responding to (the canonical example: an Active Directory compromise that disables the SIEM and identity-dependent forensic tooling)
- Third-party failure scenarios where the third party is itself the responder
These are scenarios where Mellivor regularly works with clients on tabletop exercises and red-team engagements. The Labyrinth Security deception platform we deploy for several clients has, on more than one occasion, surfaced lateral movement that went undetected by primary controls during what was assumed to be a routine resilience test.
The fourth gap: ICT risk management framework alignment
Article 6 requires firms to establish, maintain, and document an ICT risk management framework that is integrated with the broader risk management system. The framework must be reviewed annually, after major ICT incidents, and following supervisory instructions.
The integration requirement is where firms have most consistently underdelivered. ICT risk frameworks exist. They are documented. They are sometimes even reviewed. But they often run as parallel documents to the enterprise risk management framework, the operational risk framework, and the business continuity framework — overlapping in places, contradicting in others, and managed by different teams with different reporting lines.
Regulators in supervisory dialogue have repeatedly asked firms to demonstrate how a specific ICT risk identified in the ICT framework appears in the enterprise risk register, how it is owned at the appropriate management level, and how mitigation progress is reported into the same governance forums as other operational risks. The number of firms that can demonstrate this end-to-end traceability is, in our experience, low.
This is a documentation and governance issue rather than a technical one. But the fix requires senior sponsorship — usually CRO-level — to actually re-plumb the risk management process. Year-one firms who treated DORA as a technology programme have struggled. Firms who treated it as a governance programme with technology dependencies are further ahead.
The fifth gap: information sharing arrangements
Article 45 encourages — but does not mandate — financial entities to participate in cyber threat information sharing arrangements. Many firms read this as optional and skipped it.
What firms missed is that Article 13 mandates that ICT risk management decisions be informed by current threat intelligence. The two articles, taken together, mean that firms need a defensible answer to: “where does your threat intelligence come from, how current is it, and how does it influence your risk management decisions?”
“We subscribe to a commercial threat feed” is not a sufficient answer. Regulators are looking for evidence that intelligence flows into specific decisions — which controls are tuned, which assets are prioritised, which incident playbooks are updated.
Mature firms have addressed this through a combination of commercial intelligence (we typically deploy Silent Push for adversary infrastructure mapping and ZeroFOX for digital risk and brand monitoring) and active participation in sector-specific sharing forums — FS-ISAC for financial services, CiSP for UK organisations, and equivalent national bodies in EU jurisdictions.
The intelligence pipeline matters less than the demonstrable consumption of it. Firms that have built the consumption story are well-positioned for supervisory scrutiny. Firms still relying on PDF threat reports nobody reads are not.
What to do in year two
If you are reviewing your own DORA position, the productive questions are not “are we compliant” but “would our register, our incident classification, our testing programme, our framework alignment, and our intelligence consumption survive a thorough regulatory review”.
The five gaps above are where year-one supervisory dialogue has concentrated. They are also, not coincidentally, the areas where remediation requires senior leadership engagement — not just additional control implementation. Firms that approach year two as a continuation of the technology workstream will find themselves having the same conversations with regulators that they had eight months ago.
Year two firms that get ahead of supervisory expectations are doing three things in particular: re-baselining the third-party register with genuine dependency mapping; testing failure modes that compromise the response capability itself (not just the systems being responded to); and building demonstrable links between threat intelligence consumption and risk management decisions.
None of these require new regulation, new technology, or new headcount. They require the institutional discipline to treat operational resilience as something more than a documentation exercise.
That discipline is, ultimately, what DORA is asking firms to demonstrate.
Mellivor works with UK and EU financial services firms on operational resilience programmes, including ICT third-party risk assessment, threat-led penetration testing, and incident response capability validation. To discuss your DORA programme, contact our advisory team.
