Most TAPA-certified forwarders believe their security system is the alert. Geofencing flags the exit. The door sensor flags the opening. The device blinks. Someone sees it, eventually. That belief is wrong. An alert is just a timestamp from a telematics event. The auditor checks something else. Who saw the alert. When. And what that person did next.
My position: an incident log without a handling status is worthless for TAPA TSR and FSR. Even when telematics detected the event perfectly.
TAPA stands for Transported Asset Protection Association. Two standards matter for forwarders. FSR, Facility Security Requirements, for warehouse sites. TSR, Trucking Security Requirements, for the transport itself. Both exist in a revised version since 2023. New and re-certifications have used only this version since 15 September 2023 (TAPA EMEA, TSR 2023).
Both standards define three certification levels. Level 1 through 3. Audited by accredited bodies. Or through self-certification, depending on the level. Which level a site or a fleet needs depends on the value and the risk of the goods stored or moved (TAPA EMEA, FSR). Both standards get reviewed every three years. The next revision is due in 2026.
The core of both standards is a documented security programme. With access control. With route and stop rules for transport. And with incident management. Every security incident gets logged. Even an attempted one. Investigated. And reviewed. Not just registered.
This is not a niche requirement anymore. Shippers with high-value goods want the certificate. Electronics. Pharma. Branded products. As a condition for the contract. Not as a nice-to-have.
The technology is usually there already. Geofencing shows when a vehicle leaves a defined area. Door sensors show every opening. Telematics shows every unplanned stop and every deviation from the planned route. All with a timestamp. All in real time.
The incident record still comes together differently. A driver calls it in. The dispatcher writes an email. The security officer summarises it later in a Word document. Hours after the event. From memory. With gaps. With no exact timestamp. With no location beyond "somewhere on the highway."
For the auditor that is a break. Telematics saw the event, down to the minute. The report shows a different time. A different version. Two sources, one event, no reconciliation.
The real reason sits deeper. An alert is not an incident. An incident needs handling. Who responded? When? What was decided? No telematics system records that path on its own. The alert blinks. The handling happens in someone's head. Or not at all.
We build telematics connections for forwarders anyway, for arrival detection and trip reconciliation. A TAPA-ready incident log is the same data stream, with a different set of rules layered on top.
First, event rules per signal. A geofence breach. A door opening outside an approved stop. An unplanned stop past a set duration. A route deviation past a threshold. Every rule writes one line. Timestamp, vehicle, location, rule, raw value.
Second, deduplication. An ongoing state is not a new incident. If a vehicle has already been silent for two hours and the cause is known, no second entry gets created for the same cause. Only a new entry when the state changes. Without this rule, every review list drowns in repeats of the same thing.
Third, a log per handling step. Detected. Seen by whom. Classified as a false alarm or a real incident. Escalated or closed. Every step with its own timestamp and its own name.
Fourth, an alert only counts as handled with a status attached. Not with an email sent. An open alert with no status past a fixed deadline escalates automatically to the next level. That is exactly what an auditor wants to see: not the alert, the path after it.
At a warehouse a fifth layer comes in. The access log at the gate or the loading dock. Who logged in, when. With what authorisation. For which zone. The same structure as a telematics event. Timestamp, location, person, status. A driver entering the dock outside the booked time slot is technically the same case as a vehicle leaving the geofence.
In one of our own fleet watchdogs, we check one signal every 30 minutes. Has a vehicle inside a working window gone more than four hours without a position update? Since 30 July 2026, that watchdog has run 2,232 times. In 578 of those runs, about 26 percent, at least one vehicle sat past the threshold. But only 74 runs, about 3 percent, carried an actually new alert. The rest was the same, already known state. That gap between a raw event and a genuinely new incident is the deduplication that turns a flood of alerts into a log someone still reads.
In dispatch, the order of things changes first. No longer: incident happens, someone notices eventually, someone reports it eventually. Instead: the incident exists as a line, visible immediately, with one clear next action.
The security officer gets a different job. No longer reconstructing incidents after the fact. Instead, working through open handling entries. Every line with a status. Before the audit, an export instead of a week spent searching the inbox.
A customer with high-value cargo sees a different signal in a real incident. Not whether an alert fired. Whether someone responded fast, and what they decided.
The insurer looks at the same thing first in a claim. Not the time of the alert. The time of the response. A three-hour gap between the event and the first handled step is its own problem in a claim, separate from the incident itself.
Three honest limits.
Not every event maps cleanly to one cause. A geofence alert can be a detour. Or a real incident. The rule can trigger the alert. It cannot judge it. That stays a human's job.
Not every telematics feed has the same precision. Older hardware reports less often. An event between two position updates stays invisible until the next update arrives. The log is only as good as the source's reporting rate, not better.
An automated log does not replace a security programme. It documents events and their handling. It does not decide which geofence threshold is right, which level a site needs, or when an incident becomes reportable. Those calls belong to the security officer or management. Automation supplies the basis. Not the judgment.
Event rules per telematics signal, with deduplication against recurring causes. A log per handling step, with a timestamp and an owner. A fixed escalation deadline for open alerts. An access log at the gate or the dock, in the same structure. An export as evidence, for both FSR and TSR.
How long does it take you, from an alert to the first documented response? Send me the number, even if you do not know it yet. Then I will show you, in a process check, what an incident record for exactly that alert looks like.
