The First Witness Is the Clock: Time Synchronisation as an Audit Control

The audit trail starts before the incident

When an incident is reviewed, attention goes to the camera, the door record or the fire panel. The first question is usually 'what does the footage show?' The better question is 'what time is it?' If the CCTV recorder, the access control system and the fire panel are not working to the same time reference, the evidence does not just become less precise. It becomes contradictory.

Clock drift is mundane and therefore easy to ignore. A recorder loses a few seconds after a power interruption. An access control controller drifts because it is not synchronised to a reliable source. A fire panel is set to local time while the CCTV system records in UTC. Each system looks healthy in isolation. Together, they can place the same event in different minutes, or even different hours, and none of the logs will announce that they disagree.

The clock is the first witness. If it is not controlled, the audit trail is not controlled either.

How small errors become contradictions

A typical example is a door alarm at 09:15. The access control log shows the door forced at 09:14:58. The camera covering the door shows the person arriving at 09:16:03. The fire panel records a related input at 09:15:22. None of those differences is large in isolation. Together they are enough to support an argument that the door event and the camera event are unrelated.

In an investigation, that argument has to be closed down with evidence. In a compliance review, it may be enough to undermine confidence in the whole record. The problem is not that any one system is badly designed. The problem is that time has been treated as a local setting rather than a controlled configuration item.

The UK adds a predictable complication. Greenwich Mean Time and British Summer Time change twice a year. A system that records in UTC and a system that records in local time will disagree by an hour for part of the year unless the relationship is documented and understood. A system that applies the change automatically and a system that is changed manually will disagree at the changeover. A system that is never changed will disagree for months.

Checks that expose the gap

Time synchronisation should be checked as a system, not as a setting on a single device. Start by recording the time source for each system: CCTV recorder, cameras, access control server, door controllers, fire panel, repeater panel, incident logging system and any building management system that contributes to the record. Then compare them at the same moment against a trusted reference.

The checks should include:

• the current offset between each system and the reference;
• whether the system uses a network time source, a radio time signal or a manual setting;
• whether the time source is authenticated and resilient to network loss;
• how the system handles the spring and autumn time changes;
• what happens after a power cycle or a network outage;
• whether the recorder and the cameras agree with each other;
• whether the access control server and the door controllers agree;
• whether exported logs include the time zone and offset.

A screenshot of a clock is not a time audit. The record should show the method, the reference used, the offsets found and the action taken. If a system cannot be synchronised automatically, the manual correction procedure should be documented and the correction itself should be logged. Changing a clock is a change to evidence. It should leave a trace.

Contractor questions that sort the serious from the superficial

Ask the CCTV maintainer what time source the recorder uses and whether the cameras follow the recorder or keep their own time. Ask the access control provider whether the controllers are synchronised to the server and what happens when the server is offline. Ask the fire alarm contractor whether the panel logs in local time or UTC and how that is recorded in exported reports.

Then ask the questions that expose weaker arrangements. Can you provide a drift report? How do you prove that a time correction was made and by whom? What happens to historical logs when the clock is corrected? Are time changes audited? Are they restricted to authorised users? Does the maintenance schedule include time synchronisation, or is it something that only gets noticed when an incident occurs?

These are not unreasonable questions. They are the same questions an investigator, insurer or auditor will ask after an incident, only asked earlier and in a calmer room.

Making time a controlled item

The practical fix is not always a major project. Many sites can improve matters by defining a single time reference, documenting which systems use it, checking offsets on a scheduled basis and recording the results. Where systems cannot be synchronised automatically, the manual process should be owned, trained and logged.

The audit file should show that time is managed, not merely present. That means a named responsibility, a checking interval, a record of corrections and a clear statement of the time zone convention used across systems. It also means including time synchronisation in contractor governance. A maintenance regime that services cameras but never checks their clocks is only maintaining part of the evidence chain.

Operations teams already understand that a camera pointing at the wrong door is a problem. A camera pointing at the right door with the wrong time is just as serious, and harder to spot. The clock is not a background detail. It is the control that makes every other record usable.