Two internet connections can make a network diagram look reassuring. I want to know which interruption they actually protect the firm against.
That question changes the conversation. The objective becomes preserving a few important kinds of work through a defined failure: joining a meeting, reaching the document platform, signing in, or contacting someone who can help. The second connection is one possible part of that answer.
Source
What recent resilience work makes clear
Cloudflare’s November 2025 outage account describes a configuration problem spreading through shared infrastructure. Its May 2026 follow-up reports changes to deployment controls, failure handling, emergency access, and incident communication.
The detail that holds my attention is the recovery dependency. Cloudflare explains that disruption to its own access services could obstruct the tools needed to fix an incident. It describes building alternate authorization paths and exercising them. That is a provider’s account of its own engineering work, not a guarantee about future availability.
For a small firm, my takeaway is a question: does the fallback still depend on the thing that failed? I would ask it about connectivity, identity, support access, and the instructions someone needs during an outage.
Proposal
Map where the paths converge
Start at a user’s device and follow the route to one critical application. Two providers may still share a building entrance, power supply, edge device, internal switch, resolver, or application dependency. Some of those relationships require evidence from the provider or building operator; a diagram cannot establish independence by itself.
Describe this figure
A user's device reaches one critical application along a single route, left to right: the internal switch, the edge device, and the building entrance inside the building, then the resolver, then the application. Power is attached to the edge device as a dependency beside the route rather than a step on it. Two providers may still share any of these. The review records each dependency as confirmed independent, confirmed shared, or unresolved; the figure leaves every dependency unmarked, because some of those relationships need evidence from the provider or building operator and a diagram cannot establish independence by itself. Unresolved gives the next conversation a purpose.
I would record each relevant dependency as confirmed independent, confirmed shared, or unresolved. The unresolved category matters. It gives the next conversation a purpose and keeps an assumption from quietly becoming a design fact.
Then map the recovery route. Where are the credentials and instructions? Can the support provider reach the equipment during the selected failure? Is the person who can authorize a change reachable without the office network? Any emergency access needs a defined owner, limited scope, appropriate protection, and a record of use.
Compare a few credible responses
Consider a hypothetical firm that needs document access and calls to continue through a primary-provider outage. Three responses deserve a fair comparison:
- A second fixed connection, where its independence and operating cost can be established.
- A wireless fallback, where coverage, capacity, and application behavior are suitable.
- A process for moving critical work to another location or an approved alternate connection.
The right choice depends on the interruption the firm can tolerate and the burden it can maintain. A backup that requires unfamiliar manual steps may still be useful, but those steps belong in the service commitment. A technically seamless switch may still interrupt an existing call or a session tied to the previous path.
I would compare each option against the same scenarios. A disconnected cable, an upstream failure with the local link still active, and an application outage are different events. A second office connection cannot solve every one of them.
Test the work, then the return to normal
The AWS Well-Architected recovery guidance recommends exercising recovery against defined objectives. My application here is a bounded test with an agreed window, a stop decision, and a known restoration path.
Choose representative tasks before the test. Observe existing sessions and new ones. Capture the network transition, the interruption people experienced, any intervention required, and the result in the application. Agree the acceptable interruption with the business owner beforehand.
Restoring the primary path is part of the exercise. Check that traffic, monitoring, access controls, and the operator’s understanding have returned to the intended state. Otherwise, the test may leave behind the next incident.
The failover test record is how I would keep that evidence compact.
Proposal
The decision I would make next
My starting proposal is a small dependency map and a test of the most consequential plausible interruption. The result should drive the next investment.
If the alternate path works but the application remains unavailable, revisit the shared dependency. If recovery relies on one person, improve the handover. If the fallback introduces more operating complexity than the firm can sustain, compare a simpler continuity process.
Resilience is a claim about particular failures. I want the design to say which ones, and the evidence to show what work survived.