Chain of Responsibility is usually discussed as a management and culture question: who in the supply chain has a duty to ensure heavy vehicle safety, and how that duty is discharged. That is the right frame. But underneath it sits something much more mundane that decides whether an operator can actually demonstrate compliance when asked — and it is an IT question.
Under the Heavy Vehicle National Law, parties in the chain must be able to produce records: work and rest hours, maintenance and defect history, mass and load restraint evidence, and increasingly the system data behind all of it — telematics, electronic work diaries, dispatch and scheduling. Requests can come from the regulator, from an investigation after an incident, or from a customer's own due diligence, and they can arrive well after the events they relate to.
A record you cannot produce is, for compliance purposes, a record you do not have. Whether you can produce it depends on where it lives.
Where the records actually are
Ask a transport operator where their compliance records are and the first answer is usually "in the system". Ask which system, and the picture fragments quickly.
- Work and rest data is in the electronic work diary platform, or the telematics platform, or both, or on paper diaries scanned into a shared folder.
- Maintenance history is in the fleet management system, or the workshop's own software, or a spreadsheet, or the dealer's records.
- Load and mass evidence is in the transport management system, on weighbridge dockets in a filing cabinet, or in photographs on a driver's phone.
- Dispatch records are in the TMS, unless the TMS was replaced two years ago, in which case they are in the old TMS, to which nobody has a working login.
Each of those is a place a record can be. Very few operators have a single, current answer to "for a given vehicle on a given day, can we produce everything, and how long would it take?"
The four ways it goes wrong
The system was replaced. Operators change telematics providers, TMS vendors and fleet software as contracts end and needs change. The data from the old system is frequently left behind — still in the vendor's cloud until the account is closed, then gone. A request for records from three years ago lands on a system nobody can reach.
The device was the only copy. Photographs of load restraint, weighbridge tickets, pre-start checks — captured on a driver's phone or a handheld and never moved anywhere else. When the phone is replaced, lost or the driver leaves, the evidence leaves with it.
The backup was never tested. The TMS or fleet system is backed up, in the sense that a backup job runs. Whether it could actually be restored, whether the restore includes the historical data or only the current state, and how long it would take, are questions nobody has asked. Ransomware answers them at the worst possible moment: the operation is down *and* the compliance history is encrypted alongside it.
Nobody can find it. The records exist, somewhere, in a format that was current at the time, and the person who knew how to get to them has moved on. This is the most common failure and the one that looks least like an IT problem — but the fix is entirely an IT one.
Designing for "produce on request"
The principle is the same one that applies to any long-lived record obligation: the ability to produce it must not depend on any single system, vendor, device or person continuing to exist.
Map the record types to their systems. One page. For each category of record the law expects you to hold, where it lives, who owns the system, and how long it must be kept. Most operators have never written this down, and writing it down usually surfaces two or three gaps immediately.
Get data off devices and out of vendors' hands on a schedule. Driver photographs and handheld data should sync to a managed destination automatically, not sit on the device. Telematics, work diary and TMS data should be exported to storage you control at regular intervals — so a vendor change is a migration, not a loss, and so a request for old records does not depend on a vendor relationship you ended.
Treat the TMS and fleet systems as critical. That means restore-tested backups, a recovery time that has been agreed rather than discovered, and at least one copy that cannot be altered or deleted by an attacker who compromises the live environment. Logistics is a deliberate ransomware target because stopping dispatch creates immediate pressure to pay; an immutable copy is what lets you refuse.
Confirm the retention periods and design to them. Different record types carry different periods under the law and under your customers' contracts. It is worth confirming the specific periods that apply to your operation directly, rather than inheriting a number from a previous manager, and then making sure the archive design actually holds records that long.
Test retrieval. Once a year, pick a vehicle and a date and have someone who did not build the system assemble the full record set. Time it. That exercise finds every gap while nobody is asking.
Where the operation meets the compliance trail
The same systems that carry compliance evidence run the operation. When the TMS is unavailable, dispatch stops; when the yard Wi-Fi drops, scanners lose the data trail; when a handheld dies, the pre-start check it held goes with it. Continuity and compliance are the same design problem seen from two sides, which is why we approach IT for transport and logistics operators with both in view at once — depot and yard connectivity built for racking and hardstand rather than an office floor plan, driver devices that are managed and remotely wipeable, and backup and continuity designed around the systems dispatch actually depends on.
A note on advice
This article describes the framework in general terms. Chain of Responsibility obligations, the records required and how long they must be kept depend on your role in the chain, your accreditation and your contracts — confirm them against the current law and your own arrangements rather than a general summary. What holds regardless is the design principle: if the evidence lives only in a device, a departed vendor or a departed employee, you do not really hold it.
*Last updated: 17 September 2026.*