Mapping Services Dependencies and Systems
A service map traces one service to the people, processes, systems, data and suppliers it needs to run, so a disruption has a path to follow and an owner to call.
Home / Guides / Page 4
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 4 of 7, guides 124 to 164.
Mapping Single Points of Failure
Mapping single points of failure finds the one person, system, supplier or store whose loss alone would stop a service, so it can be covered or redesigned.
Mapping Third-Party Dependencies
Mapping third-party dependencies records every supplier a service relies on, what each supplies, and how the service copes if that supplier fails or degrades.
Measuring Concentration Risk
How a financial entity can build a picture of concentration that counts shared dependencies, not just supplier names, across its important services and recovery planning.
Minor Incidents and Near Misses
Why minor incidents and near misses deserve attention under DORA, how to record them without drowning the team in paperwork, and what patterns they reveal before a major incident.
Multi-Cloud and Avoiding Lock-In
Using more than one cloud can reduce lock-in, but only if workloads can actually move. This guide explains the difference between spreading services and building genuine portability.
Network Security Testing
How network security testing checks the paths into and between a firm's systems, and why segmentation and supplier connections deserve the closest attention.
Operational Resilience by Sector
Why the same resilience questions give different answers by sector, and how to read a sector guide by naming its service, its users, and the harm when that service stops.
Operational Resilience for Small Firms
How smaller firms approach operational resilience with fewer services, fewer people, and heavier reliance on suppliers, without copying a large firm programme.
Operational Resilience Glossary
Plain language explanations of the terms used across operational resilience: important services, tolerances, mapping, scenarios, and the evidence that ties them together.
Operational Resilience vs Business Continuity
How operational resilience differs from business continuity: one asks what harm users suffer when a service stops, the other plans how work resumes after disruption.
Operational Resilience vs Cyber Risk Management
How operational resilience differs from cyber risk management: cyber work reduces the chance and impact of attacks, while resilience asks whether users can still be served during one.
Outsourcing and Cloud Dependencies
Outsourcing does not move accountability away from the firm owning the service. This guide explains how DORA treats cloud and outsourcer dependence, tolerance, recovery, and evidence.
Outsourcing and Data Location
Where data sits affects recovery, access, and legal exposure. This guide explains how a firm maps data location for outsourced services and why a provider region label is not enough.
Outsourcing and Regulatory Access Rights
Regulatory access rights let supervisors and the firm examine a provider when it matters. This guide explains audit, information, and inspection rights, and why they must work in practice.
Outsourcing Contract Renewals and Changes
Renewal and change are when outsourcing risk quietly shifts. This guide explains how to review a contract, assess provider changes, and keep service protection intact through both.
Outsourcing Due Diligence Records
Due diligence records show why a provider was chosen and what was checked before signing. This guide explains what to examine, what to keep, and when to revisit it.
Outsourcing Governance and Oversight
Governance turns a signed contract into ongoing oversight. This guide explains how a firm monitors providers, challenges performance, and keeps decisions about a service in its own hands.
Outsourcing Incident Responsibilities
When an outsourced service fails, provider and firm must already know who tells whom, who decides, and who acts. This guide explains how incident responsibilities are divided and rehearsed.
Outsourcing Risk Assessments
Risk assessment asks what could harm a service through a provider, and what would limit that harm. This guide explains how to assess outsourcing risk in service terms, not vendor terms.
Outsourcing to Group Entities
Group outsourcing can feel safer because the provider sits inside the group, but DORA still expects arm's length governance, clear contracts, and independent oversight of the service.
Outsourcing vs ICT Third Party Services
DORA uses ICT third party services as the wider category, with outsourcing as a narrower arrangement inside it. This guide explains why that distinction changes governance, contracts, and evidence.
Oversight During the Contract
How oversight during an ICT contract works under DORA: monitoring the service that depends on the provider, checking that evidence matches that service, and acting on early warning signs.
Performance and Load Testing
Why a system that works well for a handful of users can still fail at peak demand, and how load testing finds that breaking point before customers do.
Proportionate Testing Programmes
Why a DORA testing programme should grow with risk, complexity, and scale, and how a smaller firm can still test the systems its critical functions depend on.
Protecting ICT Systems
Protecting ICT systems under DORA means reducing the chance that a risk interrupts a service and limiting the damage when it does, through controls fitted to the service and its risk picture.
Readiness Assessments for New Services
How to assess a new service before it goes live: mapping it, setting its tolerance, testing its dependencies, and refusing to launch on assertion alone.
Readiness Checklists That Help
What makes a readiness checklist useful instead of cosmetic: a check tied to a service, an arrangement that can be shown, and a result that changes what happens next.
Readiness Without Overclaiming
How to describe readiness honestly: claiming only what tests and incidents have shown, labelling what is untested, and resisting language that outruns the evidence.
Recovery and Data Corruption
When restored data itself cannot be trusted: how corruption is found, how far it may have spread, and how a firm chooses between repairing, rebuilding, and starting again.
Recovery Communication During an Outage
What to say while a service is down and coming back: honest status, clear limits, and updates that keep customers and staff acting on the same understanding.
Recovery Evidence and Lessons
What a recovery leaves behind: decision records, restore logs, and lessons that actually change the next plan, rather than a report that is filed and forgotten.
Recovery Sequencing for a Service
The order in which a service returns matters: which foundations come first, which journeys follow, and why restoring a channel before its records is a false recovery.
Recovery Testing and Rehearsal
Rehearsals that actually teach: testing a restore under realistic conditions, finding where the plan breaks, and fixing the plan before an incident finds it first.
Recovery Time and Recovery Point Thinking
Recovery time and recovery point thinking explained qualitatively: how quickly a service returns, and how much recent data can be lost, both driven by tolerance.
Recovery vs Business Continuity
Recovery and business continuity are related but not the same: one keeps a service going through disruption, the other brings it back clean after it has failed.
Reducing Concentration Without Breaking Services
Practical ways to lower concentration risk, from splitting services to strengthening exit plans, without introducing disruption that outweighs the benefit.
Register and Third-Party Risk Link
The register and third-party risk management feed each other: the register maps dependence, risk work judges what that dependence means, and its findings should flow back into the record.
Register Contractual Arrangements
Contractual arrangements in the DORA register turn provider relationships into checkable facts: the agreement, its parties, its scope, and the terms that shape continuity and exit.
Register Data and Locations
Data and locations in the DORA register show what information each ICT arrangement touches and where the related activity takes place, giving supervisors a view of movement and concentration.
Register Entity and Branch Information
Entity and branch information anchors the DORA register: exactly which financial entity the record covers, how its branches are treated, and why precise identification prevents confusion.