Principaux enseignements
- Business continuity plans map the technology behind a service in detail, then stop before mapping the people, processes, and third parties it depends on outside IT. The UK’s FCA confirmed this exact pattern in its 2026 one-year review of operational resilience self-assessments. (FCA, Operational Resilience: Insights and Observations One Year On, March 2026)
- A map that stops at technology can’t show which entity, country, or team owns a service once it crosses a boundary, because it never recorded where the boundaries are. DORA’s Article 11(5) requires a business impact analysis that weighs mapped functions, processes, third-party dependencies, and their interdependencies together, not system criticality alone. (DORA, Article 11(5))
- Vendor dependency mapping stops at the first name on the contract. ISO 22301 requires identifying the internal, outsourced, and supply chain dependencies behind every activity in scope, not just documenting that a plan exists. (ISO 22301, Business Continuity Management Systems)
- Technology mapping and dependency mapping answer two different questions. Business continuity management programs finish only the first one.
In This Article
A business continuity mapping gap is the distance between a service mapped for technology recovery and a service mapped for the full range of entities, people, processes, and vendors that keep it running. A continuity team can list every server, every failover site, and every recovery time objective behind a cross-border payments service, and still not know how many countries that service touches, or which of them would keep it running if one link failed. That gap shows up in business continuity management long before an incident does, and it's the one regulators keep confirming.
The cause is a mapping gap, not a testing failure or a thin continuity team. It shows up in business continuity management (BCM) long before an incident does, and it’s the one regulators keep confirming.
Business Continuity Plans Map the Technology and Stop There
A detailed technology inventory for an important business service can exist without anyone knowing which countries, functions, or vendors that service depends on outside IT. The UK’s Financial Conduct Authority (FCA) found the same pattern in its 2026 review: firms mapped systems in detail but had done less work on the people, processes, and third parties tied to the same service.
The FCA treats that as unfinished work rather than failure. Firms that mapped their infrastructure well now face a second, harder job: mapping everything a service depends on that isn’t a server.
This is the resilience gap, the same mapping gap measured against what DORA and the FCA now expect.
The Boundary a Technology Map Can’t Show
A technology map answers a single question. What supports this service? It doesn’t answer where that service crosses from one entity, country, or team into another, because that boundary was never what it was built to show. DORA’s Article 11 requires a business impact analysis that weighs mapped functions, third-party dependencies, and their interdependencies together, not the criticality of any one system alone.
The UK’s important business service concept asks the same question in different words. What does this service need to survive, and where does that list stop being something IT can answer on its own? Neither regime cares whether the map is elegant. Both care whether it’s complete enough to trust during a live incident, when guessing which country or vendor sits behind a failing service is no longer an option.
What’s the Difference Between a Technology Map and a Dependency Map?
The distinction shows up as two different maps. One shows what supports a service, the version infrastructure and IT disaster recovery teams already maintain well. The other shows what a service depends on to keep running: every entity, country, and vendor it touches. Regulators used to accept the first as proof of readiness. DORA and the FCA are now checking for the second.
| Technology Mapping | Cartographie des dépendances | |
| Answers | What supports this service | What this service depends on to survive |
| Typically owned by | IT | Often nobody specifically |
| Stops at | The application and its infrastructure | The entity, country, vendor, and subcontractor behind it |
| Checked by regulators | Rarely, on its own | Increasingly, under DORA and the FCA’s important business service rules |
The first column comes together without much effort. The second column takes real work, and carries real risk.
One Vendor Can Hide an Entire Chain of Dependencies
A vendor contract usually names one company, and the mapping stops right there. That vendor’s own subcontractors, and the infrastructure they lease from, go unmapped almost by default. ISO 22301 requires organizations to identify the internal, outsourced, and supply chain dependencies behind every activity in scope, not simply to record that a plan exists.
The dependency that causes the outage is usually two or three names past the one on the contract, sitting on infrastructure nobody in the room assessed directly.
None of this shows up on a map built to answer “do we have a vendor” instead of “what does this vendor depend on.”
What a Complete Business Continuity Map Must Include
A complete business continuity map ties every important business service to five things at once, not just the technology behind it:
- The technology behind it: the applications and infrastructure most programs already map well
- The people who run it: the specific teams and roles who keep the service live, not a generic owner
- The processes that carry it: the steps, manual or automated, the service actually depends on day-to-day
- The entities and countries it passes through: the legal and geographic boundaries that change who has the authority to act
- The third parties, including their own subcontractors, it depends on: the vendors, and the vendors behind those vendors, most assessments never reach
Leave out any one of the five, and the map can look finished while still hiding the boundary that matters.
This takes more than a bigger spreadsheet. It’s a different question asked about every service instead of some of them, not just what supports this, but where it crosses a line that changes who’s responsible.
Map It Before the Next Incident Forces the Question
Go back to the payments service this piece opened with. Its technology map was probably fine, every server, every failover site, every recovery time objective accounted for. What it couldn’t show was which countries the service ran through, or which of them would keep it alive if one link failed. Nobody had asked that the map answer that question.
This is common. Business continuity management programs get built with real care on the technology side and left unfinished everywhere else. Regulators are only now asking to see the rest of it, and an incident won’t wait for the map to catch up.
A BCM manager who has mapped the five things above has more than the average program can produce today. A CRO or COO who has that map ready knows the answer before an incident ever forces the question. Everyone else is still managing paperwork.
Turn Your Plan Into a Map Regulators Can Follow
Mitratech Preparis keeps continuity plans, dependencies, and ownership in one connected record instead of scattered documents and spreadsheets.
Explore Mitratech PreparisQuestions fréquemment posées
Why does a mapping gap matter if the continuity plan itself still passes review?
How much of this mapping can be automated, versus done by hand?
Isn't identifying vendors already standard practice in continuity programs?
How does this connect to the ownership question CROs and COOs are being asked about now?
What's the fastest way for a BCM manager to test whether their own map has this gap?
What's the one thing you'd tell a BCM manager or CRO to fix first?
Comment Mitratech peut aider
Mitratech Preparis was built to hold the map, not just the plan: the people, processes, facilities, technology, and third parties behind every important business service, tied to the specific entities and countries each one runs through, in a single source of truth kept current instead of rebuilt every time a regulator or a board asks to see it. Explore Mitratech Preparis.
