On 19 July 2024, a single flawed software update took down an estimated 8.5 million Windows devices worldwide. In the UK, GP surgeries lost access to patient records and appointment systems, train departure boards went blank during the morning rush, airports cancelled flights, and small businesses were pushed onto cash-only tills when card payment systems stopped working. None of it was a cyber attack. It was one third-party update, cascading into services that had never been mapped as depending on it.
That's the part a lot of business continuity plans miss. You can have a plan that's signed off, tested and sitting in a folder, and still be caught out, because the plan covers what happens if your building floods or your server room loses power, without ever setting out which of your critical activities actually depend on which supplier, system or person. A continuity plan is only as good as the dependency map underneath it, and for a lot of UK organisations, that map doesn't really exist.
This piece sets out what a business dependency actually is in continuity terms, why it's become a sharper regulatory and practical issue over the last two years, and how to start identifying yours before something forces the question.
What counts as a business dependency
In continuity planning, a dependency is anything a critical activity needs in order to keep running. ISO 22301, the international standard for business continuity management, requires organisations to identify the internal and external dependencies that support what it calls their prioritised activities: the processes that matter most when something goes wrong. In practice, those dependencies tend to fall into a handful of categories, and most organisations are reasonably confident about some of them and genuinely unsure about the rest.
| Dependency type | What it covers | A question worth asking |
| People | The specific individuals or skills a process relies on, including anyone whose knowledge isn't written down anywhere else. | If this person were unavailable tomorrow, who else could do their part of the job? |
| IT systems and applications | The software, platforms and infrastructure a process runs on, including 25 anything hosted by a third party. | Which systems would need to be working for this activity to happen at all? |
| Data | The information a process needs to function, and where it's stored, 35 backed up and accessed from. | If this data were unavailable or corrupted, could the activity still 39 happen in any form? |
| Suppliers and third parties | Any external organisation a process relies on, directly or indirectly, 46 including suppliers of your suppliers. | Do we know what happens to this activity if that supplier has an outage? |
| Facilities | The physical premises, equipment or workspace a process needs. | Could this activity be carried out from a different location, and how quickly? |
| Utilities and connectivity | Power, telecoms and network connectivity that everything else usually 65 assumes is just there. | What's our actual exposure if connectivity to this site goes down? |
The Business Continuity Institute's Good Practice Guidelines set out a formal version of this exercise, the business impact analysis, which estimates how the impact of losing each dependency grows over time and uses that to set recovery priorities. It's a more structured process than most businesses attempt informally, but the underlying question is the same one in the table above, asked activity by activity rather than assumed at the level of the whole organisation.
Where those dependencies actually concentrate tends to point at what needs fixing. If IT systems and data are doing the heavy lifting, that's usually a disaster recovery and backup conversation. If it's facilities, work area recovery covers the physical side: somewhere your people can actually work if the building itself becomes the thing that's unavailable. And if suppliers or the wider cyber layer are the exposed dependency, that's where security monitoring and incident response earn their keep, rather than a plan that assumes the threat only ever comes from inside your own network.
Why dependency mapping has become harder to ignore
For financial services firms, this stopped being optional in March 2025. Under the FCA's operational resilience rules, in-scope firms had until 31 March 2025 to be able to remain within impact tolerance for each of their important business services during a disruption. Impact tolerance is a deliberately different measure to a recovery time objective: it's not just how fast you can recover a system, it's the maximum tolerable disruption to customers, measured in whatever terms actually matter, such as transaction values or numbers of customers affected. Meeting that standard is close to impossible without first mapping which people, systems, data, facilities and third parties sit behind each important service.
We've seen what that looks like in practice. A global bank we worked with needed a purpose-built business continuity centre because their previous arrangement couldn't give them confidence about failover against IT failure, cyber incidents and extreme weather at the same time. That's impact tolerance stopped being a document and turned into a physical facility, which is what mapping dependencies properly tends to lead to sooner or later.
That's a financial services rule specifically, so if you're outside that sector it doesn't apply to you directly. But the government's direction of travel points the same way for everyone else. The UK Government Resilience Action Plan, published in July 2025, is explicit that a lack of resilience in a business or its supply chain can lead to significant financial and reputational damage, and sets out plans for a new Supply Chain Centre and expanded guidance aimed at businesses well beyond the regulated sectors. Whether or not a regulator will ever ask you for evidence, the practical case for knowing your own dependencies doesn't really depend on being told to.
The government's own Cyber Security Breaches Survey 2025/2026 suggests plenty of UK organisations haven't got there yet. Only 25% of businesses overall have a formal incident response plan, ranging from 21% of micro businesses up to 76% of large ones. More strikingly, the proportion of small businesses with a business continuity plan that covers cyber security actually fell, from 53% in 2024/2025 to 44% in 2025/2026. We can't say with certainty why that dropped rather than continued to improve; the survey doesn't give a single explanation, and it would be guessing to pin it on any one cause. What the figures do show is that continuity planning isn't a box that gets ticked once and stays ticked. It needs revisiting as the business changes, and dependency mapping is usually the part that goes stale first, because new suppliers and systems get added far more often than anyone updates the plan to reflect them. We've looked separately at what that downtime actually costs UK businesses when the gap catches up with them, which is worth reading if you need the financial case to take to the rest of the business.
The dependencies that tend to get missed
A lot of UK businesses have a reasonable handle on their obvious IT dependencies: the core finance system, the customer database, the main office network. What tends to fall through the gaps is everything one step removed from that. Other companies discover, usually during an actual incident, that a critical process depends on a supplier's supplier they'd never heard of, or on one person's informal workaround that nobody else in the business could replicate. Neither of those shows up on a standard IT asset register, because neither one looks like an IT asset. Catching that kind of gap before it becomes an incident is really the argument behind proactive IT support: someone actively looking for the dependency nobody's written down, rather than only turning up once it's already failed.
The CrowdStrike outage is a useful illustration precisely because it wasn't really an IT failure in the traditional sense. GP practices didn't lose their own systems; they lost access to a shared platform that ran on infrastructure they didn't control and, in most cases, didn't know they were exposed to until it went down. Card payment terminals failed for small retailers who'd never thought of themselves as depending on a cyber security vendor at all. That's the pattern worth planning for: the dependency that matters most in a real disruption is often the one that's furthest from where you'd naturally think to look.
It works the other way too. A housing association we worked with removed single points of failure across its infrastructure entirely, re-architecting for near-zero recovery time rather than treating failover as something bolted on afterwards. Once a dependency's been mapped and understood, it's often possible to design it out altogether instead of just planning around it.
| A plan without dependency mapping | A plan built on dependency mapping |
| Dependencies are documented per system, in isolation | Dependencies are mapped per critical activity, showing everything that activity needs to function |
| Third-party risk stops at your direct suppliers | Third-party risk extends to the suppliers your suppliers rely on, where that's known |
| The plan assumes key people will be available | The plan identifies where one person's knowledge is a single point of failure |
| Dependency information is reviewed when the plan is renewed | Dependency information is updated when a new system, supplier or process is introduced |
| Recovery targets are set the same way for every system | Recovery targets reflect how quickly each dependency's absence actually starts to hurt |
Where to start mapping your own dependencies
You don't need to map everything at once, and trying to is usually why the exercise stalls. Start with the activities that would genuinely stop the business, or cause real harm to customers, if they failed: not every process, just the ones that matter most. For each one, work through the dependency types in the table above and write down what you actually know, including the gaps. An honest 'we don't know who else could run this' is a more useful outcome than skipping the question.
Once you know what an activity depends on, you're in a position to set a sensible recovery target for it rather than a generic one applied across the board. We've written separately about the difference between a recovery time objective and a recovery point objective, and how to set each one; that's worth reading alongside this if you're getting into the detail of specific systems. If connectivity turns out to be where your exposure actually sits, why intelligent connectivity matters for business uptime goes further into that specific dependency on its own.
If the exercise feels bigger than something to run internally alongside everyone's day job, that's a reasonable conclusion, not a failure. Our operational resilience consultancy is built around exactly this: working through your business-critical processes and operations with you to identify dependencies and gaps through a structured business impact analysis, rather than leaving it as a document nobody quite finishes.
For further reading, our resource centre has more on this alongside what's here, including a look at disaster recovery versus business continuity if the distinction between the two still feels blurry, and a 10-step guide to building a disaster recovery plan once your dependencies are mapped and you're ready to put the recovery side in place.
Talk to us about mapping your dependencies
Knowing what your critical activities actually depend on is what turns a continuity plan from a document into something you could genuinely rely on during a bad week. If you're not sure where the gaps are in yours, we're happy to talk it through, whether that means a specific look at operational resilience or a broader conversation about your business continuity set-up. Talk to us.
FAQs
What's the difference between business continuity planning and dependency mapping?
Business continuity planning covers the whole process of preparing for and responding to disruption. Dependency mapping is one part of that: identifying the people, systems, data, suppliers, facilities and utilities each critical activity actually relies on. A continuity plan can exist without proper dependency mapping underneath it; it just tends to be less useful when something specific goes wrong.
Is dependency mapping only a regulatory requirement for financial services?
The specific FCA rules on mapping important business services and their dependencies apply to regulated financial services firms. Outside that sector there's no direct legal requirement in the same form, though the UK Government Resilience Action Plan sets out a general push for businesses to understand their dependencies and supply chains, and the practical benefit of knowing your own exposure doesn't depend on which sector you're in.
What's an impact tolerance and how is it different from a recovery time objective?
A recovery time objective is the maximum time you're aiming to take to recover a system. An impact tolerance, as used in FCA operational resilience rules, is broader: the maximum disruption a business service can cause before it becomes unacceptable, measured in terms like customer numbers affected or transaction values, not just time. Setting either one properly depends on knowing what the service actually relies on.
How often should a dependency map be reviewed?
There's no single fixed interval that suits every organisation, so treat this as a starting point rather than a rule: reviewing whenever a new system, supplier or major process changes, alongside at least an annual check, tends to keep the map closer to reality than reviewing only when the wider continuity plan comes up for renewal. Dependencies change more often than most plans get updated.
What's the first step if we've never mapped our dependencies before?
Start with the activities that would cause the most harm if they stopped, not every process in the business. For each one, work through what people, systems, data, suppliers, facilities and utilities it actually needs, and be honest about what you don't currently know. That gap list is often more useful early on than the parts you can already answer confidently.
About the author
Colin Jeffs MBCI transitioned into business continuity from IT project management, where resilience was a core requirement of system implementation. He has over 30 years’ experience in business continuity, operational resilience, and crisis management, holding senior leadership roles within major financial institutions in the City of London. Colin now leads Wavenet’s award-winning operational resilience consulting and software division and co-designed the latest version of Shadow-Planner.
