Logs That Were Never Meant as Evidence
Operational logs as evidence: what each system was built to record, the gap between that and what it is read as, and the questions to ask its owner first.
Five operational logs, pressed into service in one investigation
Designed for access control; records credentials.
Designed for fleet cost; records a vehicle.
Operator codes are shared on busy days.
Timestamps are when records were saved, not when work was done.
Sessions stay open after people leave.
Two of the five record what they appear to record. The other three record something adjacent, and the difference is where investigations go wrong. This is one employer's own reconstruction, not a statement of what any rule requires.
Every system in an organisation records something, and almost none of them was built to record attendance. A door controller exists to control doors. Telematics exists to manage fuel. A ticketing system exists to move work along. Each produces timestamps that look like attendance data and attest to something slightly different.
The evidential discipline in “Logs That Were Never Meant as Evidence” should also govern workforce technology. A team evaluating read more on the official website for tips to increase productivity can use time and project records as operational context, but should preserve the original record, document access and let the employee correct a misleading entry before it supports a conclusion.
Using them is legitimate and frequently the only option. What matters is asking the owner of each system what it actually records before treating it as a record of a person's day.
Teams reviewing “Logs That Were Never Meant as Evidence” can cross-check their approach against the EPIC workplace privacy resources. The comparison is most useful when the organisation records which recommendations apply, which do not and why.
The questions to ask the system owner
- What event, exactly, writes a row — and what does not write one?
- Is the timestamp the event or the moment the record was saved?
- Is the identifier a person, an account, a device or a code?
- Are identifiers shared, and if so when?
- How long are rows kept, and is anything purged or aggregated?
- Is the clock synchronised, and when was that last checked?
Six questions, one conversation, and they change the reading of the data more than any amount of analysis does.
Saved, not done
The third question is the one that produces the most false conclusions. A ticketing system records when a record was saved. Somebody who did the work at ten and wrote it up at four produces a four o'clock timestamp.
Reading that as the time of the work is a straightforward error, and it is extremely common because the field is usually labelled something like "completed".
Shared identifiers
Till operator codes, shift supervisor accounts, generic logins for a machine on a shop floor — these exist because individual credentials were impractical, and they make the log a record of a role rather than a person.
A system owner will say so immediately if asked. Nobody asks, because the report has a name column and the name column looks authoritative.
Sessions that outlive people
Network sign-on and application sessions persist after the person has gone home. A session active until 18:40 does not establish that anybody was at the keyboard at 18:40.
The useful signal is activity within a session rather than its duration — and whether the system records that is, again, a question for its owner.
Negative inferences from operational logs
Nothing in a ticketing system between ten and twelve does not establish that nobody worked. It establishes that nothing was saved, which has several explanations, most of them boring.
Before drawing anything from an absence of rows, ask what the person would have had to do for a row to exist. If the answer is "something they might reasonably not have done that morning", the absence shows nothing.
Retention set by somebody else
Each of these systems has a retention period chosen by its administrator for operational reasons, and those periods are typically short: door logs for weeks, camera footage for days.
That has a practical consequence for any investigation: the evidence window closes quickly and it closes on a schedule nobody involved in the case knows about. Establishing the retention period is step one, because it sets the deadline for everything else.
Exports, and what the export leaves out
Operational systems rarely export everything. A report shows the fields somebody chose when the report was written, and the fields left out are frequently the ones that matter — the accuracy flag, the device, the editing history, the raw timestamp.
Ask for the underlying rows rather than the report, or at minimum ask what the report omits. An analysis built on a convenient export is an analysis of somebody else's selection.
Asking before the case
Every question on this page is easier to ask in a quiet week than during an investigation, and the answers do not change.
The single page describing each system — what it records, which identifier, how long, what clock — is a week of conversations once and a permanent asset. Built during a case, it is a week nobody has.
Asking once, for everything
The strongest version of this work is not per-investigation. It is a single page listing every system that produces person-level timestamps, what each records, the identifier type, the retention period and the clock status.
Assembling it takes a week of conversations and it is the document that makes every subsequent question answerable in an afternoon instead of a fortnight. Most organisations have never assembled it, which is why each investigation rediscovers the same facts from scratch — and why each one discovers them a little too late.