DORA, Two Years In: What Financial Organisations Have Actually Learned

The lesson nobody flagged early enough

DORA was widely treated as a third-party risk management exercise: map your ICT vendors, get contractual clauses updated, tick the register. That part was manageable. What caught organisations out was resilience testing — specifically, proving operational continuity on the systems that are hardest to test without disrupting live service. For most financial institutions, that means the mainframe.

Where the friction actually shows up

• Testing core banking platforms without risking production.
• Resilience testing obligations don't pause for the fact that your core ledger runs on infrastructure you can't casually take offline.
• Documenting recovery capability, not just claiming it.
• Regulators want evidence of tested recovery times, not policy documents describing intended ones.
• Concentration risk on infrastructure providers.
• Ironically, the systems most in-house and longest-running — mainframe estates — have turned out easier to evidence resilience for than some of the newer cloud-dependent services DORA was arguably written with in mind.

What's next

Supervisory attention is shifting from "have you done the mapping" to "can you prove it under stress." That's a harder bar, and it rewards organisations that treated DORA as an operational capability question rather than a documentation exercise from the start. If your resilience testing programme still leans more on paperwork than proof, it's worth a second look before the next supervisory cycle.