Compliance evidence: prove the checks actually happened

Most compliance failures are not failures to do the work. They are failures to be able to show the work was done, months later, to someone who was not there and has no reason to take your word for it.

This is why teams with a 98% completion rate still have difficult audits. The number describes the paperwork, not the practice.

The problem with a tick

A checkbox records an assertion. It carries no reading, no photo, and no indication of whether the person actually looked.

It also carries no time. A form completed honestly across a shift and a form completed from memory at 23:58 produce identical ticks, and everyone in the room during an audit knows it. That ambiguity is the thing you're trying to remove.

What a usable record looks like

Every completed item carries:

• who did it, from their own account and not a shared login
• when, to the minute, captured at the point of work and not end-of-week
• what they found, a reading, a value, a photo where the evidence is visual
• what happened next if it failed, captured in the same completion

The per-step timestamp is the part most systems miss and auditors notice. It is the difference between evidence that the paperwork was filed and evidence that the walk happened.

Exceptions recorded with their corrective action

An item that fails can reveal follow-ups asking for the detail and the action taken. The problem and the response end up in one record, at the time. No more logging the fault in one system and trusting the fix to memory.

A failed check can also raise the corrective task automatically, so the fix is tracked as work, not as an intention. When an auditor asks what happened about the fault found in March, the answer is a linked record, not a recollection.

Sign-off that means something

Route completed work through the people whose approval the standard actually requires: supervisor, then compliance, then whoever else. Stages carry names, so the record shows which function signed, not just that somebody did.

Rejections reopen the task with the reason attached. Approval rights are a permission tied to roles, so a signature represents a second pair of eyes rather than whoever had the login.

Retention and retrieval

History is retained per site and per task, searchable by date. Producing the record for an inspection, an insurer or a client takes minutes, not a week of collating folders.

Where this comes from

None of this is a separate compliance exercise. It's a side effect of running the work in checklists on recurring schedules with approvals: the evidence accumulates because that is how the work was done, which is the only kind of record that stays honest.

The weak points to close first

Three things undermine an otherwise good record, and all three are configuration, not effort:

• Shared logins. A completion attributed to Reception or Kitchen proves a task happened, not who did it. It's the first thing a serious auditor probes, and it costs you the attribution that made the record worth keeping.
• Checks that cannot fail. Check the fridges records nothing. Fridge temperature within range can be answered wrongly, which is exactly why it's worth asking.
• Self-approval. If the person who did the work can sign it off, the approval stage documents a formality. Approval rights are permissions, so this is something you configure once and then stop policing.

Retention is a decision, not a default

Different obligations expect different retention periods, and the time to decide is before you need the records, not after.

Because history is held per task and per site, not in files someone has to maintain, the practical question isn't whether records survive but whether you can find the right ones quickly. Test that deliberately: pick a date six months back, pick a site, and see how long it takes to produce everything recorded that day. If that takes more than a minute or two, fix it while it is a drill and not an inspection.