Compliance is not resilience

The Digital Operational Resilience Act is now enforceable across the EU, and the ripple effects are reaching UK firms through contractual requirements, cross-border operations, and regulatory expectations. Most organisations we speak to have done something about DORA. Few have done the right things.

The most common pattern we see is a compliance-led approach: map DORA's requirements to existing controls, fill the gaps on paper, produce a report for the board, and move on. The problem is that DORA is not really about compliance. It is about whether your organisation can actually withstand and recover from a serious ICT disruption. That is a fundamentally different question, and answering it requires testing, not documentation.

Third-party oversight is where most firms are weakest

DORA places significant emphasis on ICT third-party risk management, and this is where we see the biggest gaps. Most organisations have a vendor register and a questionnaire process. Very few have genuine visibility into how their critical suppliers manage security, how resilient those suppliers are to disruption, or what happens when a key provider goes down.

The challenge is compounded by concentration risk. Many firms rely on the same small number of cloud providers, managed service partners, and SaaS platforms. When one of those has an outage - and they do - the blast radius extends across the entire client base. DORA expects firms to understand this and plan for it. Most have not.

We have worked with financial services firms to build supplier assurance programmes that go beyond questionnaires. This means direct evidence review, targeted assessments of critical vendors, and realistic testing of what happens when a key dependency fails. It is more work than sending a spreadsheet, but it produces assurance that actually holds up.

Incident reporting needs forensic capability, not just process

DORA mandates strict timelines for reporting ICT-related incidents. The intent is good - faster, more transparent reporting benefits the whole sector. But the reality is that many firms cannot diagnose an incident accurately within the required timeframe.

Rushed reporting leads to incomplete disclosures that get corrected later, creating confusion with regulators and undermining credibility. The fix is not a better reporting template. It is better detection and forensic capability so that when something happens, the security team can determine what occurred, what was affected, and what the impact is - quickly and accurately.

Resilience testing needs to hurt

DORA requires resilience testing, including threat-led penetration testing for significant firms. The issue is that many organisations treat testing as a validation exercise rather than a stress test. Pre-scripted scenarios with agreed scope and advance notice do not tell you how your organisation would respond to a real incident at two in the morning on a Friday.

Effective resilience testing should be uncomfortable. It should expose gaps in communication, decision-making, and recovery. It should reveal whether your backups actually work under pressure, whether your incident response plan survives first contact with reality, and whether your team knows what to do when the playbook runs out.

What we recommend

If your DORA programme has been compliance-led so far, it is not too late to shift. Start by testing your recovery capability for real - not on paper, but by simulating disruption to a critical service and measuring how long it takes to restore. Review your third-party risk programme against what DORA actually expects, not what your questionnaire covers. And invest in detection and forensic capability so that incident reporting is accurate, not just fast.

DORA is a genuinely useful regulation if it drives real resilience. The firms that treat it as a box-ticking exercise will find out the hard way that compliance certificates do not restore services.