Business continuity is often discussed in terms of backups, cybersecurity, disaster recovery and resilience planning.
Those are essential, but some of the most disruptive technology risks inside an organisation are less obvious.
They are the dependencies that accumulate quietly over time:
· an administrator account known only to one person
· a legacy server nobody wants to touch
· a cloud service configured by a former supplier
· a spreadsheet or script that has become part of a critical workflow,
· several vendors each responsible for one piece of an environment that no one fully understands end to end.
These arrangements can operate successfully for years. That is what makes them dangerous.
A hidden dependency rarely announces itself while everything is working.
It becomes visible when something changes.
The risk is often knowledge, not technology
Many organisations assume that if a system is documented, backed up and supported, it is under control.
In practice, operational knowledge is often distributed unevenly.
One employee may know why a particular service account must never be changed.
A former contractor may have created the only recovery account for a cloud platform.
An external provider may manage the network, while another manages Microsoft 365, and neither has visibility of how a line-of-business application depends on both.
The underlying technology may be perfectly sound.
The weakness is that the organisation does not clearly understand who controls it, what depends on it or what would happen if a key person or supplier became unavailable.
This is a business continuity problem because recovery depends on more than restoring data.
It depends on knowing how the environment fits together.
Workarounds can become permanent architecture
Temporary fixes are another common source of hidden dependency.
A manual process may be introduced to keep a business operating during an outage.
A scheduled task may be created to compensate for an application limitation.
A second internet connection may be configured in an unusual way after a previous failure.
None of these decisions is necessarily poor.
The problem begins when the temporary solution becomes permanent but the reasoning behind it is never captured.
Years later, someone removes what appears to be redundant equipment, changes an account, replaces a server or migrates a service, only to discover that an undocumented process depended on it.
The lesson is not that organisations should avoid workarounds.
It is that every workaround that becomes operationally important should eventually be treated as part of the production environment and documented accordingly.
Multi-vendor environments create gaps between responsibilities
Modern organisations frequently use multiple technology providers, and that can be entirely appropriate.
Specialisation is often valuable.
The risk appears at the boundaries.
A networking provider may confirm that connectivity is working. A software vendor may confirm that its application is healthy. A cloud provider may show no service fault.
Yet the business can still experience a recurring problem because the issue exists in the interaction between those systems.
When responsibilities are divided too narrowly, each supplier can be correct within its own scope while the organisation as a whole remains exposed.
This is where recurring incidents deserve more attention.
If the same problem continues to return despite individual components repeatedly being declared healthy, the organisation may need someone to examine the relationships between systems rather than another isolated support ticket.
Finding hidden dependencies before a failure
The most useful time to discover these weaknesses is before a migration, outage, staff departure or supplier change forces the issue.
A practical review should establish:
· who controls critical administrator accounts
· where recovery methods are held
· which systems depend on one another
· which services rely on individual knowledge
· what legacy infrastructure still performs an important function
· whether another competent person or provider could take over without first reverse-engineering the environment.
This does not require documenting every technical detail.
The objective is to identify the dependencies whose failure or loss of knowledge could materially disrupt the business.
The process also needs to be repeated.
Technology environments change continuously. Documentation that was accurate two years ago may now describe a system that no longer exists.
Business continuity starts with understanding
Resilience is not only about having backups or redundant infrastructure.
It is also about reducing uncertainty.
An organisation is in a stronger position when it knows what it depends on, who controls those dependencies and how they can be recovered or transferred when circumstances change.
The most dangerous IT dependency is often not an ageing server or an old application.
It is the one nobody realised was critical until it stopped working.
