In the first fifteen minutes of the CrowdStrike Falcon outage on 19 July 2024, thousands of BCM and IT teams reached for the same artifact at the same time: a dependency map. Most found a spreadsheet last touched during an audit. By the time anyone opened it under pressure, the answer they needed was buried three tabs deep in a picture that no longer matched reality.
That detail matters. The technology that failed was understood within hours. CrowdStrike reverted the faulty Channel File 291 update in roughly 78 minutes. But recovery required manual, machine-by-machine remediation across 8.5 million crashed Windows endpoints, and it took organisations days to execute it. Airlines grounded fleets. Hospitals reverted to paper. Banks froze mid-transaction. None of them shared a business function. They shared one security agent that nobody had drawn as a common single point of failure, and when it failed, responders spent the critical early window reconstructing the map instead of acting on one. Fortune 500 firms absorbed more than $5 billion in direct losses as a consequence.
The diagnosis worth stating plainly: most cascading failures are a mapping problem wearing a technology costume.
The same pattern, a different incident
The same failure mode runs through Maersk’s 2017 NotPetya recovery. Destructive malware spread through a compromised software update and tore through Maersk’s global estate. Four thousand servers and 45,000 PCs had to be rebuilt over ten days at $250–300 million in direct losses. Recovery hinged on a single offline domain controller in Ghana that happened to survive a dependency nobody had planned around, and nobody’s map had marked as the lifeline it turned out to be. The threat was external. The fragility was structural, hidden inside an incomplete map.
These cases keep repeating because the underlying failure mode is not specific to any one vendor or technology. It is the gap between what an organisation’s dependency documentation says and what its environment actually looks like on the day something breaks.
What a critical dependency actually is
Not every dependency is worth mapping with equal rigour. A general dependency is any relationship between two resources. A critical dependency is one whose failure would prevent a critical business service from operating within an acceptable timeframe. The distinction matters because treating every dependency as equally important buries the ones that will actually cause a cascade. Criticality is always defined against the service and its tolerance for disruption never against the asset in isolation. A database is not critical because it is large or central to the architecture. It is critical because a named service cannot deliver without it, and that service cannot be offline for long without causing real harm.
This framing shifts the question from “what do we have?” to “what can we not afford to lose, and what does it depend on?” That is the question most dependency maps fail to answer, because they were built the other way around starting from assets and working upward, rather than starting from services and working down to the resources that underpin them.
The layers most maps miss
Most programs under-capture the layers where cascades actually travel. Technology gets documented. The people layer almost never does. A critical process that runs because one specialist knows the manual workaround is a single point of failure that no application inventory will show. Fourth-party and nth-party dependencies are similarly invisible: your direct supplier’s supplier may be your real exposure, and you may never have named it. The CrowdStrike cascade was exactly this at scale dozens of unrelated organisations tracing back through different vendors to the same underlying security agent, a concentration nobody had mapped until it failed.
The FCA’s operational resilience rules are explicit that firms must map across people, processes, technology, facilities, and information not just the application estate. Under-capturing any one layer leaves a corridor for failure to travel unseen.
Why dependency maps go stale and siloed
The structural weakness beneath all of this is how dependency data gets owned. In most organisations it sits in fragments one BIA per team, each capturing only the slice of the environment that team operates. Two teams may each name the same critical application as a dependency without either knowing the other does. No one holds the aggregate view, so the concentration risk sitting across both is invisible until the shared node fails and takes both services down together. Each BIA is accurate in isolation and misleading in aggregate. This is not an edge case. It is the default condition of any program that lets dependency data live in siloed documents.
The second failure mode is staleness. Dependencies change faster than documentation cycles can track. A cloud migration reroutes half a firm’s data flows over a weekend. A vendor consolidation creates a new shared single point of failure that nobody signed off on explicitly. The spreadsheet gets updated at the next annual review, if someone remembers. In the interval, responders are working from a picture that has quietly stopped being true. A stale map is worse than no map, because it manufactures confidence in an artifact that no longer reflects reality.
Both failure modes produce the same outcome: organisations enter a disruption without a working map and spend the opening window building one. That is the window where every decision taken against a wrong or incomplete picture makes recovery harder, not easier.
What AI dependency mapping actually solves
The fix is not a better method for mapping on the day of an incident. It is keeping the map current before one arrives. ISO 22301:2019 treats dependency identification as a continuous requirement, not a project that closes when the BIA is filed. DORA Article 28 frames ICT third-party risk as an ongoing, integral part of the risk framework a living model, not a point-in-time document. Both standards are pointing at the same operational reality: a dependency map only does its job if it reflects the environment as it is right now.
What makes that hard at scale is the aggregation problem. Connecting dependency data across dozens of BIAs into one traceable view, surfacing shared nodes no single owner could see, and keeping the model current as systems and vendors change this is where human effort breaks down under the weight of a large, moving environment. Most programs do not have a stale map because they lack the methodology. They have a stale map because keeping it current manually is more work than the team can sustain between audit cycles.
This is the problem AI dependency mapping is built for. It uses automation and machine learning to connect and maintain the relationships between business services, processes, applications, vendors, people, and data replacing the point-in-time snapshot with a continuously updated model. It surfaces implicit dependencies that manual documentation routinely misses, aggregates data across fragmented BIAs into a single connected view, and flags concentration risks that no individual BIA owner could see from their own slice. The analyst still owns the judgment calls about criticality. AI dependency mapping handles the continuous aggregation they would otherwise do by hand, once a year, under time pressure.
The economics support the shift. IBM’s 2025 analysis found that organisations using automation extensively saved nearly $1.9 million per breach on average compared with those without a gap that comes largely from faster identification and containment, which is exactly what a current map enables. The goal is not a better spreadsheet. It is the map that was ready when teams reached for it on 19 July 2024 and wasn’t.
Fortiv’s AI dependency mapping capability is built around this specific problem: connecting the dependency data that sits in fragmented BIAs into a single visualised model, keeping it current as the environment changes, and surfacing concentration risks before an incident forces them into view.
What this means for your program
If your dependency data lives in separate BIA documents with no connected view across them, you have the fragmentation problem. If your maps are reviewed annually or tied to audit cycles rather than to infrastructure change, you have the staleness problem. If your maps stop at direct suppliers without tracing upstream, you have the under-capture problem. Most programs have all three.
The starting point is not a new tool. It is an honest assessment of whether your current map would have been usable in the first fifteen minutes of a CrowdStrike-scale event and if not, what specifically would have been missing. That answer tells you where AI dependency mapping can close the gap.
