Incident Reporting That Survives a Client Audit

An incident report survives a client audit when it was captured as structured data at the time, moved through a defined workflow with timestamps on each stage, and can be reproduced months later with its evidence intact and its edit history visible. A narrative written up at shift end and emailed as a document fails all three tests. It reads fine on the day and it cannot be defended a year later, because nothing in it establishes when it was written, what was known at the time, or whether it has been revised since.

Incidents are the most externally visible thing a security agency produces. Clients read them, sometimes carefully, occasionally with lawyers. This is the area where the gap between a competent agency and a credible one is largest, and it has very little to do with how well the officer writes.

Structure at the point of capture

The decision that determines everything downstream is whether an incident is captured as a typed record with defined fields or as free prose. Prose is easier for the officer and worthless for analysis, because you cannot count, trend or compare narratives.

A workable type list covers the events security operations actually encounter: unauthorised access or security breach, theft or missing property, fire alarm activation, medical emergency, accident, near miss, staff misconduct, equipment or system failure, and a residual category for anything genuinely uncategorised. Nine or so types is about right. Too few and everything lands in the residual bucket; too many and officers pick inconsistently, which destroys the comparability the types existed to provide.

Severity needs to be a separate axis from type, with a small number of levels and, importantly, written definitions of each. Without definitions, severity becomes a measure of how the reporting officer felt rather than a property of the event, and severity-based escalation rules built on top of it fire unpredictably.

The fields that matter alongside type and severity: date and time of occurrence as distinct from date and time of reporting, precise location within the site, people involved, description, immediate actions taken, and evidence attachments. The occurrence-versus-reporting distinction is the one most often collapsed into a single timestamp, and it is exactly the gap a client will ask about when a report was filed three hours after the event.

Offline capture is not optional

Incidents happen in stairwells, loading bays and basement car parks. If the reporting tool requires connectivity, the officer either waits until they are back at a post with signal, by which time detail has degraded, or writes it on paper and transcribes it later, which reintroduces every problem structured capture was meant to solve.

Draft-offline with automatic sync is the requirement. The value is not convenience; it is that the timestamp and the detail are captured close to the event rather than reconstructed after it.

The workflow and its timers

An incident moves through report, triage, assignment, investigation, resolution and closure. Whether those exact stages suit a given agency matters less than that stages exist, that transitions are timestamped, and that responsibility is explicit at each one.

Timers on the stages are what make service level commitments real. A contract that promises a serious incident will be escalated within thirty minutes and a written report provided within twenty-four hours has created two measurable obligations. Without stage timestamps, compliance with them is an assertion. With timestamps, it is a report you can hand over.

Escalation rules should be automatic and driven by severity plus elapsed time. A high-severity incident sitting untriaged past its window escalates without anyone having to remember to escalate it, which is the point: the situations where escalation matters most are the situations where everyone is busy.

Investigation as a workspace, not a field

For anything beyond routine, the investigation needs somewhere to live. Assigned investigator, interview notes, references to CCTV footage with timestamps and retention deadlines, witness statements, and corrective actions with owners and due dates.

The CCTV reference deserves specific attention because it has a deadline attached. Footage is typically retained for a limited window, and an investigation that identifies relevant footage in week four of a thirty-day retention cycle has three weeks less margin than it thinks. Recording the footage reference and its retention expiry at the point the incident is logged, rather than when the investigation gets around to it, is a small discipline that prevents a specific and irreversible failure.

Corrective actions are the part that closes the loop between incidents and the rest of the operation. An action that changes a standing instruction, adds a patrol checkpoint, or updates a site risk register is the mechanism by which an incident makes the operation better. Tracked to closure with an owner, it is evidence of a functioning safety system. Left as a paragraph in a report, it is an intention.

The client-facing report

What the client receives should be generated from the record rather than written separately. A branded document with the timeline, the actions taken, the root cause where established, and the prevention measures adopted.

Generating it from the record rather than composing it independently has a specific benefit beyond saving time: the client report and the internal record cannot diverge. When they are separate documents, they drift, and a discrepancy between what the client was told and what the internal file says is a much worse position than either document alone.

Where a client portal exists, incident visibility is the feature clients value most, because it removes the wait between an event and being informed about it. It also imposes discipline, since a record a client can see gets completed properly.

Analytics that change decisions

Once incidents are typed and severity-rated, aggregate patterns become available: incident rates by site, client and post type, repeat issues at specific locations, time to closure by severity, and trends across quarters.

The genuinely useful output is normalised rather than absolute. A site with more incidents than others may simply be larger or busier. Incidents per guard-hour, or per thousand visitors where that is measurable, tells you something about the site; raw counts mostly tell you about its size. The comparison worth making is a site against its own history, and against similar sites, not against the portfolio average.

This is also the data that supports commercial conversations. A client whose site generates repeated unauthorised access incidents at the same entry point is a client who may need a physical security change or additional coverage, and the incident trend is the evidence for that discussion.

How Moxogo implements it

Moxogo Security captures incidents as structured records across nine defined types with separate severity levels, distinguishing occurrence time from reporting time, with location, people involved, immediate actions and evidence attachments. Reports draft offline in the guard app and sync when connectivity returns.

The workflow runs report through triage, assignment, investigation, resolution and closure with timestamped transitions, service level timers per stage and automatic escalation driven by severity and elapsed time. The investigation workspace holds assigned investigators, interview logs, CCTV references and corrective actions with owners and due dates. Client-ready reports generate from the same record rather than being composed separately, and where the client transparency portal is deployed, clients see incident status directly. Analytics cover incident rates by site, client and post type, repeat issue identification and time-to-close trending.

A practical test

Pick a serious incident from six months ago. Try to establish, from the record alone: when it occurred as distinct from when it was reported, what the officer knew at the time of filing, what CCTV was referenced and whether it still exists, what corrective action was agreed, and whether that action was completed. If the record cannot answer those five questions, it is a description of an incident rather than a defensible account of one.

Frequently Asked Questions

Why are typed incident records better than written narratives? Because narratives cannot be counted, trended or compared. Structured types and severity levels make aggregate analysis possible, which is what turns incident data into evidence about site risk rather than a filing cabinet of individual accounts.

Why separate occurrence time from reporting time? Because the gap between them is itself information a client will ask about. Collapsing both into a single timestamp hides whether a report was filed immediately or three hours later, and that difference matters in any serious review.

Does incident reporting need to work offline? Yes. Incidents occur in stairwells, loading bays and basements without signal. Without offline drafting, officers either wait for connectivity while detail degrades or write on paper and transcribe later, which reintroduces every problem structured capture was meant to solve.

Why record the CCTV reference immediately rather than during investigation? Because footage retention windows are finite and non-negotiable. An investigation that identifies relevant footage late in the retention cycle may find it already overwritten, and that failure is irreversible. Logging the reference and its expiry when the incident is filed preserves the option.

Should client incident reports be written separately from internal records? No. Generated from the same record, they cannot diverge. Separately composed documents drift over time, and a discrepancy between what a client was told and what the internal file says is a materially worse position than either document alone would be.

Related in this series

• Overview: What Does a Security Agency in Singapore Actually Need From an ERP?
• patrol verification
• audit readiness
• the client portal and field layer