Accountability When a Service Fails
Accountability when a service fails is tested by the governance record made before the failure. This guide explains how decisions, challenge and follow-up show whether oversight was real.
Home / Guides
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 1 of 7, guides 1 to 41.
Backup Integrity and Isolation
Why backups fail when they are needed most: how integrity checks, separation from live systems, and protection from the same incident keep a copy trustworthy.
Benchmarking Third-Party Performance
Benchmarking ICT provider performance under DORA: comparing service, cost and resilience against peers and past performance, and recognising what a benchmark cannot prove.
Board Reporting on Resilience
Board reporting on resilience under DORA must give the management body a service view, not a technology inventory. This guide explains what useful reporting contains, and what it leaves out.
Board Responsibility for ICT Risk
Board responsibility for ICT risk under DORA means the management body owns the framework and its review. This guide separates that responsibility from delegation to executives or providers.
Board Training on ICT Risk
Board training on ICT risk under DORA is about collective understanding, not technical mastery. This guide explains how training helps a management body ask better questions and judge answers.
Business Continuity and Disaster Recovery
Why service continuity starts from tolerance and works back to restoration order, data, people and testing, rather than from a building evacuation plan alone.
Business Continuity Plans for Services
How a continuity plan for one service should read as an action sequence: service, owner, decision maker, recovery order, data, suppliers and workarounds.
Business Impact Analysis for Services
How business impact analysis identifies what harm a disruption causes, which service steps matter most, and where continuity effort should go first for each named service.
Classifying an Incident by Impact
How to judge an ICT incident by its impact on services and customers, rather than by the size of the technical fault, and how to keep that judgement consistent.
Clean Room Recovery Principles
How a clean room recovery works: rebuilding a service in an isolated space, with checked tools and fresh credentials, before anything reconnects to the live estate.
Cloud Exit and Portability
Exit is a resilience capability, not a procurement afterthought. This guide explains portability, data return, and rehearsed steps for leaving a cloud provider safely.
Cloud Regions and Availability Zones
Regions and availability zones shape where a service runs and how it survives a local failure. This guide explains what each concept does and why placement must follow the service.
Cloud Service Levels vs Tolerances
A service level measures provider performance, while a tolerance states what disruption a service can bear. This guide explains why one cannot stand in for the other.
Cloud Service Models and Resilience
Infrastructure, platform, and software services place different parts of a system in provider hands. This guide explains how each model changes control, visibility, and recovery for a service.
Cloud Shared Responsibility Explained
Shared responsibility divides cloud work between provider and firm, but the boundary is rarely where marketing draws it. This guide explains how to map it for a specific service.
Common Evidence Gaps
The gaps that recur in resilience files: missing links, undated records, unowned actions, and tests that never touched the dependency that matters most.
Concentration Risk and Critical Third Parties
Why DORA treats concentration risk as a firm-wide and sector-wide question, and how the oversight framework for critical ICT providers fits into that picture.
Continuity After a Cyber Incident
Continuity after a cyber incident: balancing containment with service recovery, checking data integrity, and returning in phases rather than rushing to restore.
Continuity and Communications Planning
Continuity communications planning: who hears what, through which channel, in what order, and how updates stay honest when facts are still emerging for each audience.
Continuity for Manual Workarounds
Manual workarounds explained: when paper and process fallbacks help a service, what controls they need, and how their later reconciliation is planned.
Continuity for People and Premises
Continuity for people and premises: staff availability, skills cover, safe working locations and remote working limits when a site or team is disrupted.
Continuity for Supplier Failure
Continuity when a supplier fails: concentration risk, degraded service options, data and exit planning, and testing what a supplier can really do in practice.
Continuity Governance and Ownership
Continuity governance and ownership: who owns a service plan, who challenges it, who decides during disruption, and who owns the follow-up afterwards.
Continuity Plan Activation Criteria
Activation criteria: pre-agreed signals, decision rights and partial activation, so a continuity plan starts promptly and does not start too late or too loosely.
Continuity Testing Without Disrupting Customers
Testing continuity without harming customers: tabletop, walkthrough and controlled exercises that expose gaps while keeping live service safe for each important service.
Contracting for ICT Services
How contracting for ICT services under DORA turns selection and due diligence into enforceable rights: audit access, security duties, cooperation in incidents, and a workable exit.
Critical ICT Third-Party Oversight Framework
How DORA organises oversight of critical ICT third-party providers at EU level, and how that framework relates to a firm's own third-party duties and oversight expectations.
Cyber Recovery after Ransomware and Outages
What cyber recovery really means after ransomware or an outage: checking backups, restoring clean, sequencing the return, and deciding when a service is safe to use again.
Deciding When to Restore a Service
Restoring is a judgement, not a switch: what evidence the decision needs, who makes it, and why business pressure alone is never a sufficient reason to return.
Designing Severe but Plausible Scenarios
How to design a scenario that is severe enough to breach tolerance yet plausible enough to be believed, using the service, its dependencies and its history as the test.
Detecting ICT Incidents Early
Detecting ICT incidents early under DORA means noticing signs of failure or attack while a service can still be contained, through monitoring fitted to the service and its risk picture.
Digital Operational Resilience Testing
How DORA testing checks whether the systems behind critical financial services would actually hold up in a real disruption, and what a credible test result looks like.
Disaster Recovery Plans for ICT
How disaster recovery for ICT restores systems and data in service order, checks integrity before reconnecting customers, and avoids restoring a problem.
Disaster Recovery Testing for ICT
Disaster recovery testing for ICT: restoring in isolation, checking data, reconnecting in service order, and turning test failures into plan changes for each service.
Documenting a Service Inventory
How to document a service inventory so that each important service, its users, its harm reasoning and its owner can be found, challenged and kept current.
Documenting Governance Decisions
Documenting governance decisions under DORA creates the record that proves oversight happened. This guide explains what to record, how to keep it usable, and why attendance alone is not enough.
DORA and NIS2 Boundaries
NIS2 and DORA both concern cybersecurity, but they are different regimes with different scopes. This guide explains the boundary without confusing the two.
DORA and Other EU Laws
DORA does not replace sectoral financial law, data law, or other EU rules. It sits alongside them, and a firm needs a map that shows where each law bites.
DORA Chapters at a Glance
A chapter by chapter map of DORA, showing how ICT risk, incidents, testing, third-party risk, and information sharing connect around one single service.
DORA Common Misunderstandings
Common DORA misunderstandings, from treating it as an IT project to treating application as completion, and what a joined-up service view shows instead.