THE RISKS YOU DIDN’T KNOW YOU HAD
WHY HIDDEN DEPENDENCIES ARE THE REAL BUSINESS CONTINUITY THREAT
Most organizations know what their biggest risks are. They've identified the obvious ones, such as a cyberattack, a data centre outage, or a major storm, and they've written plans for those scenarios.
What tends to blindside them is something much quieter.
A transit strike that stops staff from getting to the office. An underground transformer explosion that disrupts telecommunications circuits nobody realized were shared. Two internet providers that turn out to be running on the same last-mile cable. A critical process that is entirely dependent on one vendor nobody thought to verify.
Scott Wilson has spent more than 30 years working through exactly these situations. As the head of 2Oaks Consulting's Business Resiliency practice, he's helped financial institutions and public services organizations find the exposures that don't show up on the obvious risk register until it's too late.
TLDR; Key Takeaways
The disruptions that cause the most damage are often the ones that weren't on anyone's radar.
Most organizations look too narrowly at their risk scope, focusing on internal systems while underestimating external and environmental factors.
Hidden dependencies in vendor and telecommunications infrastructure are among the most common sources of unexpected failure.
The difference between a manageable incident and a serious crisis often comes down to how well dependencies were understood and documented in advance.
Genuinely redundant systems require verification, not assumption.
The Disruptions That Don't Make Headlines
Ask most people to name a business continuity threat and they'll reach for the dramatic: ransomware, floods, server failures. Those risks are real, and they deserve serious planning.
But in Scott's experience, the disruptions that quietly cause the most damage are often far more mundane. A 2026 analysis found that 100% of 1,000 senior technology executives surveyed reported their companies lost revenue due to IT outages in the previous year, and most experienced multiple incidents.
The majority of disruptions such as these are not exceptional events. They are routine features of modern operations, and organizations that plan only for the dramatic ones are consistently underprepared for the ones that actually happen.
"Short-term issues that happen are things that aren't planned for," Scott explains. "Something that happens out in the street, and not being fully prepared to account for that as a situation. A lot of the times you don't see those sorts of things, and it's not part of your scope of risk. You're looking too narrowly at your scope."
He points to examples that many Canadian organizations would recognize: a regional transit strike that leaves staff unable to get into the office. A G8 Summit security zone that unexpectedly restricts access for workers on temporary visas. An event that was planned well in advance but still surfaced problems nobody anticipated.
"After 30 years in this field, you get to see all the 'gotcha' situations," Scott says. "The ones where everything looked covered until it wasn't. You didn't plan for this, and guess what? It gotcha."
The Last-Mile Problem: When Redundancy Isn't Real
One of the most instructive examples of hidden dependency risk involves something that sounds straightforward: having two internet providers for redundancy.
A financial services organization learned a hard lesson that illustrates this dynamic precisely. They had two providers, believed they had genuine redundancy, and tested accordingly. What they hadn't verified was that both circuits, despite being sold by different providers, were running on the same physical last-mile cable.
"The last mile of cable is actually a major telecommunications provider, and this national telco rents out their cable to your primary provider," as the situation was described. "When they get hit, both lines go down, secondary and primary at the same time." In one case, a train derailment hit the shared internet infrastructure and an organization was completely down, with what they believed were two independent circuits both going dark simultaneously.
Scott sees this pattern regularly. "You have people that come in and say, do you have redundant lines? Yeah, I use this company for this circuit and another company for this circuit. But they don’t realize the last mile is the same." He calls these nuanced gotchas: "They need to be focused on and identified, which is done by diving that little bit deeper and getting a certificate from your telecommunications provider saying that this circuit and that circuit are not on the same piece of wire."
This is the kind of dependency that requires active verification, not assumption. It's also the kind of work that fits naturally within 2Oaks' Business Operations Excellence practice, which helps organizations map operational dependencies systematically rather than relying on assumptions that may not have been revisited since the infrastructure was set up.
The broader version of this problem is oversubscription. In a localized but wider disaster, multiple customers might simultaneously try to access the same backup infrastructure. A system designed to handle ten simultaneous users is suddenly being called upon by thirty. It fails not from damage, but from demand.
Is your "redundant" infrastructure actually independent? Does anyone in your organization know the answer with certainty? If not, it's worth finding out before the question gets answered for you. Talk to 2Oaks about how a dependency audit fits into your continuity planning.
The Scope Problem: How Far Does Your Risk Reach?
Many organizations define their risk scope by what they directly control: their own systems, their own premises, their own staff. That made more sense when businesses were more self-contained.
Modern financial services organizations operate within a web of third-party relationships. Cloud platforms, managed service providers, specialized vendors, and outsourced functions. The reach of a disruption doesn't respect the boundaries of your org chart. The 2Oaks article on the hidden risks of ancillary systems in core banking transformation examines exactly this dynamic in the context of banking technology: the supporting systems that keep the lights on are often the ones that receive the least continuity attention.
Scott describes the scope problem directly: "What happens when staff can't get into the office? What happens 10 miles out?" External events like a strike, a political summit, or an infrastructure failure in the surrounding area can have direct impacts on an organization's ability to function, and they often don't appear on risk registers that focus narrowly on internal assets.
The organizations that handle disruption well have extended their risk thinking beyond their own walls. They've mapped not just what they depend on, but what those dependencies depend on. They've asked the uncomfortable questions about concentration risk: what happens if this vendor is affected by the same regional event that's affecting us?
What Good Dependency Mapping Looks Like
Surfacing hidden dependencies is a practical process of asking specific questions about how the organization actually operates.
Who are the vendors this organization cannot function without, even temporarily? What are those vendors' own dependencies? Is there a single person who holds critical knowledge about a system, a process, or a relationship? If that person were unavailable tomorrow, what would happen?
Are systems documented as "redundant" genuinely independent at every layer, including physical infrastructure? Has anyone verified this recently, or does the assumption persist from when it was first set up?
Are backup systems sized for normal conditions or for the conditions under which they'd actually be needed, when multiple users and organizations might be drawing on them simultaneously?
Good dependency mapping often surfaces issues that have been sitting quietly for years. The 2Oaks article on AI readiness assessment draws a parallel that applies directly here: organizations frequently discover gaps only after committing to an initiative that depends on capabilities they assumed they had. The same principle holds in continuity planning. The honest assessment, done before an incident, is always cheaper than the discovery made during one.
These questions don't require dramatic scenarios to be worth answering. The value is in the honest picture they produce. That picture is the foundation of a continuity program that performs when it needs to. The 2Oaks Technology Operations and Continuity Planning practice helps organizations build that picture systematically, with the verification depth that assumptions-based planning consistently misses.
Reach out to the 2Oaks Business Resiliency team to discuss what a dependency review looks like for your organization.
Scott Wilson leads the Business Resiliency practice at 2Oaks Consulting. He brings more than 30 years of experience identifying and resolving the operational exposures that don't show up until something goes wrong. To discuss what you might not know about your organization's dependencies, reach out here.
About Scott
Scott Wilson leads the Business Resiliency practice at 2Oaks Consulting. He brings more than 30 years of experience in business continuity and disaster recovery across financial services, insurance, and public services organizations. To discuss your organization's continuity program, reach out.