Register for Groups and Branches
Groups and branches complicate the DORA register, because shared services, central contracts, and local arrangements must all be recorded without double counting or omission.
Home / Guides / Page 5
All guides A-Z
258 guides across 20 lines. Each one opens with a service check: the regime reference, the obligation, the start date and who has to act. Page 5 of 7, guides 165 to 205.
Register Format and Templates
Format and templates give the DORA register its comparability: consistent fields, clear labels, and a structure that lets readers and supervisors search, compare, and trust the record.
Register ICT Services and Functions
ICT services and functions are the heart of the DORA register: what each provider actually does, and which business functions would feel it if that service stopped.
Register Quality Checks
Quality checks turn the DORA register from a collection of entries into a trustworthy record, by testing links, completeness, consistency, and agreement with contracts and live services.
Register Reporting and Supervisory Use
Supervisory use is the reason the DORA register is reported in a comparable form: authorities read across registers to spot shared dependencies, concentration, and questions worth pursuing.
Register Reporting to Authorities
Reporting the DORA register to the competent authority turns an internal record into a supervisory submission, and the discipline of that handover shapes the quality of the whole register.
Reporting to Competent Authorities
Who competent authorities are in DORA incident reporting, how a firm finds the right route, and what a report to an authority should and should not contain.
Resilience and Risk Appetite
How resilience tolerances relate to risk appetite: appetite describes the risks a firm is willing to take overall, while a tolerance states the harm a particular service must not suffer.
Resilience as a Board Question
Why operational resilience belongs on the board agenda: boards decide what harm is intolerable, what recovery is expected, and whether the evidence supports those decisions.
Resilience Culture and Ownership
How culture and ownership shape operational resilience: a service recovers when its owner is known, its people speak up about weakness, and lessons change the service.
Resilience for ICT Third-Party Providers
ICT provider resilience is about harm at one remove: a cloud, software, or connectivity failure that reaches the customers of many firms at once, through firms that did not cause it.
Resilience in Asset Management
Asset management resilience turns on valuation, dealing, and settlement: whether a fund can be priced, traded, and settled correctly when a vendor, custodian, or administrator is disrupted.
Resilience in Credit Institutions
Credit institution resilience covers lending and deposit-taking together: credit lines that stay available, deposits that stay reachable, and loan records that stay accurate through disruption.
Resilience in Fintech and Challengers
Fintech resilience has a single point of failure to manage: the app. When the app is the bank, its outage is the outage, and the fallback has to be real, not assumed.
Resilience in Insurance
Insurance resilience is judged after a loss: whether a policyholder can report a claim, be assessed fairly, and be paid without a system failure adding a second hardship.
Resilience in Investment Firms
Investment firm resilience is about orders, positions, and client money: whether a client can trade, see a true position, and be protected when markets, venues, or brokers are disrupted.
Resilience in Market Infrastructure
Market infrastructure resilience is about coordination: an exchange, clearing house, or settlement system cannot recover alone, because its recovery has to line up with every participant that uses it.
Resilience in Payments and E-Money
Payments resilience is judged at the till and in the transfer: whether a merchant can trade, a customer can pay, and e-money remains reachable when a link in the chain fails.
Resilience in Pension and Fund Services
Pension and fund service resilience is about records and regular payments over long horizons: contributions recorded correctly, benefits paid as expected, and member data that stays trustworthy.
Resilience in Retail Banking
Retail banking resilience starts with a current account a household can actually use: paying bills, receiving income, and getting cash when the usual channel is down.
Resilience Maturity Without Maturity Theatre
How to judge resilience maturity honestly: by recovery evidence for named services, not by levels, colours, or programme dashboards, and by whether recovery improves over time.
Resilience Roles and Accountability
Resilience roles under DORA turn a shared ambition into named responsibility. This guide explains how management, risk, technology and assurance roles fit together without blurring ownership.
Responding to ICT Incidents
Responding to ICT incidents under DORA means containing harm, protecting customers and data, and making clear decisions while a service is disrupted, before recovery begins in earnest.
Restoring from Backups Safely
How to restore from backups without carrying the incident forward: choosing a copy, checking it first, and restoring in stages that can be paused or reversed.
Restoring ICT Systems
Restoring ICT systems under DORA means returning a disrupted service to sound operation in a planned order, checking restored systems and data before live traffic returns to them.
Reviewing Important Services After Change
How to review important services after change, so that new products, migrations, supplier moves and incidents update the list instead of quietly outdating it.
Revising a Tolerance After an Incident
How an incident should lead to revising a tolerance, what counts as evidence that a limit was wrong, and how revision is governed without turning a breach into a quiet rewrite.
Scenario Libraries and Maintenance
How a scenario library stays useful, with versioning, retirement, service links and reviews triggered by change, so old stories do not rehearse old services.
Scenario Testing and Exercises
How scenario testing turns a disruption story into decisions, rehearsals and changes, so an important service can be kept running or restored within its tolerance.
Scenario Testing for Cyber Outages
How a cyber outage scenario tests coping while systems are unavailable, including manual workarounds, customer communication and decisions about what waits.
Scenario Testing for Cyber Recovery
How cyber recovery scenarios test rebuilding cleanly, verifying integrity, and returning to normal in stages, rather than simply restarting affected systems.
Scenario Testing for Data Loss
How data loss scenarios test integrity, reconstruction and trust, when records are missing, corrupted or cannot be relied on after a disruption to a service.
Scenario Testing for Supplier Failure
How supplier failure scenarios test substitutes, exit routes and customer harm when a provider a service depends on stops, degrades or cannot be reached.
Scenario-Based Testing
How scenario-based testing rehearses a severe but plausible disruption from first failure to recovery, and why the scenario must stress decisions as well as technology.
Scenarios for Emerging Risks
How to build provisional scenarios for risks that are new, uncertain or only partly understood, using weak signals, plausible chains and regular revision.
Sector Lessons That Travel
Some resilience lessons genuinely travel across sectors, and some do not. This guide separates the two, so a payments lesson is not pasted onto pensions, or a market lesson onto insurance.
Selecting ICT Third Parties
How a financial entity selects an ICT provider under DORA, judging fit for the service, replaceability and concentration before price or familiarity decides the choice.
Self-Assessment Against DORA
How an EU firm assesses itself against DORA: working through the regulation service by service, recording the basis for each judgement, and keeping DORA separate from UK rules.
Self-Assessment Against UK Rules
How a UK firm assesses itself against the FCA and PRA operational resilience regime: important services, tolerances, mapping, and testing, labelled separately from DORA.
Service Boundaries and Sub-Services
Where one important service ends and another begins, and when a shared function or a sub-service needs its own boundary, owner and tolerance treatment.
Service Mapping Workshops
Service mapping workshops bring the people who run a service together to trace it aloud, surface hidden dependencies, and agree owners before an incident does.