A Second Line Is Not a Safety Net: Quarterly Proof for UK Business Connectivity

Backup internet has a reassuring place on an infrastructure diagram. A second router, a 4G or 5G modem, perhaps a secondary leased line with diverse routing: the boxes suggest resilience. The operational question is narrower. When the primary circuit fails at 10:15 on a Tuesday, which business services actually continue, for how long, and who is accountable for the difference between the diagram and the till?

For many UK SMEs, the honest answer is uncertain. A secondary connection may restore general web browsing while leaving card terminals, cloud telephony and remote access stranded. That is not failover in any commercially useful sense. It is a router with a green light.

A green light proves very little

Connectivity suppliers often describe failover in terms of circuit availability. The business experiences it in terms of transactions, conversations and access. Those are different measurements.

A backup line can be working perfectly and still fail the business if it does not carry the right addressing, routing, firewall policy or service registration. Card payment terminals may be restricted by IP allow-listing. SIP telephony may fail to register or deliver inbound calls. VPN tunnels may be bound to the primary WAN address. Domain Name System queries may resolve inconsistently. Cloud applications may work for some users and not others.

None of these failures will necessarily be visible on the router. They will be visible at the counter, in the contact centre and in the finance team’s inbox.

Start with critical paths, not hardware

A useful test begins by naming the business paths that must survive an outage. For a typical UK SME, that list might include:

• card payments at the till or over the phone;
• cloud productivity and file access;
• inbound and outbound VoIP calls, including the main business number;
• remote access for staff working from home or another site;
• email flow and any line-of-business application hosted outside the office.

Each path needs an owner, a pass criterion and an acceptable interruption. “Internet works” is not a pass criterion. “A test card payment is authorised within two minutes of the primary circuit going down” is.

The exercise should also identify what is deliberately not protected. Not every system warrants automatic failover. A clear statement that a particular service may be unavailable for up to four hours is more honest than an assumption that everything is covered.

Run a fixed quarterly drill

The test should be repeatable, scheduled and documented. A quarterly rhythm is usually sufficient for a small business, with an additional test after any significant change to firewalls, telephony, payment systems or the wide-area network.

A practical script looks like this:

1. Agree the window and notify affected staff. A test that nobody knows about creates its own incident.
2. Record the baseline: active WAN address, DNS behaviour, telephony registration, payment terminal status and remote-access connections.
3. Simulate a primary-line failure using an agreed method. Pulling a cable at the router may be acceptable; shutting the carrier interface or asking the supplier to simulate the outage is cleaner. Avoid improvising in a way that affects other tenants or services.
4. Confirm that the secondary path comes into service and note how long detection and switching take.
5. Test each critical path in turn. Make a card payment, place an inbound and outbound call, open the main cloud application, resolve an external domain and establish a remote-access session.
6. Inspect DNS and firewall behaviour. Confirm which public address the business presents, whether split DNS still works and whether policy follows the traffic onto the backup circuit.
7. Restore the primary circuit and confirm that services return without manual intervention — or record exactly what manual step was needed.
8. File the evidence: timestamps, screenshots, test transaction references and the name of the person who signed off the result.

DNS and firewall checks are not optional

Failover often exposes hidden dependencies in naming and policy. If internal systems point to a DNS resolver that is only reachable over the primary line, name resolution may fail even though the backup circuit is passing traffic. If firewall rules are tied to the primary WAN address, inbound services may disappear. If the telephony system uses SIP, the backup path must permit the required traffic and handle registration cleanly.

The test should therefore include a small number of deliberate checks rather than a general browse. Resolve a known external domain. Confirm the public IP address presented to the internet. Verify that a remote worker can authenticate. Check that the card terminal can reach its payment host. These are simple tests with high diagnostic value.

Measure recovery, not just availability

A failover report should contain times, not adjectives. Record the time the outage was introduced, the time the secondary path became active, the time each critical service was restored and whether any user action was required. Note any transaction that failed and any call that dropped.

Those figures allow the business to compare actual performance with the recovery objectives it has agreed. They also expose the difference between automatic failover and a manual process that depends on someone being in the office. A backup line that requires a director to unplug a cable and restart a router is not unavailable, but it is not automatic either.

Give the test an owner

Resilience decays when nobody owns the evidence. The quarterly drill should have a named coordinator, typically within IT or the managed service provider, and a business sign-off from whoever depends most on the affected services — finance, operations or customer service.

The managed service agreement should state who is responsible for testing which layer. The connectivity supplier may test the circuit; the IT provider may test routing and firewall policy; the business must test the payment and telephony outcomes. Handoffs between those parties are where gaps usually appear.

Report in plain business terms

A one-page summary is enough for most boards and management teams. It should state the date of the test, the critical paths tested, the paths that passed, the paths that failed, the longest service interruption and the actions assigned with dates. Technical detail can sit in an appendix.

In 2026, connectivity is not a peripheral utility for a UK SME. It is the route to revenue, customers and staff. A secondary line is worth having, but it is only a safety net once the business has proved what it carries. The quarterly drill turns an assumption into evidence — and gives the company time to fix the gap before a real outage finds it first.