Insights · Field note · Infrastructure and resilience
Infrastructure dependencies you did not know you had
The service fails because of something three steps removed that nobody drew on the diagram. Dependency mapping finds it before the outage does.
Hidden infrastructure dependencies are the components a service relies on that nobody documented: the DNS server everything resolves through, the license server an application checks on start, the certificate that expires on a Sunday, the single internet circuit behind the redundant firewalls, the person who alone knows the password, the vendor API a critical process calls. They surface during outages and recovery tests as the reason the plan did not work. Dependency mapping finds them deliberately: observed traffic, startup sequences, recovery rehearsals and interviews with the people who operate the systems, recorded in a map that recovery order and continuity planning then use.
In detail
What the evidence shows.
Where they hide
Shared services: DNS, time, directory, certificates, licensing. Network paths: the one circuit, the one switch, the one cross-connect. People: the sole administrator, the vendor contact. External services: payment, messaging, identity, cloud control planes. Each is invisible until it fails.
How to find them
Observe traffic between systems over a representative period. Trace the startup sequence of each critical application. Rehearse recovery and note what the restored system needed that was not in the plan. Interview operators: what do you check first when this breaks. Review certificates, licenses and contracts for expiry.
What the map changes
Recovery order, because dependencies must come back first. Continuity workarounds, because some dependencies have none. The single-points-of-failure list for the board. Segmentation design, because dependencies cross zones. Vendor oversight, because an external dependency is a vendor risk.
Keeping it current
The map is maintained through change control and refreshed by each recovery test. See asset and configuration review, disaster recovery planning and key-person and vendor dependency review.
By David Selakovic · Published 2026-10-16 · Revised 2026-10-16 · Reviewed every 180 days