Who owns fault resolution when connectivity problems involve multiple providers?

Fault resolution should have one accountable owner, normally the connectivity provider named in the business service agreement. That owner may need to involve an access carrier, wholesale network operator, hardware supplier, cloud platform or internal IT team, but responsibility for coordinating diagnosis should not be passed between parties without a clear handover. The contract should define where the provider’s responsibility begins and ends, who manages each dependency, and how the incident is escalated.

The service demarcation point is the starting point. This is the agreed boundary between the provider’s service and the customer’s equipment or network. Depending on the service, it may be a network termination device, router, firewall interface, building handover point or another specified connection. The agreement should state whether the provider is responsible for the circuit only, the managed router, customer premises equipment, internal cabling, wireless network and configuration. Without this detail, each party may test only its own equipment and argue that the fault lies elsewhere.

A practical responsibility model separates accountability from technical ownership. The primary provider remains accountable for the incident record and customer communication. A carrier may own the physical access circuit, while a managed IT provider may own the edge router, firewall or local network. A cloud provider may own the availability of its own platform, but not necessarily the internet connection used to reach it. These roles can coexist, provided the contract identifies who coordinates them and who confirms that service has been restored.

Before troubleshooting starts, the parties should establish what has actually failed. A complete fault assessment should distinguish between:

• Loss of the physical access circuit or leased connection.
• Failure of the provider’s router, modem, network termination device or power supply.
• Incorrect routing, firewall, authentication or configuration settings.
• Loss of local switching, wireless access or internal cabling.
• Domain Name System, addressing or name-resolution problems that make a working connection appear unavailable.
• Failure of a particular cloud application or remote service rather than the underlying connectivity.

Monitoring and diagnostic evidence can help locate the fault without relying on assumptions. Useful evidence may include interface status, loss and latency measurements, routing information, device logs, power records, configuration changes and tests from more than one site or connection. The time of the first symptom, affected locations, affected applications and any recent change should also be recorded. A connectivity provider should use this information to raise a supplier case with the relevant carrier or operator where the fault is outside its own network.

Escalation should follow the service chain, not the customer’s guess about the cause. If the provider suspects an underlying carrier, it should open and manage the appropriate wholesale or network case rather than instructing the customer to start again with another helpdesk. If the carrier reports that its circuit is operational, the primary provider should continue testing the equipment, routing and handover rather than treating that statement as proof that the customer is at fault. The same principle applies when a cloud service is involved: connectivity to the service and the service’s own operation need to be tested separately.

Contracts and service level agreements should make this process measurable. They should define:

• The single point of contact for reporting and tracking a fault.
• The service components included within the provider’s responsibility.
• The exact demarcation point and any customer-owned equipment beyond it.
• How incidents are categorised by business impact and technical severity.
• How the provider records actions taken by third parties.
• When an incident is escalated to a network operator, engineering team or senior service manager.
• What information is supplied during investigation and at closure.
• How restoration is verified and how a recurring or complex fault is reviewed afterwards.

Restoration should not be treated as complete merely because a circuit shows a signal or a router reconnects. The provider and customer should confirm that the relevant business services work across the intended paths. For example, a site may have internet access but still be unable to reach hosted applications because of a routing, firewall or authentication issue. A second connection may be available but incorrectly configured for failover. Verification should therefore cover the affected locations, critical applications and any resilience arrangements included in the service.

Where several providers are involved, the customer should retain an up-to-date service map showing circuits, carriers, routers, firewalls, cloud dependencies, IP addressing and ownership. Configuration records should identify which party can change each component and how changes are approved and documented. This reduces the risk that an incident is prolonged by an undocumented device, an obsolete contact or a configuration that no provider recognises.

For a small or medium-sized organisation without a full in-house IT team, a managed IT provider can help interpret evidence, coordinate the connectivity supplier and separate a carrier fault from a local network or security issue. The important requirement is not simply having more than one technical supplier; it is having a documented operating model in which one accountable party controls the incident, dependencies are visible and responsibility is tested against the agreed demarcation point.