Which network dependencies affect critical business services?

Network dependencies are the technical components, services and external connections that a critical business service requires in order to operate. They include obvious connections, such as access to a hosted application, and less visible prerequisites, such as name resolution, authentication, accurate time, routing, power and third-party connectivity. Understanding these relationships helps an organisation assess the effect of failure and select proportionate resilience and recovery measures.

A useful dependency assessment considers more than whether a device is connected. It should identify what each business service needs to function, what users need to access it, and what administrators need to restore it. Dependencies commonly fall into the following groups:

• Access dependencies: user devices, wireless coverage, switching, routing and remote connectivity can determine whether staff can reach an application or shared resource.
• Core network services: address allocation, name resolution, authentication and time synchronisation support the operation of many other systems. A failure in one of these services can appear to users as an application fault.
• Security dependencies: firewalls, filtering, authentication controls and inspection services may be required for both access and protection. A control that blocks malicious traffic can also prevent legitimate traffic if it fails incorrectly or is misconfigured.
• External dependencies: internet providers, hosted platforms, software suppliers, payment services, customer portals and business partners may sit outside the organisation’s direct control.
• Infrastructure dependencies: power supplies, cooling, physical cabling, equipment rooms and supporting hardware can affect network availability even when software is operating normally.
• Operational dependencies: configuration backups, monitoring, administrative access, support credentials and documented recovery procedures are essential when a failed component needs to be investigated or replaced.

The most important distinction is between a direct dependency and a hidden dependency. A direct dependency is easy to see: an online order system requires a connection to its hosting environment. A hidden dependency may be less obvious: the same system could rely on internal name resolution, an identity provider, a certificate validation service or a specific route through a security appliance. If any of those prerequisites is unavailable, the application may be inaccessible even though its own servers are healthy.

Dependencies can also be shared. Several critical services may use the same network cabinet, uplink, authentication service, internet circuit, virtual host or cloud control plane. These shared elements create a concentration of risk. Treating each service as independent can therefore give a misleading view of resilience, because one failure may affect multiple functions at once.

A practical dependency review starts with the business service rather than the network equipment. For each service, document:

• the business activity it supports and the users, sites or devices that require it;
• the systems, connections and supporting services it depends on;
• which dependencies are internal, hosted, supplier-managed or shared;
• the effect of losing each dependency, including degraded operation and complete unavailability;
• the order in which components must be restored; and
• the person or supplier responsible for investigating and recovering each component.

This information is often represented as a service dependency map. The map should show relationships rather than simply list assets. For example, it may trace a transaction from a user’s device through local connectivity, security controls, external routing, application hosting and a payment provider. A separate view can show management dependencies, such as the systems needed to administer the network or retrieve configuration backups during an incident.

Risk should be assessed according to business impact, not just equipment value. A small network component may be more significant than a high-specification server if its failure prevents access to several essential services. Consider the consequences of losing confidentiality, integrity or availability, as well as the effect of partial failure. A network that remains connected but suffers severe latency, packet loss or intermittent authentication may disrupt operations without appearing completely offline.

Controls should then address the specific dependency. Examples include separate connectivity paths, resilient power, spare equipment, alternative name-resolution arrangements, replicated authentication services, documented firewall changes, tested configuration backups and supplier escalation routes. Redundancy is useful only when the alternative does not rely on the same physical path, power source, configuration error or external provider. It should also be monitored so that a failed primary component does not remain unnoticed until the backup is needed.

Cloud and hosted services require particular care. The organisation may not manage the provider’s network, but it remains responsible for understanding its own access path, identity arrangements, domain configuration, data flows and supplier commitments. A hosted service may be available while users are unable to reach it because of a local routing problem, an expired certificate, a failed identity integration or a disrupted internet connection. Supplier documentation should therefore be considered alongside internal network records.

Dependencies change when applications, sites, providers or security controls change. A review should form part of change management and should be repeated after network redesigns, acquisitions, office moves, cloud migrations and major application upgrades. Monitoring should reflect the service map, checking not only whether individual devices respond but whether important user journeys and supporting services work together.

For organisations without a complete internal IT function, an external IT support partner can help translate business processes into dependency maps, review shared points of failure and maintain accurate technical documentation. The objective is not to remove every dependency, which is rarely practical, but to make important dependencies visible, reduce avoidable concentration risk and ensure that recovery decisions are based on how the organisation actually operates.