Mapping Data Centres and Networks

Mapping data centres and networks records where a service physically runs, how its locations connect, and what happens if a site or a network path becomes unavailable. A service may appear to live in a cloud or an application, but it ultimately runs on physical infrastructure in particular places, connected by networks that can fail, congest, or be cut. The map should show, for each important service, which sites and network paths it depends on, which alternative site or path exists, and how the service moves between them. Without that picture, a site incident can become a service incident before anyone realises the connection.

For each service, the map should show the sites that host its systems and data, including any site that holds a copy for recovery. It should distinguish a site that actively runs the service from a site that is ready to take over, and it should note what is needed for that takeover to succeed, such as replicated data, available capacity, and staff or supplier access. A site that is labelled as a recovery site but cannot actually run the service, because its data is incomplete or its access is untested, is a dangerous entry on a map. The site layer should therefore record readiness, not merely location.

The network layer should show the paths that connect users to the service, systems to each other, and sites to each other, in the order that traffic actually travels. It should note where a path is the only route between two points, where an alternative path exists, and what depends on each path. Network dependencies are easily overlooked because they are invisible in normal operation, yet a single network failure can isolate a site, break an integration, or cut off a supplier. The map should make those connections explicit, so that a network incident is recognised as a service incident from the start, rather than investigated as an isolated technical fault.

Sites and networks must be mapped together, because a recovery that moves a service to another site fails if the network to that site is also affected, and a network workaround fails if the site it reaches cannot run the service. The map should therefore show, for each service, the combination of site and network that constitutes a working route, and the alternative combination that would be used if the first fails. That combined view prevents a common rehearsal failure: a team demonstrates that a recovery site exists and that an alternative network path exists, but never demonstrates that the two work together for the actual service under load.

Data centres and networks are often shared across many services, which means a single site or network failure can affect a whole portfolio at once. The map should make that sharing visible by showing, for each site and each critical network path, which important services depend on it. That view supports prioritisation during a widespread incident, when not every service can be recovered at once and choices must be made about order. It also supports planning, because a firm that can see its concentration on one site or one network provider can decide whether that concentration is acceptable or whether diversification is warranted.

Test by removing a site or a network path in rehearsal and asking the team to demonstrate the alternative route for the service, including data readiness and customer impact. The demonstration should use the map alone, without relying on the memory of the person who designed the infrastructure. If the alternative route works, the map is validated. If it stalls on data, access, or capacity, the map has exposed a gap that should be owned and fixed. Under DORA in the EU and under FCA and PRA policy in the UK, the physical and network underpinnings of a service are part of its resilience picture, labelled separately in these guides, and a tested alternative route is the evidence that matters.