A second internet connection can help maintain access when a primary circuit fails, but it does not guarantee resilience. The two services may share a physical route, local access provider, building entry, power source or upstream dependency. A resilient design starts by identifying which services must continue, what can fail and what the organisation expects to happen during and after an outage.
Define the service and recovery requirement
List the applications, sites and users that depend on the connection. Decide which functions must remain available, which can operate in a degraded mode and which can wait for restoration. The requirement should reflect business impact rather than a generic preference for “high availability”.
Set out the acceptable interruption and recovery approach for each important service. Confirm how users will work if the primary connection is unavailable, what data or transactions may be affected and who can authorise a change to the normal operating mode.
Identify common failure points
Draw the path from the site to critical services. Include power, customer equipment, the building entry, access circuit, carrier hand-off, routing, security devices, DNS, identity services and cloud dependencies. Mark which components are shared by primary and backup arrangements.
A diverse carrier name does not prove a diverse physical route. Ask providers what path diversity they can confirm and where information is unavailable. Consider local risks such as construction, site power, shared equipment, environmental exposure or a single point of configuration.
NIST’s contingency-planning guidance for federal information systems discusses redundant communications links and network-connecting devices as possible contingency strategies.^1 It is guidance for a federal context, not a universal requirement or a guarantee that a particular design will meet an organisation’s needs.
Design the failover behaviour
Decide whether the secondary service is active, standby or manually enabled. Define what triggers failover, how routes or sessions change, what alerts are generated and who responds. Check the effect on firewall policy, network address translation, public addressing, VPN or secure-access paths, voice services and applications.
Some sessions may not continue when a path changes. Confirm the expected user experience and whether applications reconnect automatically. A failover that keeps a circuit technically up but leaves an essential service unreachable is not a successful recovery for that service.
Keep recovery procedures operable
Document the decision points, contact paths, approved actions and rollback process. State who can declare an outage, who contacts the carrier, who communicates with staff and who decides when to return to the normal path. Keep diagrams and configuration records current enough to support the people who will act.
Consider whether critical operations can continue if a network provider, support partner or cloud service is unavailable. Where a third party is part of the recovery plan, record the access arrangements and a fallback contact. Avoid depending on one person who holds undocumented knowledge.
Test the path, not just the contract
A backup link should be exercised under controlled conditions. Check that it activates as intended, that the expected systems are reachable, that security controls remain in place and that monitoring identifies the change. Record timing, errors, user impact and the recovery steps required.
Testing may be staged to reduce operational risk. Start with a maintenance window and a defined scope, then test more complex failover scenarios when the team and business owner agree. A test should have an approval, a rollback plan and a clear record of results.
Re-test after a carrier change, network redesign, firewall policy change, site move or major cloud dependency change. Review whether the secondary path remains available and whether the documented contacts still work.
Consider dependencies beyond connectivity
A resilient circuit does not resolve an outage in identity, DNS, cloud hosting, application services or power. Map the dependencies that must work for users to complete a task. Decide which providers should be contacted and what information they need during a coordinated incident.
Network resilience also includes monitoring and capacity planning. Alert on conditions that threaten the agreed service, review recurring faults and decide whether new business demand changes the design requirement.
Make resilience an owned operating practice
A second link can be one useful component of a resilience plan, but the organisation should verify path diversity, failover behaviour, security policy, recovery procedures and support ownership. Define what must continue, test it safely and update the plan when dependencies change.
Read how network performance affects security operations and how to assess carrier fit by location. For AltTab’s current network resilience and connectivity planning scope, see Networking and connectivity.