OperationalResilience.help
The Continuity Desk - important services, kept running

Important services, kept running

When disruption arrives, the service is the thing that must survive

The Continuity Desk is an independent guide to operational resilience for regulated organisations. It follows one backbone through every guide: organisation, important business service, dependency, ICT system, third party, disruption, impact tolerance, incident, testing, recovery, evidence, regulator.

Start with what operational resilience is, or follow the service map below. Every guide opens with a service check and names the regime it explains, so DORA duties and FCA/PRA duties are never mixed.

A calm operations room where a team reviews a service map on a large wall board
The continuity desk at work: the service on the wall, its dependencies traced, its tolerance in view.

Service map

Twenty lines, each one a cluster of guides completed whole. Pick the line that holds the service, the dependency, or the disruption you are working on.

Line 01 - Foundations line Operational resilience foundations What operational resilience means, how it differs from cybersecurity alone, and how the backbone of this site runs: service, dependency, disruption, tolerance, test, recovery, evidence. 14 guides Line 02 - Service line Important business services How to identify the services whose disruption would cause intolerable harm, who uses them, and where the boundary of a service sits. 11 guides Line 03 - Mapping line Service mapping and dependencies Mapping a service to the people, processes, technology, data and third parties it actually depends on, so a disruption has a traceable path. 16 guides Line 04 - Tolerance line Impact tolerances Setting a tolerance for each important service: how much disruption, for how long, and with what data loss, before harm becomes intolerable. 9 guides Line 05 - Risk line ICT risk management The ICT risk management framework at the centre of DORA: identifying, protecting, detecting, responding and recovering, as one joined-up system. 13 guides Line 06 - Incident line Incident management and reporting Classifying an ICT-related incident, managing it while the service is down, and reporting it to the right authority in the right phase. 15 guides Line 07 - Testing line Digital operational resilience testing Testing whether resilience works before a real disruption tests it: proportionate testing programmes, from tabletop work to live exercises. 10 guides Line 08 - Threat-led line Threat-led penetration testing Threat-led penetration testing under DORA: what it is, who it applies to, how a test is scoped, and what happens to its findings. 14 guides Line 09 - Third-party line ICT third-party risk Managing the risk that arrives with a supplier: selection, contracting, oversight, exit, and the difference between a supplier and a dependency. 12 guides Line 10 - Outsourcing line Outsourcing and cloud dependencies Outsourcing and cloud: where responsibility stays with the firm even when the system sits elsewhere, and how concentration creeps in. 16 guides Line 11 - Concentration line Concentration risk and critical third parties When many services lean on one provider, one region, or one technology: measuring concentration and the oversight framework for critical providers. 9 guides Line 12 - Register line Register of information The register of information DORA requires: what it records about ICT third-party arrangements, how it is kept, and who it is reported to. 13 guides Line 13 - Continuity line Business continuity and disaster recovery Business continuity plans and disaster recovery that are written for a service, not for a building: restoring the service within its tolerance. 15 guides Line 14 - Recovery line Cyber recovery and restoration Recovering after a cyber incident: clean restoration, data integrity, sequencing, and the decision to bring a service back. 11 guides Line 15 - Governance line Governance, board oversight and accountability Who owns resilience at board level, what the board must approve and review, and how accountability is evidenced rather than asserted. 14 guides Line 16 - DORA line The DORA regime in full DORA as a whole regime: scope, proportionality, chapters, technical standards, application dates, and how the pieces fit together. 10 guides Line 17 - UK line FCA and PRA operational resilience The UK regime, labelled as a separate regime throughout: FCA and PRA operational resilience, its own policy statements, dates and expectations. 16 guides Line 18 - Sector line Operational resilience by sector How the same backbone plays out differently in banking, insurance, payments, asset management, fintech, and for ICT providers themselves. 12 guides Line 19 - Scenario line Scenario testing and exercises Severe but plausible scenarios, exercises that rehearse them, and the lessons that change a plan instead of sitting in a report. 13 guides Line 20 - Evidence line Evidence, audit and readiness Proving resilience to a regulator, an auditor, or a board: evidence trails, examinations, self-assessment, and the gaps that recur most often. 15 guides

How the desk works

01
Identify the service
Name the important business service, its users, and the harm if it stops. A service without a boundary cannot be protected.
02
Map the dependencies
Trace the service to its people, processes, systems, data, and third parties. Every dependency is a path a disruption can travel.
03
Set the tolerance
State how much disruption the service can absorb before harm becomes intolerable, in duration, scope, and data terms.
04
Test, recover, evidence
Rehearse severe but plausible scenarios, restore the service within its tolerance, and keep the evidence that proves it happened.

How this desk works

Engineers restoring a service in a bright control room
Recovery in progress: the service returns in sequence, with its data checked before it is trusted again.

Three habits. First, primary sources only: the regulation text on EUR-Lex for DORA, the European Supervisory Authorities for its technical standards, and the FCA and PRA policy statements for the UK regime, linked from every guide. Second, regimes stay labelled: a guide that explains DORA says so, a guide that explains the UK regime says so, and a guide that compares them keeps the two columns apart. Third, corrections are published, not buried: the corrections page records what changed and why. The desk explains what firms must be able to do when a service is disrupted. It does not advise any individual firm on its own compliance position, and it never promises a resilience outcome.

Topics index

Browse the whole site by line in the service map index, or search the full list in all guides A-Z. The line guides are the starting point for each line; the working guides under them carry the detail.