DORA compliance is now a live operational issue for financial services, but UK firms need to handle the topic with precision. The Digital Operational Resilience Act is an EU regulation. It applies to many EU financial entities and to the way those entities manage ICT risk, incidents, resilience testing, information sharing, and critical technology providers. It does not automatically turn every UK-only firm into a directly regulated DORA entity.
That does not make DORA compliance irrelevant to UK financial services. UK groups with EU entities, UK firms serving EU clients, technology providers supporting EU financial entities, and firms aligning group-wide resilience standards may all feel the effect. DORA also lands in a market where UK regulators have already pushed banks, insurers, payment firms, investment firms, and other in-scope firms to identify important business services, set impact tolerances, map dependencies, test disruption scenarios, and improve third-party oversight.
The practical question is therefore not, “Does DORA replace UK operational resilience?” It does not. The better question is, “Where does DORA compliance overlap with the resilience work UK financial services should already be doing?” For many firms, the answer will be ICT asset mapping, incident escalation, supplier registers, contract clauses, cyber testing, continuity evidence, and board-level ownership.
This guide is not legal advice. It is a practical technology and governance guide for UK leaders who need to understand what DORA compliance means, where UK obligations sit alongside it, and how to build a defensible operational resilience plan.
DORA compliance at a glance
The European Securities and Markets Authority explains that DORA entered into force on 16 January 2023 and applies from 17 January 2025. Its purpose is to strengthen the ICT security of financial entities and make sure the financial sector in Europe can stay resilient during severe operational digital disruption.
DORA compliance brings several disciplines together. ESMA lists ICT risk management, ICT third-party risk management, digital operational resilience testing, ICT-related incident management and notification, cyber-threat information sharing, and oversight of critical third-party ICT providers. That is why the topic belongs with operations, technology, risk, legal, compliance, procurement, and the board, not only with the cyber team.
For UK financial services, the useful starting point is a gap map:
| Area | DORA focus | UK resilience overlap |
|---|---|---|
| ICT risk | Policies, controls, protection, detection, response, recovery | Important business service mapping and vulnerability remediation |
| Incidents | Classification, escalation, reporting, learning | FCA/PRA incident notification and 2027 operational incident reporting changes |
| Testing | Digital operational resilience testing and advanced testing for some entities | Severe-but-plausible scenario testing against impact tolerances |
| Suppliers | ICT third-party risk, contracts, registers, exit planning | Outsourcing, third-party risk management, and critical third-party oversight |
| Governance | Management body accountability and evidence | Board and senior management responsibility for resilience outcomes |
DORA compliance is best treated as an evidence programme. Policies matter, but regulators, customers, auditors, and counterparties will care about whether critical services are mapped, controls are operated, incidents are rehearsed, suppliers are governed, and recovery can be shown.
Why UK financial services should pay attention
The FCA says operational resilience is the ability of firms, financial market infrastructures, and the financial sector to prevent, adapt and respond to, recover from, and learn from operational disruption. Its rules came into force on 31 March 2022, and in-scope firms had until 31 March 2025 to make sure they could operate important business services within impact tolerances.
That UK regime is not the same as DORA compliance, but the operating logic is close. Both regimes care about the services customers and markets rely on. Both care about the technology and suppliers behind those services. Both expect firms to understand vulnerabilities, test plausible disruption, communicate during incidents, and invest where resilience is weak.
There are several reasons a UK firm may still need a DORA compliance view. A UK-headquartered group may include EU-regulated entities. A UK service provider may support an EU bank, insurer, investment firm, payments business, or trading venue. A UK firm may inherit contractual requirements from an EU counterparty. A global technology risk function may choose one resilience standard for the group. A board may also want DORA alignment because it sharpens UK operational resilience evidence.
The safe position is to confirm scope, then use the overlap. Do not claim DORA compliance where legal scope has not been assessed. Do not ignore it because the firm is UK-based. Treat it as a trigger to make operational resilience more testable, supplier-aware, and evidence-led.
1. Confirm scope before assigning work
The first step is a scope decision. Before launching a DORA compliance project, list the legal entities, regulated permissions, EU branches, EU subsidiaries, client relationships, outsourced services, group policies, and technology services that could bring the firm into direct or indirect DORA conversations.
Scope should not be guessed by the IT team. Legal, compliance, risk, procurement, operations, and technology should agree the working view. The output should separate direct regulatory obligations, contractual expectations from clients or counterparties, group-standard alignment, and optional good practice.
For UK-only firms, the scope exercise is still useful. It stops DORA compliance becoming a vague label for every cyber project. It also identifies where UK obligations remain the primary driver: FCA rules, PRA expectations, outsourcing requirements, payment services rules, cyber insurance evidence, customer contracts, and board risk appetite.
Ask four questions at the start:
| Question | Why it matters |
|---|---|
| Do we have EU-regulated financial entities or branches? | This may create direct DORA obligations. |
| Do we provide ICT services to EU financial entities? | Clients may flow DORA requirements into contracts and assurance requests. |
| Do group policies require EU-standard alignment? | A global control baseline may simplify governance. |
| Which UK rules already require similar evidence? | This prevents duplicated work and conflicting control owners. |
2. Map important services to ICT assets and suppliers
DORA compliance becomes real when services are mapped to the technology that delivers them. Start with the business services that matter most: payments, trading, customer access, claims, lending, policy administration, settlement, treasury, customer support, regulatory reporting, and core finance operations.
For each service, document the applications, infrastructure, identity paths, data stores, network links, endpoints, monitoring tools, support teams, third-party suppliers, fourth parties where known, recovery dependencies, and manual fallbacks. The aim is not a beautiful architecture diagram. The aim is a map that can be used during an incident or a test.
The FCA PS21/3 policy statement required in-scope firms to identify important business services, set impact tolerances, carry out mapping and testing, and identify vulnerabilities. That work gives UK firms a strong base for DORA compliance alignment. If the map cannot show which ICT assets and suppliers support a service, it cannot support resilience decisions.
This is also where hybrid-work architecture matters. If staff need secure access from branches, home offices, or supplier locations, the service map should include identity, device posture, remote access, SaaS routes, and monitoring. Progressive Robot’s guide to the Anywhere Office covers that wider access model for hybrid teams.
3. Strengthen ICT risk management controls
ICT risk management is the control core of DORA compliance. It covers how the firm protects systems, detects abnormal activity, responds to incidents, recovers services, and learns from disruption. For UK firms, this should not sit in a separate DORA spreadsheet. It should connect to the existing cyber security, operational resilience, and supplier governance control library.
Start with a baseline that leaders can understand. Which systems are critical? Which accounts are privileged? Which vendors can access production? Which logs are retained? Which backups have been restored? Which vulnerabilities are overdue? Which systems are unsupported? Which controls depend on one person or one provider?
The strongest DORA compliance evidence is operational. A policy says what should happen. A dashboard, test result, ticket trail, access review, backup restore, incident exercise, and supplier review show whether it actually happens. That distinction matters when resilience is challenged by a cyber attack, failed change, cloud outage, or supplier incident.
For many UK firms, identity is the most urgent control area. Finance applications, administrator consoles, remote support tools, and SaaS platforms are all account-driven. A review of Identity-First Security can help connect DORA compliance to MFA, privileged access, device checks, session monitoring, and joiner-mover-leaver discipline.
4. Prepare incident classification and communications
Incident handling is where operational resilience either becomes calm or chaotic. DORA compliance expects financial entities to manage ICT-related incidents and notify major ones to competent authorities. UK firms also need to understand existing FCA notification expectations and upcoming UK reporting changes.
The FCA’s reporting operational incidents page says current reportable indicators include material disruption to financial services, large customer impact, unauthorised access to information systems, significant data loss, and unavailability or loss of control of IT systems. It also explains that new operational incident reporting rules will come into force on 18 March 2027, with a standardised process for incidents that pose risks of intolerable harm, safety and soundness concerns, or market stability and confidence issues.
DORA compliance work should therefore create one practical incident framework. It should define severity, service impact, customer harm, system control loss, data loss, regulatory notification triggers, client notification triggers, evidence capture, and executive decision points. Avoid parallel runbooks where the cyber team, compliance team, and service desk each use different language.
Communications need equal attention. The FCA’s CrowdStrike outage observations highlighted the value of mapped important business services, tested severe-but-plausible scenarios, clear communication strategies, third-party pathways, and post-incident review. Those are not abstract governance points. They are the difference between a firm that can explain disruption and a firm that spends the first day trying to find owners.
5. Test resilience with severe-but-plausible scenarios
Testing is one of the most useful parts of DORA compliance because it turns assumptions into evidence. A firm may believe its payment process can survive a supplier outage, its trading desk can work from another site, or its customer portal can recover within tolerance. Testing shows what is true.
Use scenarios that cross technology and business boundaries. Examples include a failed identity provider, ransomware on a supplier remote-management platform, a cloud region disruption, loss of a call-centre application, data-centre network failure, an endpoint security update problem, a payments outage, or a loss of staff access during a regional incident.
The PRA’s SS1/21 supervisory statement sets expectations for operational resilience of important business services and impact tolerances. It frames resilience as a proportionate minimum standard that improves the resilience of firms and the wider financial sector to operational disruptions. That aligns well with DORA compliance testing: prove whether important services remain within tolerance, then fix the gaps.
Testing should include people, not only platforms. Can decision makers be reached? Can the supplier respond? Can the help desk handle customer messages? Can logs be preserved? Can the business run a manual workaround? Can the firm show what happened after the event? This is where MSP to MSSP thinking becomes relevant, because monitoring, response, escalation, and evidence often sit partly with managed service partners.
6. Tighten ICT third-party contracts and registers
Third-party risk is central to DORA compliance because financial services now depend on cloud platforms, SaaS systems, data processors, managed service providers, telecoms, endpoint tools, identity platforms, payment processors, and specialist software vendors. The firm may own the customer relationship, but a supplier failure can still stop the service.
The PRA’s SS2/21 supervisory statement sets expectations for outsourcing and third-party risk management, including data security, business continuity, and exit plans. It complements operational resilience expectations and is relevant to banks, building societies, PRA-designated investment firms, insurers, reinsurers, and certain branches.
DORA compliance adds pressure to make ICT supplier governance more structured. Firms should maintain a register of material ICT arrangements, map supplier services to important business services, understand subcontracting, define notification duties, test continuity assumptions, review concentration risk, and keep exit plans credible. Contract clauses should support audit, access, incident notification, data location, resilience testing, recovery expectations, and cooperation during regulatory reviews.
The UK is also building its own critical third-party regime. The FCA, PRA, and Bank of England PS24/16 statement says the final rules for critical third parties took effect from 1 January 2025, but it also stresses that the rules do not change firms’ responsibility for their own resilience and third-party supplier management. That point is vital: supplier oversight cannot be outsourced away.
7. Align governance, budgets, and evidence
DORA compliance can fail if it is treated as a one-off compliance project. Resilience is a management system. It needs owners, budgets, risk acceptance, metrics, evidence, supplier reviews, remediation tracking, and board reporting.
UK financial services should create a single resilience governance rhythm. Operational teams should review vulnerabilities, incidents, service maps, supplier performance, and control exceptions. Risk and compliance should confirm regulatory interpretation, reporting triggers, and evidence requirements. Senior management should review impact tolerances, open vulnerabilities, major supplier risks, investment decisions, and residual risk.
The output should be understandable. Leaders need to know which important services are inside tolerance, which services depend on fragile suppliers, which incidents changed the risk view, which tests failed, and which investments are needed. A 200-row control spreadsheet may be useful to the project team, but it will not help the board make decisions.
This is where a vCIO advantage can help. DORA compliance touches IT strategy, supplier management, cyber security, cloud governance, budgets, and executive accountability. It needs a roadmap that balances risk reduction with operational reality.
A 90-day action plan
In the first 30 days, confirm scope and build the evidence baseline. List entities, services, clients, EU touchpoints, critical suppliers, important business services, systems, applications, privileged accounts, and existing UK operational resilience artefacts. Decide where DORA compliance is direct, indirect, contractual, or useful alignment.
In days 31 to 60, map the highest-risk services. Choose three to five services that could create customer harm, market disruption, safety and soundness concerns, or major contractual exposure. Map technology, data, suppliers, support teams, recovery routes, incident triggers, and manual workarounds. Compare the map with existing FCA/PRA operational resilience work.
In days 61 to 90, test and prioritise remediation. Run at least one severe-but-plausible scenario, review third-party contract gaps, confirm incident reporting paths, and create a board-ready risk view. The goal is not to finish DORA compliance in one quarter. The goal is to replace uncertainty with scope, ownership, evidence, and a funded improvement plan.
If local power, connectivity, or facilities failures could disrupt payment, branch, contact-centre, or support operations, link this work to Power-Independent Infrastructure planning. Digital resilience often fails at the physical edge.
Mistakes to avoid
The first mistake is treating DORA compliance as an EU-only issue and then missing contractual, group, supplier, or customer expectations. The second mistake is treating it as a generic cyber project and ignoring service impact, operational tolerance, third-party dependencies, and evidence.
The third mistake is duplicating UK and EU resilience work. A UK firm should not maintain separate maps, runbooks, supplier registers, and incident definitions unless it has a strong reason. Harmonised evidence is easier to operate and easier to explain.
The fourth mistake is relying on supplier reassurance. A cloud provider, SaaS vendor, MSP, or security vendor may be resilient at platform level while the firm’s own configuration, access model, contract, monitoring, or manual fallback remains weak.
The fifth mistake is waiting for a regulator, client, auditor, or insurer to ask for evidence. DORA compliance is easier to build before a disruption, renewal, contract review, or board challenge creates pressure.
FAQ
Does DORA apply directly to every UK financial services firm?
No. DORA is an EU regulation, so direct applicability depends on the firm’s legal entities, activities, and EU regulatory footprint. UK firms should take legal and regulatory advice on scope. Even where direct DORA compliance is not required, UK firms may face indirect expectations through EU entities, clients, group policy, supplier contracts, or operational resilience alignment.
How is DORA different from UK operational resilience?
DORA is an EU digital operational resilience regulation focused on financial entities and ICT risk. The UK operational resilience regime is built around important business services, impact tolerances, mapping, testing, remediation, and communications. They are different regimes, but DORA compliance overlaps strongly with UK resilience work around ICT dependencies, incidents, testing, suppliers, and governance.
What should a UK firm do first?
Confirm scope, then map important services to ICT assets and suppliers. A firm cannot prioritise DORA compliance sensibly until it knows whether it is directly in scope, indirectly affected, or mainly using DORA as a benchmark for resilience maturity.
Are third-party providers responsible for our resilience?
No. Providers have obligations under contracts and, in some cases, regulatory oversight regimes. But financial firms remain accountable for the resilience of the services they provide and for managing supplier risk. Contracts, monitoring, testing, exit plans, and incident cooperation all need firm ownership.
Can DORA work support cyber insurance and assurance?
Yes. The evidence created for DORA compliance can support wider assurance if it shows mapped services, tested recovery, controlled access, supplier oversight, incident runbooks, and governance. Progressive Robot’s guide to Cyber Insurance Red Flags explains why insurers increasingly care about evidence, not just policy statements.
Bottom line
DORA compliance should not be treated as a distant EU paperwork exercise by UK financial services. It should be treated as a prompt to make digital operational resilience more specific, testable, and supplier-aware.
Start with scope. Then map services to technology and suppliers, strengthen ICT controls, define incident reporting paths, test severe-but-plausible scenarios, tighten contracts, and create board-level evidence. Even where DORA does not directly apply, the discipline behind DORA compliance can help UK firms build resilience that customers, regulators, boards, and counterparties can trust.
