Planning robust site connections: dependencies, fallback and handover
A practical guide to site connections: make dependencies visible, assess fallback paths and hand over operations in a traceable way.
A second line is not yet a fallback path
With several sites, “redundant connection” initially sounds unambiguous. In practice, more than the line itself can fail: power, endpoints, routers, routing, name resolution, identities, providers, building cabling or the responsible person. Two connections using the same route, provider or network termination are therefore not automatically independent.
The key question is not only “Is there a second connection?” It is: Which function should continue, in what restricted form, during which failure – and who can restore it in a traceable way?
1. Define the function and failure scenario first
Before selecting technology, create a small operating picture for each site function:
| Planning question | Concrete result |
|---|---|
| Which function connects the sites? | For example file access, telephony, identity services or production data – not merely “the LAN”. |
| Which users or processes are affected? | Affected roles, applications and time-critical activities |
| How much interruption is tolerable? | Agreed priority and acceptable degraded operation; no blanket availability figure |
| What may be dropped during an incident? | Non-essential services, bandwidth or convenience functions |
| How is the failure detected? | Measurement point, alert, check and responsible role |
The BSI business impact analysis guidance lists staff, information, information and communications technology, and services among the resources to consider for critical processes. It also identifies single points of failure whose loss can completely interrupt a process or essential function. This is a planning basis, not proof that a particular architecture is resilient.
2. Trace dependencies all the way to the service
A site is not reachable only through a WAN line. For a prioritised function, the dependency chain should include at least these layers:
- Access: line route, wireless or point-to-point radio link, network termination and power.
- Transport: router, firewall, tunnel, routing protocol and addressing.
- Name and identity services: DNS, time source, directory service and required authentication.
- Application: server, storage, database or external service.
- Operations: monitoring, credentials, spare parts, provider contact and escalation path.
Document the purpose, owner, common failure domains, detection, fallback and recovery for every element. “Unknown” is a valid finding. An unverified assumption must not be treated as independence or promised recoverability in the decision.
3. Compare independence, not just quantity
NIST SP 800-34 Rev. 1 recommends avoiding common single points of failure for alternate telecommunications services and considering primary and alternative providers or paths so that they are not exposed to the same hazards. This leads to the following site-comparison table:
| Check area | Planning question | Warning sign |
|---|---|---|
| Physical route | Do both connections share the building entry, route or network termination? | “Two contracts” without route evidence |
| Provider and upstream service | Do both connections use the same operator or last mile? | A common outage remains possible |
| Power and room | Do active components share power or a technical room? | No defined local emergency operation |
| Active technology | Is there a shared firewall, power supply or configuration? | The alternate path cannot terminate |
| Control plane | Are routing, DNS, identity and monitoring also dependent? | The line is available but the service is unreachable |
| Operations | Who switches over, checks the function and escalates? | Fallback depends on individual knowledge |
A more expensive or technically complex option is not automatically better. The relevant question is which common failure domain it actually reduces and whether the added operational effort remains manageable.
Contractual jurisdiction and vendor lock-in are dependencies too
For managed lines, SD-WAN, security gateways or cloud nodes, the decision should not stop at the number of connections. Clarify contracting parties and subcontractors, the locations of operations, administration, support and log processing, and applicable statutory, contractual and customer-specific requirements. The location of a network connection or data centre alone does not determine legal jurisdiction; the relevant jurisdiction must be assessed separately for the project.
It is equally important to ask how tightly the sites are tied to a vendor and what the trust in that vendor is based on: How transparent are security updates, incident reports, support and product lifecycle? Does the fallback path require the same central platform, licence, identity management or proprietary configuration as the primary path? Can routes, rules, keys and operational documentation be exported and restored with another operator? What contractual, migration and parallel-operation costs would a change create? Deliberate close integration is possible if the common failure domain, responsible party and practical exit path are documented and tested.
These questions complement technical failure analysis; they do not replace legal or contractual review. For cloud services, BSI recommends clarifying service-provider requirements and an exit before committing. For managed site connections this is a transferable planning principle, not a blanket legal requirement.
4. Describe the fallback path as a limited service
A fallback path should be described as a procedure, not as a property on a network diagram. For every prioritised service, the decision should cover at least:
- Trigger: Which observed event starts the switchover? Which false alarms are possible?
- Decision: Is the switchover automatic, manual or subject to approval?
- Remaining function: Which applications and users remain reachable, and with what limitation?
- Security boundary: Which data flows remain allowed and which are deliberately blocked?
- Return: How is the primary path restored after the incident?
- Evidence: Which test shows that the function really works in fallback mode?
“The internet is still reachable” is not sufficient evidence of function. Fallback can fail at DNS, identity, MTU, firewall rules, routes or the application itself. Test switchover and return with the real prioritised functions, not only with a ping.
5. Plan the operational handover before commissioning
A connection is operable only when another person can assess its state and handle an incident. For recovery, NIST lists current physical and logical telecommunications diagrams, configuration and provider information, and contacts and contract information as useful documentation.
The handover should produce a compact, versioned set of documents:
| Handover artefact | Minimum content |
|---|---|
| Architecture and route overview | Sites, endpoints, logical paths and common failure domains |
| Dependency list | Service, prerequisite, owner, test method and fallback |
| Operating procedure | Normal operation, switchover, return, escalation and security boundaries |
| Access and responsibility | Managed access, secret handover outside the document, roles and provider contacts |
| Test record | Date, scenario, expected result, actual result and open deviations |
| Change log | What changed, why, by whom and when it must be checked again |
Handover is not complete when a configuration file has been delivered. It is complete when operations and accountable decision-makers know the fallback limits, open risks and next review date.
A small decision matrix
A simple assessment can be enough for each option. Weights must fit the process; the matrix does not replace risk analysis.
| Criterion | Yes/no or short rationale |
|---|---|
| Does the option reduce a specifically named common failure domain? | Name the route, provider, power, device or operation |
| Does at least the prioritised remaining function remain testable? | Record the service test and limitation |
| Can switchover and return be tested at reasonable effort? | Test window, owners and abort criterion |
| Is the fallback security boundary documented? | Allowed and blocked flows |
| Can operations act without individual knowledge? | Documentation, access and escalation available |
| Is the decision reversible or deliberately justified? | Rollback, follow-on costs and open assumptions |
If an option has no answer, that is a clarification point, not a reason to claim robustness. In smaller environments, a deliberately limited manual fallback may be more useful than complex automation if the procedure can be documented and practised.
Boundaries of this contribution
This contribution contains no concrete network design, provider recommendation, security or availability guarantee, regulatory assessment or promise of a particular recovery target. It does not describe customer experience. Terms such as “robust” and “redundant” are used only with a named failure scenario and a testable operating procedure.
For a specific project, consulting and project planning and networks, routing and radio may be suitable starting points. An enquiry should state the affected function, available documentation, known dependencies and desired operating limits; this does not constitute a promise of service or response time.
The project profile on more resilient connectivity in a hospital environment and the profile on segmented connectivity for a care facility provide bounded, anonymised practical context. They do not replace an assessment of a specific site.
Sources
The technical statements draw on these primary sources (accessed 25–26 September 2026):
- NIST, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems, especially CP-8 and guidance on telecommunications documentation and recovery, DOI
10.6028/NIST.SP.800-34r1, NIST - German Federal Office for Information Security (BSI), 3.7 Determine resources, their criticality and recovery parameters, BSI
- German Federal Office for Information Security / UP KRITIS, Recommendations for preparing an exit strategy when using cloud services, BSI
The sources support general planning and documentation guidance. They do not establish specific company services or a particular result for a project.