DORA explored: what the Digital Operational Resilience Act means for your organisation

The Digital Operational Resilience Act (DORA) came into force in January 2025. It establishes binding requirements for digital operational resilience across financial services and their technology supply chains operating within the EU. For organisations already navigating CAF, DSPT, NIS2, and other regulatory frameworks, DORA adds another set of obligations around ICT risk management, incident reporting, resilience testing, and third-party oversight.

Understanding what DORA requires, which organisations are in scope, and how the infrastructure underneath your services affects your ability to evidence compliance is increasingly relevant for UK regulated organisations – not only those in financial services.

What is DORA?

DORA is a regulatory framework introduced by the European Union to strengthen the operational resilience of financial services and the technology providers that support them. Its primary purpose is to ensure that organisations can withstand, respond to, and recover from ICT-related disruptions, and that they can demonstrate they have done so.

DORA applies to a wide range of entity types: banks, insurers, investment firms, payment processors, trading venues, credit rating agencies, crypto-asset service providers, and critically for technology suppliers, ICT third-party service providers to any of the above.

The five pillars of DORA

• ICT risk management. Organisations must implement and maintain a comprehensive ICT risk management framework, covering risk identification, protection, detection, response, and recovery. The framework must be documented, reviewed regularly, and auditable.
• ICT incident reporting. Significant ICT incidents must be reported to the relevant competent authority within defined timeframes. The thresholds and classification criteria for what constitutes a reportable incident are set by DORA and its implementing technical standards.
• Digital operational resilience testing. Organisations must test their resilience regularly, including basic testing for all in-scope entities and threat-led penetration testing (TLPT) for those classified as significant. Testing must be documented and findings acted upon.
• Third-party ICT risk management. Organisations must actively manage the risks arising from their ICT third-party providers, including contractual requirements, ongoing monitoring, and due diligence. Certain providers are designated as Critical ICT Third-Party Providers (CITPs) and are subject to direct oversight by EU supervisory authorities.
• Information sharing. DORA encourages sharing of cyber threat intelligence and information about vulnerabilities between financial entities and across the sector, to improve collective resilience.

What is the UK position?

Post-Brexit, DORA is EU legislation and does not directly apply to UK-domiciled firms in the same way. However, UK organisations are not straightforwardly outside its scope.

UK firms that conduct regulated financial market activities within the EU are subject to DORA. UK-based ICT third-party providers whose clients include EU financial services firms will face DORA requirements through their contractual relationships with those clients. And UK financial services regulators, including the FCA and PRA, have their own operational resilience frameworks that share significant ground with DORA in terms of the underlying requirements.

The practical position for many UK regulated organisations is that DORA-aligned practices are either directly required, contractually imposed by EU clients, or increasingly expected by UK regulators pursuing parallel objectives. The alignment between DORA, NIS2, and the Bank of England’s operational resilience framework means that the compliance work has broad applicability beyond any single regulatory label.

Why infrastructure matters for DORA

The requirements DORA imposes are not abstract. They translate directly into what your infrastructure needs to do and what evidence it needs to produce.

• ICT risk management requires that the components of your digital infrastructure, connectivity, cloud environments, security controls, and third-party integrations, are documented, risk-assessed, and managed under a defined framework. An estate running on ungoverned point solutions with no unified view is difficult to evidence under this requirement.
• Incident reporting requires that you can detect significant incidents promptly, classify them accurately, and report them within tight timeframes. This depends on having telemetry and alerting across your estate that is consolidated rather than fragmented across multiple provider portals.
• Resilience testing requires that you can test your infrastructure under realistic disruption scenarios and document the results and subsequent remediation. A managed service provider should be conducting and evidencing this on your behalf, not leaving it as your team’s responsibility.
• Third-party risk management requires that you know which ICT providers you depend on, what your contractual rights are with respect to audit and assurance, and that you can demonstrate ongoing monitoring of those providers. The same applies to the providers you are for your own clients: your ability to evidence your own security and resilience posture is now a commercial and regulatory expectation, not just an internal governance matter.
• The evidence requirement is continuous. DORA, like CAF, DSPT, and NIS2, expects evidence of ongoing compliance, not a point-in-time snapshot assembled before a review. The infrastructure underneath your services needs to produce that evidence as a by-product of running, not as a quarterly project.

What good looks like

Organisations that are well-positioned for DORA compliance tend to share a few characteristics.

They have a unified view of their estate, across connectivity, security, cloud, and remote access, rather than separate views across separate provider portals. Incidents are visible in one place and can be classified and reported quickly. Change records are generated automatically and are auditable without manual assembly.

Their third-party provider relationships are governed by contracts that include audit rights, SLA evidence, and security posture reporting. They receive that evidence on an ongoing basis rather than having to request it before an assessment.

Their resilience testing is documented, the findings are tracked, and the managed services they use are tested as part of the same programme rather than sitting outside it.

And their compliance evidence, the change records, patch logs, incident history, security posture reports, and SLA delivery data, is generated as a by-product of how the platform operates rather than assembled retrospectively.

How managed infrastructure supports DORA compliance

A managed connectivity and security platform that generates compliance evidence as part of its operating model addresses several DORA requirements directly. Change records are captured automatically. Security posture is reported continuously. Incidents are visible in a single view with the context to classify and escalate quickly. Third-party provider assurance is documented through the service rather than sitting as a separate audit engagement.

This is the argument for building DORA compliance into the operating model rather than treating it as a compliance overlay on top of infrastructure that was not designed to evidence itself.

Cloud Gateway delivers connectivity, security, observability, and compliance evidence as part of one managed platform. For more on how the Assure pillar works and how evidence is generated as a by-product of the service, see our Assure page and our platform page.