Nobody looks closely at tour data until something goes wrong. Then a claim gets filed, or a client asks why nobody saw the vehicle that was broken into, or opposing counsel requests everything you have for a particular night — and your guard tour audit trail is suddenly the most important document your company produces. The uncomfortable discovery, at that point, is that most tour records are built to satisfy a monthly report, not to withstand someone trying to take them apart.
This post is about what makes tour data hold up. It is not legal advice, and evidentiary standards and recordkeeping requirements vary by state and by jurisdiction — verify anything specific with your regulator, such as TDLR in Texas, and with your own counsel.
What “surviving scrutiny” means in practice
Set aside courtroom language for a moment. The people who will actually pick apart your records are, in rough order of frequency:
A property manager who wants to know whether the officer really covered the garage on the night a tenant’s car window was smashed. An insurance adjuster building a timeline. Your own client’s corporate risk group during a vendor review. And occasionally, a lawyer.
All four are doing the same thing: looking for a reason to doubt the record. The record survives if the answer to every “how do you know” question is something other than “because the officer said so.”
The four properties that make tour data credible
1. The officer is identified, not inferred
A scan attached to a device is not attached to a person. Phones get shared, handed over at relief, and left in a vehicle. If your record says “checkpoint 7 scanned by the site phone,” you have a record of equipment.
Credible tour data ties every scan to an individual who authenticated on their own account, on a shift they were actually scheduled and clocked into. That chain — this person, on this shift, at this post — is what turns a scan into testimony. The weakest version of this is a shared login, and it is worth eliminating before you spend money on anything else.
2. The time is recorded by the system, not by the phone
This is the flaw that quietly undermines more tour data than anything else. A phone’s clock is user-adjustable. Time zones change, devices drift, and a phone that has been offline all night reports whatever its clock says when it reconnects.
If your tour times are whatever the handset claimed, then anyone who wants to challenge the record has a trivially easy line of attack: the times came from a device controlled by the person whose work is in question.
The stronger arrangement records the authoritative time centrally, when the scan arrives, and keeps the device’s own claimed time as a separate value rather than as the truth. Offline scans — which are unavoidable in stairwells, basements and steel warehouses — should be stored as captured and then reconciled on upload, with both times preserved and the delay visible. A record that says “captured at 02:41 by the device, received at 02:58” is far more credible than one that silently presents a single number, because it is obviously not hiding anything.
3. Position is captured with the scan
A checkpoint is a token, and tokens can be moved. Recording the officer’s location at the moment of the scan is what distinguishes “the officer was at the northeast dock” from “the tag was read somewhere.”
Be honest about the limits, because overclaiming here is how records get discredited. GPS degrades badly indoors, in parking structures and against building faces; accuracy varies with the device and the sky. A position with a large uncertainty radius proves less than people assume. What it does do reliably is rule things out — a scan recorded miles from the property is unambiguous — and the presence of the check changes behavior on its own.
Store the accuracy value alongside the position. A record that reports its own uncertainty reads as honest. One that presents every fix as a precise point invites the question of why an indoor scan appears to be accurate to a few feet.
4. The record is immutable, and corrections are visible
The fastest way to destroy the value of tour data is to allow someone to edit it after the fact with no trace. If a supervisor can mark a missed tour as complete, then every complete tour in your archive means nothing, because none of them can be distinguished from an edited one.
Corrections have to be possible — officers make mistakes, checkpoints break, notes get filed against the wrong site. The requirement is that a correction is an addition, not an overwrite: the original entry stays, the change is recorded with who made it and when, and the reason is captured. That is what an activity log is for, and it is the difference between “we amended the record” and “the record was changed.”
The supporting evidence around the scan
The scan log is the spine. On its own it is thin. What fills it out:
The officer’s narrative. Daily activity reports filed the same shift, in the officer’s own words, describing what was observed. A DAR written three days later is worth much less than one written at 3 a.m. — and if the timestamp shows it was written days later, the gap will be noticed.
Photos with the conditions they document. A photo of a propped fire door, taken at the checkpoint, is stronger than a sentence about it. Photos also age well: the image carries information nobody thought to write down.
Attendance. Tour records that are not backed by a clean time and attendance record invite an obvious question about who was actually on post. Clock-in with a selfie and a location makes the shift itself part of the same chain.
Exceptions, kept rather than buried. Missed tours, late tours and unreachable checkpoints should be present in the record with their dispositions. A month with no exceptions at all is less believable than a month with three documented and explained. Perfect data reads as curated data.
Retention: decide before you need to
Two failure modes here, symmetrical.
Keep too little, and the request arrives for a night you can no longer produce. Keep everything forever with no policy, and you are storing personal data — officer locations, selfies, notes about identifiable people — with no stated reason, which creates its own exposure and its own questions.
The answer is a written retention policy per data type, applied consistently, set with counsel. Whatever the period, the two things that matter are that it is documented in advance and that it is applied uniformly. Deleting selectively, or extending retention only for records you like, is worse than either extreme.
Also decide how you produce records. If answering a request means someone reconstructing a month from screenshots, the production itself becomes an argument about accuracy. Being able to export the underlying records in a straightforward, complete form is part of the audit trail.
A quick self-test
Take a random night from three months ago at your largest account and try to answer these, using only what your system holds:
- Who was on post, and how do you know it was them?
- What time did each tour start and finish, and where did that time come from?
- Where was the officer when each checkpoint was recorded, and how accurate was that?
- What was observed, in the officer’s words, written when?
- Was anything missed, and what was done about it?
- Has any of it been edited since, by whom, and why?
If any answer is “we’d have to ask the officer,” that is the part of your guard tour audit trail that will not survive scrutiny. Fix that one first.
The point of all this is not paranoia. It is that the same properties that make records defensible — identified officers, trustworthy times, position, honest exceptions — are the properties that make them useful for running the operation on an ordinary Tuesday. Records built only for the monthly report are the ones that fail in both roles.
If you want to see how tour scanning, attendance and field reports are tied to one another, explore CGuardPro’s tour system or get in touch.