The Evidence Trail Insurers Actually Read: Specifying Scaffold Alarm Logs for Claims
Photo: N Chadwick , CC BY-SA 2.0, via Wikimedia Commons
A scaffold alarm is usually sold on its ability to make noise. After a theft, however, the insurer is less interested in the siren than in the record. The event log is the difference between a claim that can be reconstructed and a claim that depends on recollection. For UK contractors, specifying the log at design stage is now as important as specifying detector coverage.
Start With the Claim Question
An insurer or loss adjuster will typically ask a simple sequence of questions: when did the activation occur, which detector operated, was there a tamper event, was the system powered and communicating, who responded, and what evidence exists to show the log has not been altered? If the panel cannot answer those questions in a structured export, the alarm may still have performed as a deterrent but it will perform poorly as evidence.
This is why the event log should be treated as part of the security design, not as a maintenance screen that happens to exist in the panel software.
Fields That Carry Weight
Synchronised time stamps. Every event should carry a time stamp referenced to a reliable time source, with GMT/BST handling stated clearly. Clock drift is one of the most common weaknesses in post-theft reviews. A log that cannot be aligned with site attendance records, CCTV or neighbour reports is difficult to rely on.
Tamper events recorded separately. Housing opening, wall removal, device masking and communication-path interference should be distinct event types, not folded into a generic alarm condition. Tamper history often shows whether a system was probed before the theft itself.
Detector identity and physical location. A log entry reading "Zone 1" is of limited value. The record should identify the detector by unique reference and describe its location in site terms: scaffold face, elevation, lift level, bay or access point. That allows the log to be matched to the scaffold layout and to the physical evidence.
Power and communications status. Mains failure, battery voltage, low-battery warnings, GSM or IP signal strength, heartbeat gaps and last-gasp transmissions should all be retained. An insurer needs to distinguish a system that was disabled from one that lost power through an external cause. A gap in heartbeats is not an absence of events; it is an event in itself.
User and key-holder actions. Arming, disarming, remote acknowledgement, isolate commands and site attendance should be attributable to an individual user or key-holder, not a shared PIN. The response trail matters as much as the activation trail, particularly where out-of-hours attendance is part of the site security plan.
Retention and export integrity. The log should be exportable in a readable format, with a clear retention period and access controls. Retention should be set with reference to the insurance policy, contractual requirements and the realistic timescale for discovering a loss. A system that overwrites evidence before the claim is notified is a false economy.
What Insurers Tend to Ignore
Raw siren duration, marketing descriptions of "24/7 protection" and unstructured text messages rarely assist a claim. Nor does a screenshot of a single alert without context. A long list of nuisance activations can also damage credibility if it suggests the system was routinely ignored. The useful evidence is the structured chronology: what happened, in what order, on which device, and what action followed.
Common Gaps After a Theft
Several weaknesses recur in post-incident reviews. Clocks may be unsynchronised. Battery and signal status may be missing because the panel only logs alarms. Detector labels may be generic. Key-holder actions may be recorded only in a notebook. Logs may be held locally on a panel that was damaged or removed. Exports may be editable spreadsheets with no audit trail.
The practical fix is to test the log before handover, not after a loss. Simulate a detector activation, a tamper, a mains failure and a communications interruption. Export the result and check whether a third party could understand the sequence without a site visit.
Specifying the Log at Design Stage
The specification should ask for time synchronisation, role-based user accounts, detector-level event records, power and communications monitoring, tamper event types, a stated retention period and a secure export. The handover file should include a log sample, an export procedure and a named contact for evidential requests.
Data protection also needs attention. Event logs should contain only what is necessary for security and claims purposes, with controlled access and a retention schedule that is actually applied. A log that is comprehensive but poorly governed creates its own risk.
The Practical Test
A useful test is to ask whether the log could support a claim without anyone who installed the system being present. If the answer is no, the design is incomplete. Scaffold alarms are deterrents, but they are also evidence-generating systems. Specifying them as such gives contractors a stronger position when a theft becomes a claim.