DORA Compliance Checklist for UK Financial Services: A Step-by-Step Guide

Picture this. You open your banking app, and nothing works. Not just for you, but for millions of people. Payments fail. Salaries do not reach. Businesses stop. And no one knows when it will be fixed.

This is not a rare situation. In 2018, TSB Bank faced a massive IT failure that locked around 1.9 million customers out of their accounts and led to a £48.65 million fine. One technical issue turned into a full financial crisis overnight.

Now think bigger. Attacks like SolarWinds and major ransomware incidents showed one thing clearly, financial systems are deeply connected, and one weak link affects everyone.

This is exactly why DORA exists. It treats technology failures not as small glitches, but as serious risks to the entire financial system. And for UK firms connected to the EU, this is not optional, it is already in action.

For UK firms, DORA brings a double layer of responsibility. You still follow FCA and PRA rules for operational resilience. But if your business connects with the EU in any way, through clients, partners, or as a tech provider, DORA rules apply on top of that. Ignoring either side creates risk from two directions at the same time.

This guide keeps things simple and clear. It explains who needs to follow DORA, what the five key areas actually mean in practice, and what non-compliance could cost in real terms. You will also see a step-by-step path to become compliant without confusion or unnecessary complexity.

No jargon. No overcomplication. Just a practical DORA compliance checklist that helps you take the right action.

The Definitive DORA Scope Table for UK Firms

Before you build a compliance programme, you need to know whether you need one. Here is the complete breakdown of UK entity types, their DORA status, and the FCA equivalent – in one place.

Unlike EU countries where DORA is a direct law, UK firms only need to follow it if they work with the EU. This includes serving EU customers, partnering with EU firms, or offering ICT services to EU banks.

At the same time, the UK is moving in a similar direction. The Financial Conduct Authority (FCA) and PRA are already working on stronger rules under the Financial Services and Markets Act 2023, especially around Critical Third Parties. Many people are already calling this “UK DORA.”

This means one thing, aligning with a DORA compliance checklist today is not just about EU exposure. It also supports FCA operational resilience UK requirements and prepares your business for upcoming regulation.

For firms working on core banking integrations, investing in banking automation UK, or exploring AI in banking, this becomes even more important. Strong UK financial services resilience is no longer optional, it is expected.

The RegTech Compliance Landscape: What UK Digital Banks Must Navigate

Before we dive into how RegTech solves these challenges, let’s understand the battlefield. This is the regulatory map every UK digital bank operates in, and it’s not for the faint-hearted.

ICT Risk Management Framework (Pillar 01) (Article 5–16)

DORA mandates that your board, not your IT department, owns ICT risk. This is the cultural shift that most UK firms underestimate. The governance must be documented, board-approved, and reviewed at least annually.

✔ Establish a board-approved ICT Risk Management Framework (IRMF) with defined roles, responsibilities, and annual review cycles
✔ Map all critical business services to their underlying ICT systems and data flows (full dependency mapping)
✔ Conduct a comprehensive ICT risk assessment covering confidentiality, integrity, availability, and authenticity (CIAA)
✔ Implement and document information security policies aligned to ISO 27001 or NIST CSF
✔ Define and enforce multi-layered network segmentation, access controls (RBAC/ABAC), and encryption standards (AES-256 at rest, TLS 1.2+ in transit)
✔ Establish change management procedures with pre-migration testing requirements (the TSB lesson)
✔ Define Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for all critical systems
✔ Maintain a live ICT asset inventory updated at minimum quarterly
✔ Implement continuous vulnerability scanning and patch management SLAs (Critical: 72hrs, High: 7 days)
✔ Appoint a named ICT Risk Manager at senior executive level with direct board reporting line

ICT-Related Incident Management & Reporting (Pillar 02) (Article 17–23)

When something goes wrong, and with cyber threats rising, it is a matter of when, not if, DORA gives you very little time. The reporting timelines are tight and the classification criteria are precise. This is where most firms stumble.

✔ Establish a documented ICT incident management process with classification criteria based on DORA’s materiality thresholds
✔ Build an escalation matrix from Level 1 (minor disruption) to Level 3 (major ICT incident requiring regulatory notification)
✔ Implement SIEM (Security Information and Event Management) tooling capable of real-time incident detection and log correlation
✔ Submit Initial Notification to competent authority within 4 hours of classifying a major ICT incident (or no later than 24 hours from detection)
✔ Submit Intermediate Report with root cause analysis within 72 hours of the initial notification
✔ Submit Final Report with full remediation timeline within 1 month of the incident
✔ Classify incidents using the EU harmonised taxonomy (impact on clients, geographic spread, economic impact, reputational consequences)
✔ Maintain an ICT incident register with status tracking, timestamps, classification, and evidence logs
✔ Conduct post-incident reviews (PIRs) within 2 weeks of resolution for all Major ICT Incidents
✔ Integrate incident reporting workflows with FCA regulatory reporting (GABRIEL / RegData) to avoid double-entry burden

Digital Operational Resilience Testing (Pillar 03) (Article 24–27)

Think of this as stress-testing your digital systems, similar to how the Bank of England tests financial stability. DORA requires different levels of testing, from basic scans to advanced simulations like Threat-Led Penetration Testing (TLPT), which mimics real-world cyber attacks.

✔ Conduct annual vulnerability assessments across all in-scope ICT systems using authenticated scanning tools (Tenable, Qualys, or equivalent)
✔ Perform annual scenario-based testing simulating real disruption events (cloud outage, ransomware attack, supply chain failure)
✔ Implement Threat-Led Penetration Testing (TLPT) at least once every 3 years for significant firms, using the TIBER-EU framework
✔ Conduct quarterly penetration testing for internet-facing critical systems and payment gateways
✔ Execute Business Continuity Plan (BCP) and Disaster Recovery (DR) drills at least twice a year with proper documentation
✔ Test backup restoration monthly, not just backups, but full data recovery and validation
✔ Conduct Red Team exercises to test detection and response end-to-end
✔ Document all test results, define actions, assign owners, and track progress to closure with evidence
✔ Ensure TLPT results are reviewed by the board and shared with regulators where required
✔ Apply proportionality, smaller firms may follow simpler testing plans but must clearly document the risk-based reasoning

Third-Party ICT Risk Management (Pillar 04) (Article 28–44)

This is the pillar that keeps many UK IT leaders on edge. Under DORA, if your cloud provider, SaaS vendor, or data centre fails, the responsibility still sits with you. Saying “it was the vendor’s fault” is no longer acceptable under the regulation.

✔ Build and maintain a complete ICT Third-Party Register (ICTPSR), including direct and important indirect (fourth-party) providers
✔ Classify all third-party ICT relationships based on criticality and clearly document how this is assessed
✔ Perform pre-contract checks covering financial stability, security standards, business continuity, and compliance status
✔ Ensure all ICT contracts include key DORA clauses such as audit rights, service levels, incident reporting, data portability, and exit terms
✔ Review existing contracts and update them with DORA requirements (January 2025 deadline — check status immediately)
✔ Map all sub-contractors (fourth-party risk) for critical services, not just primary vendors
✔ Conduct annual third-party risk assessments with proper documentation
✔ Create clear exit strategies and transition plans for all critical ICT providers, including concentration risk scenarios
✔ Monitor third-party performance regularly using KPIs and KRIs with defined escalation points
✔ Engage with suppliers marked as Critical Third-Party Providers (CTPPs), as they will face direct regulatory oversight

Information Sharing Arrangements (Pillar 05) (Article 45)

DORA encourages firms to share cyber threat information with each other. It is not strictly mandatory, but it is strongly recommended. Think of it like a financial sector “neighbourhood watch,” where firms share risks, attack patterns, and warning signs to stay protected together.

✔ Assess eligibility and join trusted cyber threat intelligence sharing groups within the financial sector
✔ Set up internal processes to receive, review, and act on threat intelligence from ISACs (Information Sharing and Analysis Centres)
✔ Share anonymised incident data and indicators of compromise (IoCs) where legally allowed
✔ Integrate threat intelligence into your SIEM and detection systems (using formats like STIX/TAXII)
✔ Ensure all sharing follows confidentiality rules and complies with UK GDPR and the Data Protection Act 2018
✔ Review and update your participation in these networks at least once a year
✔ Inform the FCA if you are part of cross-border intelligence sharing involving EU organisations

The £330 Million Warning: What TSB’s IT Disaster Tells Every UK Bank About DORA

If there is one case study that encapsulates why DORA exists, it is TSB Bank in 2018. And it did not happen in a small obscure fintech. It happened at a mainstream UK high street bank with millions of customers.

What the Industry Is Saying About DORA

The DORA discussion is very much alive on social platforms and in boardrooms. Here is the kind of sentiment resonating across UK financial services communities.

The UK’s NCSC regularly publishes cyber resilience guidance aligned with DORA principles.

The Cyber Defence Alliance (a consortium of UK and EU banks) has been particularly active in sharing threat intelligence relevant to DORA Art. 45 information-sharing obligations.

How UK Financial Firms Are Using Technology to Achieve DORA Compliance

Compliance does not have to mean armies of manual reviewers and spreadsheet-driven audits. The most forward-thinking UK firms are deploying automation and AI in banking compliance programmes to meet DORA obligations at scale.

FAQs: DORA Compliance Checklist