Ask a leadership team about resilience and the conversation usually turns to cyber incidents within a minute. That is a real risk and it is not the most likely one. The disruptions that actually interrupt operations are more mundane: a vendor changes their terms, a platform has an extended outage, a key person leaves, an integration silently stops working.
None of those are security events. All of them stop work. Resilience planning that only covers incidents leaves the more probable failures unaddressed.
The question is not what might attack you. It is what you would struggle to operate without.
Four Kinds of Dependency
Dependencies accumulate without being decided. Each one was reasonable when it was added. The exposure comes from the total, which nobody has looked at.
- PlatformsSystems that daily work runs through. Usually well understood for the obvious ones and poorly understood for the small tool that quietly became load-bearing.
- VendorsThird parties whose availability, pricing, or terms you do not control. Includes the ones you pay and the free ones nobody tracks.
- PeopleIndividuals who hold knowledge or access nobody else has. The most common single point of failure and the least likely to appear in a plan.
- KnowledgeProcesses that exist only as practice. If the person who runs it is unavailable, nobody can reconstruct how it works.
Finding Them
You do not need a formal business impact analysis to get a usable picture. You need one question asked of the right people.
Ask each team: if you arrived tomorrow and one system was unavailable, which one would stop you working? Then ask what they would do instead, and how long that would hold.
The answers are usually specific and immediate, because the people doing the work already know. What is missing is not the information but the exercise of collecting it in one place, where the pattern becomes visible.
The dependency nobody flagged is rarely the major platform. It is a small tool adopted by one team that other processes quietly grew to rely on, or a spreadsheet that became the authoritative record of something without anyone deciding it should be.
Deciding What Is Acceptable
Not every dependency needs mitigation. The work is deciding which ones you accept, deliberately.
An hour, a day, a week. The answer differs by function and it changes the response. A dependency the organization can absorb for a week needs a documented workaround, not a redundant system.
Most fallback plans have never been executed. A procedure that exists on paper and has never been run is an assumption, not a plan. Testing one during a quiet week is inexpensive and reliably surprising.
If the answer is one person, that is a resilience finding regardless of how the system is architected. Documentation and cross-training are cheaper than any technical redundancy.
You are not planning to. You are establishing whether you could, and at what cost. A dependency you cannot exit is a commercial position as much as an operational one, and it is worth knowing before a renewal conversation rather than during it.
Silent failures are the expensive category. An integration that stops running without alerting anyone can go unnoticed for weeks, and the recovery work scales with how long it went undetected.
Turning It Into Something Usable
The output should be short enough that leadership reads it. A list of the dependencies that would stop work, how long each is tolerable, what the fallback is, and who owns it. One page is usually enough.
What makes it useful is that it gets revisited. Dependencies change every time you adopt a tool, change a vendor, or lose a person. A document produced once and filed describes an organization that no longer exists.
Ask each team the single question above, collect the answers in one place, and look for the dependency that appears more than once. That overlap is where your exposure concentrates, and it is usually not the system you expected.