About This Template
The Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — came into force for EU financial entities on 17 January 2025. It establishes a comprehensive framework for ICT risk management, incident reporting, digital operational resilience testing, and the management of third-party ICT dependencies. While DORA is an EU regulation, it has direct relevance for UK financial firms with EU operations, EU-based counterparties, or ICT service providers subject to DORA oversight. The UK's own operational resilience framework under PS21/3 and SS1/21 covers similar ground for FCA and PRA-regulated firms.
This template helps finance and operations teams at financial firms map their critical business services, document their ICT asset dependencies, and maintain a structured incident log — the three core building blocks of a DORA-aligned operational resilience programme. It is designed to be accessible to teams that are beginning their resilience journey, while providing enough structure to support more mature programmes.
The four-sheet workbook gives you a structured starting point for the three critical mapping exercises: identifying which business services are critical, documenting the ICT assets that support them, and logging and learning from operational incidents.
What's Included
Sheet 1 — Instructions
An overview of DORA: what it is, who it applies to, the five pillars of the framework, and the key concepts of Maximum Tolerable Disruption (MTD), Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Includes a summary of how the three mapping sheets relate to each other.
Sheet 2 — Critical Business Services
The foundation of any resilience programme is identifying which business services are critical — meaning that their disruption would have a material impact on the firm, its customers, or the wider financial system. This sheet provides a structured register with pre-populated example services including:
- Payment processing
- Customer onboarding
- Safeguarding reconciliation
- Regulatory reporting
- Trading / execution
- Customer support
- API platform
- Internal finance systems
For each service, you define the owner, the Maximum Tolerable Disruption (in hours), the impact profile across financial, reputational, regulatory, and customer dimensions, the criticality rating, and whether it is subject to a regulatory obligation.
Sheet 3 — ICT Asset Register
Maps the ICT assets — software, hardware, cloud services, SaaS platforms, and third-party services — that support each critical business service. Pre-populated with 15 example assets across categories including core banking platforms, cloud infrastructure, identity and access management, payment processing providers, and internal finance systems. Key fields include the asset type, vendor, the business service it supports, whether there is a single-vendor concentration risk, sub-outsourcing arrangements, RTO and RPO, last test date, and criticality.
Sheet 4 — Incident Log
A structured log for operational incidents. Pre-populated with two example entries to show the expected level of detail. Fields cover the incident date, system and business service affected, duration, cause category (Technology / People / Process / External), customer impact, whether the incident was FCA-reportable, regulatory notification status, root cause, resolution, and lessons learned. Ten blank rows are provided for active logging.
How to Use This Template
- Start with the Critical Business Services sheet. Work with your operations, compliance, and technology leads to identify which services your firm provides that, if disrupted, would cause material harm. Do not limit the list to technology services — include any customer-facing or regulatory-critical business process.
- Assign Maximum Tolerable Disruption (MTD) figures. For each critical service, define the maximum amount of time the firm could tolerate that service being unavailable before causing unacceptable harm. Be realistic — an MTD of zero hours is rarely meaningful. Work with operational and customer teams to calibrate this figure.
- Build the ICT Asset Register. For each critical business service, identify the underlying ICT assets that enable it. Map each asset to the service it supports, document the vendor and type, and assess concentration risk. The register should be reviewed at least annually and updated whenever a new vendor relationship is established or an existing one changes materially.
- Set RTO and RPO for each ICT asset. The Recovery Time Objective is how quickly the asset must be restored after an incident; the Recovery Point Objective is the maximum data loss the firm can tolerate. These should be set in the context of the MTD for the business service the asset supports — the RTO must always be less than the MTD.
- Log and learn from incidents. Every significant operational incident — whether or not it triggers a regulatory notification — should be logged, root-caused, and reviewed. The lessons learned column is as important as the incident description itself.
- Test your arrangements. The incident log and asset register are only useful if they are tested. DORA requires firms to conduct testing proportionate to their risk profile. Significant firms must undergo Threat-Led Penetration Testing (TLPT). Smaller firms should conduct scenario testing and table-top exercises at least annually.
Frequently Asked Questions
Does DORA apply to UK firms?
DORA is an EU regulation and applies directly to financial entities operating within the EU, including UK firms with EU-regulated entities, EU branches, or those providing services into the EU under cross-border passporting arrangements. UK firms that are not operating in the EU are not directly subject to DORA. However, the UK has its own operational resilience framework under PS21/3 and SS1/21, which covers FCA and PRA-regulated firms and requires identification of important business services and setting impact tolerances — concepts that are closely aligned with DORA's approach.
What is the difference between RTO and RPO?
The Recovery Time Objective (RTO) is the maximum acceptable time to restore a system or service after an incident — it measures how quickly you need to recover. The Recovery Point Objective (RPO) is the maximum acceptable amount of data loss, measured in time — it measures how much data you can afford to lose. For example, an RPO of 1 hour means your backup or replication must be frequent enough that, even in the worst case, you lose no more than 1 hour of data. Both RTO and RPO must be set in the context of the Maximum Tolerable Disruption for the business service the system supports.
How often should I test my resilience arrangements?
DORA requires digital operational resilience testing at least annually for in-scope firms. The testing programme should be proportionate to the firm's risk profile, size, and the complexity of its ICT systems. At minimum, firms should conduct scenario-based tests and table-top exercises. Significant firms identified by their competent authority must undergo Threat-Led Penetration Testing (TLPT) every three years. Under the UK framework, the FCA expects firms to test their response and recovery capabilities for important business services and to have clear evidence of testing outcomes.
Which incidents need to be reported to the FCA under DORA?
Under DORA, major ICT-related incidents must be reported to the relevant competent authority. An incident is classified as major if it meets defined classification criteria relating to the number of clients affected, the duration of the disruption, the geographic spread, the data losses involved, and the criticality of the services affected. Initial notification must be made within 4 hours of classifying the incident as major, with an intermediate report within 72 hours and a final report within one month. Under the UK framework, similar notification obligations apply to FCA-regulated firms under existing rules on operational incidents and service outages.
What is concentration risk in the context of ICT assets?
ICT concentration risk arises when a firm is overly dependent on a single technology vendor, cloud provider, or third-party service provider, such that a failure or disruption at that provider would simultaneously impact multiple critical business services. DORA requires firms to assess and manage concentration risk as part of their ICT risk management framework. This includes identifying where multiple critical services share the same underlying vendor, assessing exit strategies, and ensuring contractual provisions allow the firm to transition away from a critical provider if necessary.
How does sub-outsourcing affect DORA obligations?
Sub-outsourcing — where your ICT service provider itself outsources elements of its service delivery to another party — creates indirect dependencies that can be difficult to manage. DORA requires firms to be aware of sub-outsourcing arrangements by their critical or important ICT third-party service providers and to ensure that their contracts contain appropriate provisions addressing sub-outsourcing. The asset register in this template includes a sub-outsourced field to flag where sub-outsourcing is present, prompting the firm to review the contractual and risk management implications.
