DORA ICT Risk Management Framework
Under DORA, ICT risk management joins identification, protection, detection, response and recovery into one framework for a financial service, reviewed as technology and threats change over time.
Home / Guides / Page 2
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 2 of 7, guides 42 to 82.
DORA Implementation Timeline
DORA implementation is a rolling programme, not a single deadline. Readiness, application, standards, testing, and supervision each move on their own rhythm.
DORA Proportionality Principle
Proportionality in DORA calibrates depth and detail to risk, size, and complexity. It does not remove duties, and it never excuses weak treatment of a critical service.
DORA Register of Information
The DORA register of information maps ICT third-party arrangements at entity level, so supervisors can see the dependencies behind a financial entity and the entity can keep that picture current.
DORA Scope and Financial Entities
Which financial entities DORA names, how ICT third-party providers fit into its picture, and where scope stops, explained through the services a firm provides.
DORA Scope, Proportionality and Timeline
DORA read as one regime: who it covers, how proportionality shapes the work, and why the timeline runs beyond a single application date, explained for financial services.
DORA Supervision and Enforcement
Competent authorities supervise DORA, the ESAs coordinate, and critical ICT providers face dedicated oversight. Evidence is judged service by service, not by policy alone.
DORA Technical Standards Explained
Technical standards fill in DORA with templates, classifications, and registers. They are developed by the ESAs and apply on their own stated dates, not all at once.
Due Diligence Before Contracting
What due diligence before contracting looks like under DORA: checking a provider against the specific service it will support, and testing whether the evidence matches that service.
End-to-End Testing of a Service
How end-to-end testing follows a complete customer journey across every system, team, and supplier it touches, rather than testing each part in isolation.
Evidence After an Incident
What to preserve, record, and review after a disruption, so the incident becomes a lasting improvement to the service trail rather than a story that fades.
Evidence Audit Examinations and Readiness
How evidence, audit and examination fit together for one service, so a claim about resilience can be checked by an auditor, a supervisor, or a board without a scramble.
Evidence for Board Assurance
What a board needs to judge resilience assurance: service-level evidence, gaps stated plainly, and a clear distinction between assertion and observed performance.
Evidence Retention and Access
How long resilience evidence should be kept, in what form, and who should be able to find it, so the trail survives staff changes and can be produced without a scramble.
Evidence Trails for a Service
How to build the checkable trail for one service, from its map and tolerance through its tests and incidents, so each claim can be followed back to a record.
Exercises for Incident Teams
How incident team exercises test roles, handovers, decision logs and coordination under pressure, including when the team itself is tired or incomplete.
Exercises for the Board
How board exercises test strategic judgement, risk appetite, external communication and oversight, rather than technical detail or operational procedure.
Exit Strategies for ICT Providers
How exit strategies for ICT providers work under DORA: planning departure before it is needed, so data, knowledge and transition assistance are available when a service must move.
External Audit and Assurance
How external assurance differs from internal audit: a defined scope, an outside reader, and a report whose wording and limits need to be read as carefully as its conclusion.
FCA and PRA Impact Tolerances in the UK
Impact tolerances under the UK regime: what intolerable harm means for a named service, how tolerances differ from targets, and why they must reflect the user experience.
FCA and PRA Important Business Services in the UK
How UK firms identify important business services under FCA and PRA rules: starting from customer harm, naming services clearly, and avoiding lists that hide real journeys.
FCA and PRA Mapping in the UK
Mapping under the UK regime: tracing every person, process, system, facility and third party a named service depends on, including single points of failure.
FCA and PRA Operational Resilience Regime
The UK operational resilience regime explained: important business services, impact tolerances, mapping, scenario testing and self-assessment under FCA and PRA rules.
FCA and PRA Scenario Testing in the UK
Scenario testing under the UK regime: designing severe but plausible disruptions, rehearsing recovery against a tolerance, and learning from where the service would fail.
FCA and PRA Self-Assessment in the UK
Self-assessment under the UK regime: the board level account of services, tolerances, maps, testing and gaps, and why honest gaps strengthen rather than weaken it.
From Policy to a Service That Recovers
How a resilience policy becomes a service that actually recovers: naming, mapping, tolerating, testing, fixing, and evidencing, in that order, for one named service.
Geographic Concentration
How reliance on one region can link otherwise separate services, and what a geographic view adds to a provider-by-provider risk picture across important services.
Governance and Risk Appetite Statements
Risk appetite statements under DORA governance translate board tolerance into boundaries for ICT risk decisions. This guide explains how appetite is set, used and revisited without inventing numbers.
Governance Board Oversight and Accountability
Under DORA, board oversight means decisions, challenge and tracked follow-up, not attendance alone. This pillar guide explains how governance turns ICT risk into accountable action.
Governance for ICT Third-Party Risk
Governance for ICT third-party risk under DORA keeps the management body in control of services run partly outside the entity. This guide explains oversight of providers, concentration and exit.
Governance for Small Firms
Governance for small firms under DORA must be proportionate, not absent. This guide explains how a smaller management body oversees ICT risk with fewer people and clearer priorities.
Governance of Testing and Findings
Governance of testing and findings under DORA turns test results into board decisions. This guide explains board oversight of scope, severity and remediation until findings close.
Governance Reporting Lines and Escalation
Reporting lines and escalation under DORA governance ensure bad news reaches the management body in time to act. This guide explains clear routes and the culture that makes them work.
How Regulators Test Resilience
How supervisors test operational resilience in practice: through service maps, tolerances, scenario evidence, and follow up, rather than through policy documents alone.
ICT Asset Management
ICT asset management under DORA means knowing what technology a service depends on, who owns it, where it sits and how it is supported, so risk, protection and recovery can be aimed accurately.
ICT Incident Classification and Reporting
A plain guide to how DORA incident classification and reporting works: restoring the service, deciding what counts as major, and keeping a record that stands up later.
ICT Risk and Change Management
ICT risk and change management under DORA means assessing technology change before it goes live, so a service improvement does not become a new source of disruption or exposure.
ICT Risk Appetite and Reporting
ICT risk appetite and reporting under DORA turn a service risk picture into clear tolerances and regular information for decision makers, so risk decisions are explicit and traceable.
ICT Risk for Cloud Systems
ICT risk for cloud systems under DORA concerns services that depend on shared, remotely operated platforms, where visibility, control and recovery are shaped by the supplier relationship.
ICT Risk Management Documentation
ICT risk management documentation under DORA records the framework for a service in a form that others can follow, test and review, without becoming a substitute for the framework itself.
ICT Risk Reviews and Assurance
ICT risk reviews and assurance under DORA test whether the framework describes the service accurately and works under disruption, through independent challenge and evidence, not repetition.