Copper's Last Call: Auditing Alarm Signalling Before the Analogue Sunset

For many UK premises, alarm signalling has been treated as background infrastructure: a copper pair in a riser, a dialler beside a panel, and an assumption that the line will keep working because it always has. That assumption is becoming harder to defend. As analogue services are retired and wholesale line products are withdrawn, fire and intruder panels that still depend on traditional telephone connections are moving towards a practical cliff edge. The compliance problem is not simply that the technology is ageing. It is that many sites cannot produce a reliable record of which signalling paths they depend on, what those paths connect to, or whether the monitoring centre has actually received a test signal.

A migration to IP, radio or another managed path may be sensible. But a migration carried out without an evidence trail simply replaces one undocumented dependency with another. The audit question is straightforward: can the site show, panel by panel, what path carries the alarm signal, who provides it, how it is monitored and what happens when it fails?

Start at the panel, not with the supplier

Signalling audits often begin with a monitoring contract or a provider spreadsheet. That is the wrong starting point. The estate should be built from the physical panel outward. For each fire panel, intruder panel and relevant ancillary system, record the asset identifier, location, make and model, standards context and whether it is monitored. Then trace the signalling path from the panel to the transmission device and from that device to the line, SIM, network termination or radio equipment.

This is where discrepancies appear. A panel may be recorded as dual-path when one path has not been active for months. A line may be billed but no longer connected to the panel. A shared line may serve a lift emergency telephone, a fax machine or a building management system as well as an alarm. Photographs, labels and physical trace evidence are useful because they expose the difference between what the contract says and what is actually installed.

Build a signalling-path register

The register should be a controlled document, not a tab hidden in an installer's handover pack. One row per path per panel is a practical structure. For a genuinely dual-path panel, that means two rows. Each row should capture the panel or asset identifier, path sequence, technology type, provider and account reference, service identifier, routing destination, polling interval, last polling evidence, last end-to-end test, failover arrangement, contractual owner and migration status.

Technology type should be specific enough to be useful: analogue PSTN, ADSL with analogue voice, dedicated IP, wireless, radio, GSM or a managed service. 'Digital' is not a path type. Nor is 'cloud monitoring'. The register should also record whether the path is shared, whether it has battery or power backup, and whether it depends on a router, switch or concentrator that sits outside the alarm contract.

Version control matters. A communications migration is a change to a life-safety or security system, even when it is described as a like-for-like swap. The register should show the before and after state, the date of change, the person who authorised it and the evidence that the new path was tested. Without that discipline, the site cannot demonstrate that the monitored system remained monitored throughout the transition.

Evidence that the path is alive

A line that dials out when tested is not the same as a path that is continuously monitored. Polling evidence is the stronger record. For each path, the site should be able to show the polling interval, the source of the evidence, the date and time of the last successful poll, and the tolerance for a missed poll. A monitoring centre report is more useful than a contractor's assertion, but it still needs to be reconciled to the panel and path it claims to cover.

ARC acknowledgement is the second evidential layer. When a test signal is sent, the record should show that the alarm receiving centre received it, not merely that the engineer pressed a test button. The acknowledgement should identify the panel, the path used, the time of receipt and the reference under which it was logged. For fire systems, the relevant standards and insurer requirements should inform the test regime, but the audit principle is universal: a test without a receipt is an assertion, not a record.

Provider invoices, service schedules and ceased-line notices are useful corroboration. They can reveal a path that has been billed but disconnected, or a migration that was ordered but never completed. They should not be treated as proof of monitoring on their own.

Failover is a test, not a claim

Dual-path compliance is often accepted on the strength of a supplier statement. That is a weak position. Failover should be tested in a controlled way, with the primary path isolated and the secondary path observed. The record should show the time of isolation, the time the secondary path carried the signal, the ARC acknowledgement and the time the primary path was restored. Where the test risks disturbing live monitoring, it should be planned with the monitoring centre and the responsible person.

The test should also examine independence. Two paths that share a router, a power supply, a carrier or a physical route are not independent simply because they appear as two rows in a contract. The register should record the dependency, even if the answer is uncomfortable.

Questions for the monitoring supplier

Before accepting a 'dual-path compliant' claim, put specific questions in writing. Which paths support this panel, and what evidence can you provide for each? What is the polling interval, and what report will you supply to prove it? If the primary path fails, how is the ARC alerted, and how quickly? Are the two paths independent in carrier, route and power? Who is responsible for ordering and ceasing lines during migration? What test certificate and ARC acknowledgement will be issued after cutover? Which legacy devices are incompatible with the proposed replacement? And how will the supplier notify the site when a service or product is being retired?

The answers should be filed with the register. If they are vague, the risk should be recorded as unverified rather than treated as compliant. A migration can then be planned on evidence: panel by panel, path by path, with testing and acknowledgement built into the change. The analogue sunset is not only a technology event. It is an audit event, and the sites that fare best will be those that can prove what their alarms were using before the line went away.