What DORA requires
DORA establishes a unified framework for ICT risk management across the EU financial sector, covering banks, insurers, investment firms, payment institutions and their critical third-party providers. Its five pillars — ICT risk management, incident reporting, digital operational resilience testing, third-party risk management, and information sharing — are not new concepts, but the regulation introduces binding technical standards and supervisory oversight where previously only guidance existed.
The most operationally demanding requirements centre on Threat-Led Penetration Testing (TLPT) for significant institutions, the ICT third-party register (a detailed inventory of all technology providers and their contractual terms), and the major incident reporting timeline — 4 hours for initial notification, 72 hours for the intermediate report.
Where institutions are struggling
Our work with financial institutions across the compliance journey has identified three systemic gaps that are proving difficult to close quickly.
Third-party inventory completeness. Most institutions discovered during the mapping exercise that their actual ICT dependency landscape was significantly broader and more complex than their documented asset register suggested. Shadow IT, undocumented integrations and multi-tier supply chains created substantial blind spots. Building an accurate, maintained register is proving to be a multi-quarter programme, not a documentation exercise.
Incident classification and escalation. The boundary between an operational incident and a reportable major incident under DORA requires clear, pre-agreed criteria embedded in runbooks, not left to real-time judgement during an outage. Many institutions' existing ITSM processes lack the granularity DORA demands, and the cultural shift — towards proactive regulatory notification — is significant.
TLPT readiness. Threat-led penetration testing is substantively different from conventional penetration testing. It requires intelligence-led scoping, red team capabilities and a controlled testing environment that most institutions are building from scratch. Finding qualified TLPT providers with the requisite regulatory recognition is also proving challenging in the current market.
A pragmatic compliance roadmap
Institutions that have navigated DORA most effectively have approached it as a resilience programme, not a compliance exercise. The difference is consequential: compliance thinking drives checkbox behaviour, while resilience thinking drives the investment in processes and capabilities that actually reduce operational risk.
In practical terms, this means prioritising the ICT risk management framework and third-party register as foundational infrastructure — these unlock the other requirements — and treating the incident management upgrade as an opportunity to modernise ITSM tooling that was overdue for replacement regardless of DORA.
Architek's view
DORA is the most consequential regulatory change for financial sector IT architecture since PSD2. Institutions that treat it as a technology and process challenge — rather than a legal and documentation one — will emerge with genuinely stronger operational resilience. Those that don't will face ongoing supervisory attention and, more importantly, real vulnerability to the disruption scenarios the regulation was designed to address.