July 12, 2026
A second internet connection is not automatically a resilient design. Effective redundancy depends on what must keep working, how traffic moves during an outage, whether the paths share hidden dependencies, and who verifies the design over time.
Use this worksheet before discussing circuits or providers. It turns “we need backup internet” into testable business and technical requirements.
Concise answer: Business internet redundancy requires more than two circuits. Define the applications that must continue, acceptable degraded performance, path and provider diversity, failover behavior, security controls, monitoring, testing, and operational ownership for each location.
Start with the business impact of an outage
The first question is not “Which backup connection should we buy?” It is “What must the business still be able to do?”
For each location, document:
- revenue-generating or customer-facing activity that depends on connectivity;
- cloud applications, voice, contact-center, payment, identity, and remote-access dependencies;
- safety, physical access, building, or operational systems that use the network;
- the effect of a partial outage compared with a complete outage;
- the number and type of users who require continuity; and
- the maximum tolerable period of disruption, as determined by the responsible business and risk owners.
This is a business impact discussion, not a service-level promise. The result should identify priorities that the network design can address and questions that require further validation.
Define normal, degraded, and unavailable states
“Failover worked” can mean very different things. A useful requirement describes the expected user experience in three states:
- Normal: Primary connectivity is available and traffic follows the intended design.
- Degraded: A dependency is impaired, but defined priority services remain usable within agreed internal tolerances.
- Unavailable: The required service cannot be delivered; escalation and continuity procedures begin.
For each critical application, record whether it must remain available, can operate with reduced performance, or can wait for restoration. Voice, video, contact-center, transactional, and cloud applications may respond differently to a path change.
Map the failure domains—not just the provider names
Two services can still share infrastructure. Diversity questions may include:
- Are the last-mile paths physically separate where separation is required?
- Do both services enter the building through the same conduit, riser, or equipment room?
- Do they depend on the same local power, firewall, router, edge device, or configuration?
- Are upstream network dependencies distinct where that matters to the design?
- Are both circuits vulnerable to the same construction, landlord, or access constraint?
- Does a wireless path depend on signal, local congestion, antenna placement, power, or another site-specific condition?
- Are DNS, identity, security, or cloud gateway services a shared dependency?
The appropriate evidence depends on the location, architecture, and approved supplier documentation. Do not infer physical or upstream diversity from different brand names alone.
Meaningful path diversity requires evidence across the last mile, building entrance, local equipment, power, upstream dependencies, and shared cloud or security services. Different provider names alone do not prove independent failure paths.
Specify failover behavior
Document how the network should detect a problem, move traffic, and return to the normal path.
Failover requirements checklist
- Define which condition triggers failover: loss of link, loss of reachability, application degradation, or another validated signal.
- Identify which traffic classes move to the alternate path.
- Prioritize critical traffic when the alternate path has different capacity or characteristics.
- Define session behavior for voice, video, VPN, cloud, and transactional applications.
- Confirm how public IP dependencies, allowlists, DNS, and inbound services are handled.
- Preserve required security inspection, access policies, logging, and segmentation during the alternate state.
- Define whether failback is automatic, manual, or controlled by a change process.
- Identify the owner authorized to change or override routing behavior.
- Document what users and support teams should expect during an event.
Automatic failover is not inherently better than controlled failover. The right behavior depends on the applications, architecture, operating model, and risk.
Keep security controls in the alternate path
An emergency path should not become an unmanaged path. Confirm whether the backup state maintains:
- firewall and traffic-inspection policies;
- identity and remote-access controls;
- network segmentation;
- DNS and web security controls;
- centralized logging and alerting;
- device and configuration management; and
- documented access for the people responsible for an incident.
Security and compliance conclusions require review by the appropriate qualified parties. A connectivity worksheet cannot establish compliance.
Define monitoring, testing, and ownership
A failover design that is never tested is a theory with invoices.
Create an operating plan that answers:
- Who monitors each circuit, device, and critical dependency?
- Which conditions generate an alert, and who receives it?
- Who opens and tracks support cases?
- Who communicates with location leaders and affected users?
- How often will controlled failover and failback tests occur?
- Which applications and security controls are checked during a test?
- Where are results, exceptions, and follow-up actions recorded?
- What change triggers a new test: firewall replacement, carrier change, application migration, office move, or configuration update?
Testing must be planned around business risk and approved change procedures. Do not disrupt production simply to complete a checklist.
Location-by-location redundancy worksheet
Complete one row per location. Add application-level detail where risk differs.
| Requirement | Location response |
|---|---|
| Business activities that must continue | |
| Critical users and applications | |
| Acceptable degraded state | |
| Primary connection and known dependencies | |
| Alternate connection and known dependencies | |
| Diversity evidence required | |
| Failover trigger | |
| Traffic priorities on alternate path | |
| IP, DNS, VPN, and inbound-service considerations | |
| Security controls required during failover | |
| Monitoring and alert owner | |
| Support and escalation owner | |
| Test method and cadence | |
| Renewal, construction, move, or opening date | |
| Questions requiring written validation |
For a broader location and circuit inventory, read Multi-Location Business Internet Requirements Before Requesting Quotes. For architecture and operating-model questions, use the Network Modernization Roadmap or review Networking and Connectivity Advisory.
Questions to ask during a requirements review
- Which outage scenarios are we designing for?
- Which applications must survive a path change?
- What capacity or performance reduction can the business accept temporarily?
- What evidence is required to validate diversity?
- Which shared devices, power sources, and services remain single points of failure?
- How are security policies preserved?
- Who monitors, escalates, communicates, tests, and approves changes?
- Which renewal, construction, lease, or opening dates constrain the decision?
Frequently asked questions
Do two internet providers guarantee redundancy?
No. The services may share last-mile facilities, building pathways, local equipment, power, upstream dependencies, or cloud services. Validate the failure domains that matter to the design.
Is wireless backup appropriate for every business location?
It depends on the location, signal conditions, application requirements, capacity needs, equipment, security design, and other constraints. Treat it as an option to evaluate, not a universal answer.
What is the difference between redundancy and failover?
Redundancy means alternate capacity or components exist. Failover is the process that detects a problem and moves defined traffic or services to an alternate state. A design may contain redundant components without effective failover.
Should failover always be automatic?
Not always. Automatic, manual, and controlled approaches have different operational and application implications. Choose the behavior from documented requirements and validated architecture.
How often should internet failover be tested?
Set a cadence based on business risk, architecture, change frequency, and approved operating procedures. Test again after material network, security, application, carrier, or location changes.
Does this worksheet replace engineering or supplier documentation?
No. It organizes business and high-level technical requirements. Architecture, availability, pricing, service levels, construction, and implementation details require appropriate validation and approved documentation.
Build the requirement before comparing options
The Data Partner can help organize the locations, business impact, dependencies, continuity expectations, and validation questions before a provider evaluation begins. Initial contact should remain high level; do not submit network diagrams, credentials, account records, invoices, or other sensitive material through the public form.
To compare wired, wireless, and managed-routing patterns before requesting options, read Primary and Backup Internet Design for Business.