The Digital Operational Resilience Act is not an IT compliance checkbox. It is a structural requirement for how financial services technology is built, governed, and recovered.
What DORA requires
The Digital Operational Resilience Act (DORA) applies to financial entities operating within the EU — banks, investment firms, payment institutions, electronic money institutions, insurance undertakings, and a significant range of other regulated financial service providers, along with their critical ICT third-party service providers.
It came into full application on 17 January 2025.
DORA requires financial entities to establish and maintain a comprehensive framework for ICT risk management. The regulation is detailed and prescriptive. It covers five core areas.
ICT risk management A documented, implemented framework for identifying, classifying, and managing ICT risks. Not a risk register. An operational framework with clear ownership, defined processes, and regular review. The framework must be integrated into the overall risk management structure of the organisation.
ICT-related incident management Defined processes for detecting, managing, classifying, and reporting ICT incidents and significant cyber threats. Major incidents must be reported to the relevant competent authority within prescribed timeframes. The classification criteria, reporting thresholds, and notification obligations are specified in the regulation.
Digital operational resilience testing Regular testing of ICT systems and tools to verify that they can withstand operational disruption. The testing programme must be proportionate to the size and complexity of the entity. For significant institutions, Threat-Led Penetration Testing (TLPT) is required on a defined cycle.
ICT third-party risk management A structured approach to managing the risks introduced by ICT third-party service providers — cloud providers, software vendors, data processors. DORA introduces specific requirements for contractual arrangements with critical third parties, including rights of access and audit.
Information and intelligence sharing Arrangements for sharing cyber threat intelligence and information within the financial sector. Participation is voluntary but the regulatory expectation is engagement.
What this means for technology architecture
DORA is not primarily a policy requirement. It is an architecture requirement.
An organisation can write documentation that describes a resilient architecture. If the architecture itself does not support resilience, the documentation is a liability rather than a defence.
Several architectural requirements follow directly from DORA’s provisions.
Recovery capability must be designed in. DORA requires ICT systems to have recovery capabilities aligned to business continuity objectives. Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) must be defined, tested, and demonstrably achievable. Architecture that has not been designed with recovery in mind cannot produce those results. Architecture that has been designed with recovery in mind cannot be retrofitted easily.
Third-party dependencies must be mapped and managed. DORA requires a register of all ICT third-party arrangements, with documented contractual requirements and risk assessments. This is only possible if the dependency map is accurate and maintained. Most organisations that have not approached this deliberately will find it is not.
Incident detection must be operational, not retrospective. DORA requires the ability to detect anomalous activity and ICT incidents in real time. Monitoring that is configured but not maintained, or that generates alerts that nobody acts on, does not meet this requirement. Detection capability must be operational.
Testing must be real. Resilience testing under DORA is not theoretical. Systems must be tested. Results must be documented. Gaps identified in testing must be addressed. An untested resilience framework is not a resilience framework.
Common gaps
For organisations working toward DORA compliance, the same gaps appear consistently.
Third-party inventory is incomplete. The register of ICT third-party arrangements does not reflect all dependencies — particularly shadow IT, departmental SaaS subscriptions, or historical integrations that predate formal vendor management processes.
Recovery objectives are aspirational, not tested. RTOs and RPOs are documented. The architecture has not been tested against them. The documentation reflects intent, not demonstrated capability.
Incident classification is ambiguous. The criteria for classifying an event as a reportable incident are not clearly defined or understood by the people responsible for making that classification. The reporting obligation is time-bound. Ambiguity is expensive.
Third-party contracts do not meet DORA requirements. Existing contracts with ICT service providers were not negotiated with DORA requirements in mind. Access and audit rights, sub-contractor notification requirements, and exit provisions may not be compliant.
The architecture approach
Operational resilience is a property of the architecture, not a layer added on top of it.
Every engagement at Sixteen Pillars that involves systems operating under DORA — or that are likely to — addresses resilience at the architectural level. Recovery capability is designed in. Dependency maps are built from the data model out. Monitoring is operational, not aspirational.
The same tested framework for security and standards is applied consistently. DORA’s requirements are specific. The architecture must meet them, not approximate them.
How we can help
DORA compliance architecture and ICT risk management frameworks are consultancy and fractional CTO engagement areas at Sixteen Pillars.
- Consultancy
- Fractional CTO
- Fractional CTO Cyprus
- Data governance for regulated industries
- DORA — what your technology function must do now
Frequently asked questions
Does DORA apply to my organisation? DORA applies to a wide range of financial entities operating within the EU, including banks, investment firms, payment institutions, insurance undertakings, and crypto-asset service providers, among others. It also applies to critical ICT third-party service providers to these entities. If you operate a regulated financial service in the EU, the regulation almost certainly applies.
When did DORA come into force? DORA entered into full application on 17 January 2025. There is no further transition period.
What is the difference between DORA and GDPR compliance? GDPR governs the protection of personal data. DORA governs the operational resilience of ICT systems in financial services. They overlap in areas such as incident reporting and data security, but they address different regulatory obligations and require different organisational responses.
Does DORA apply to technology vendors serving financial services firms? Critical ICT third-party service providers — cloud providers, software vendors, data centres — that provide services to financial entities in scope are subject to DORA requirements. The financial entity is responsible for ensuring its third-party arrangements meet the regulation.
What is Threat-Led Penetration Testing? TLPT is a form of advanced resilience testing required under DORA for significant financial entities. It simulates real threat actor behaviour to test the resilience of live production systems. It differs from standard penetration testing in scope, methodology, and required expertise.
Free interactive tool
Interactive deadline calculator
Check which regulations apply to you and when
Regulation across the EU, UK, US and Asia-Pacific has moved considerably in the past eighteen months, and several headline dates have shifted more than once. Twelve questions, about three minutes.
Results are shown on screen — no email required. A dated summary is available to download, and can be sent on if that's more useful. What we do with your answers.