Prove every critical change: audit trails and access control in tunnel safety management
Ask what tunnel safety precautions consist of and the answer arrives as hardware and paperwork: escape routes, fire detection, ventilation capacity, emergency plans, trained staff. Regulation goes into real detail about which documents to hold and which roles to appoint.
It says much less about the digital evidence a tunnel management system should be able to produce. That gap surfaces during an inspection, when somebody asks a question about a specific date.
What the regulation asks for
Directive 2004/54/EC sets minimum safety requirements for tunnels over 500 metres on the trans-European road network. It names the roles: an Administrative Authority, a Tunnel Manager, a Safety Officer and an independent Inspection Entity. Every tunnel within the Directive’s scope requires safety documentation, which the Tunnel Manager must keep permanently up to date. Inspections run on a cycle and significant incidents are analysed.
PIARC guidance adds practical detail on incident learning, emergency exercises and the continuous improvement of tunnel safety. Operators outside the EU work within national tunnel safety frameworks that address comparable governance and evidence requirements.
National implementation and approval routes vary. The underlying need recurs across jurisdictions: safety documentation describes the approved arrangements, while system records evidence what actually happened.
One boundary matters here. The Directive does not prescribe a digital audit-trail architecture or a role-based access model. Those are system design capabilities that help the Tunnel Manager and the Safety Officer demonstrate how approved procedures and configurations were applied in practice.
Operating parameters are tunnel safety precautions too
Tunnel safety precautions are easy to picture as hardware. A significant part of tunnel safety behaviour is also defined through system configuration. CO and NO thresholds, visibility limits, temperature trip points, ventilation setpoints and closure triggers all influence how the tunnel responds.
Change control on these values should be proportionate to their operational impact. Where parameter changes sit outside formal change control, operating behaviour can shift without the review a documented procedure would receive.
The test is easy to state and uncomfortable to fail. Six months later, the Tunnel Manager may need to establish what the CO threshold was on a particular night, who changed it and which approval supported the change.
Three questions your records should be able to answer
Start with access. Who held permission to change a given parameter? That belongs to the role model, and the answer has to hold for the whole retention period, not just today’s user list.
Then the change itself: what moved, when, and on whose authority. Each parameter classified as safety-relevant should have a change record containing the previous value, the new value, the user, the timestamp, the stated reason and the associated approval.
Last comes system behaviour during a specific event, which sits in operational logging, covered separately in the article on execution feedback and audit trails. Configuration governance and operational logging answer different questions, and an inspection may well ask both.
Designing the role model
For safety-relevant parameter classes, separate change preparation from approval. The engineer who identifies that a ventilation setpoint should change is seldom the right person to authorise it alone, and the workflow should match the parameter’s operational impact.
Scope permissions by parameter class rather than by screen. Access to the ventilation configuration and authority over fire detection thresholds are different things, even when they appear in the same interface.
Keep emergency permissions usable, scoped and recorded. A role model that stops an operator acting during an incident has traded a governance problem for a safety one. Authorised operators need the actions defined in the operating procedure without unnecessary delay, and the platform should record the user, action, time, stated reason and resulting system state for later review.
Shared control-room accounts prevent reliable attribution of individual actions, which undermines every record above. Named accounts with suitable authentication and shift-handover procedures are a prerequisite for a defensible audit trail.
What your tunnel management system has to export
Records that cannot be produced in a usable form do little work. The Safety Officer should be able to pull parameter change history, role assignment history and event records without raising a support ticket with the supplier, and an Inspection Entity reading the output should not need platform training to interpret it. Retention deserves the same deliberate treatment: set it against national rules, contractual terms and the liability framework, and note that the inspection interval is a maximum period between inspections rather than a retention requirement.
Compliance evidence is a system capability
When an inspection examines past operation, the system records help establish whether approved configurations and procedures were applied as intended.
Specifying the audit capability during procurement is usually far less costly than retrofitting it later. Retrofitting can add the capability. It cannot recreate records that were never captured. An audit trail added in year six starts in year six.
Lillyneir designs and integrates tunnel supervisory and control systems for motorway operators and road authorities. Our TM-Hub platform applies role-based authorisation to configured operating parameters and maintains exportable change and event histories for the operator and the Safety Officer. TM-Hub supports live operation at the M85维也纳-霍尔斯坦隧道综合体 in Hungary, commissioned in December 2024. To discuss audit and compliance requirements for your tunnel, contact our team.
