DORA in its second year: what supervisors are actually testing

The first DORA cycle was a documentation exercise for most financial entities: build the register of information, map critical or important functions, and paper the contractual clauses with ICT third-party providers. That phase is closing. The questions arriving from supervisors now are operational — can you demonstrate that the resilience you described on paper survives contact with a real incident?

In practice this means three things. First, incident classification has to be defensible: the thresholds you apply to decide whether an event is major must be written down, consistently applied, and traceable to the decisions your team took at the time. Second, the digital operational resilience testing programme has to be risk-led rather than calendar-led — testing the same three systems every year because they are easy to test is now a finding. Third, exit strategies for critical providers must be costed and rehearsed, not merely asserted.

Boards should expect the register of information to be used as an audit index rather than a compliance artefact. Every contract flagged as supporting a critical or important function invites a follow-up question about concentration, substitutability and monitoring evidence.