What Must a Passport Software Audit Trail Record?

A software audit trail is the immutable record of who created, read under restricted access, introduced, modified or updated each passport field, and when, under what authority and for what reason. The audit trail supports conformity evidence, market surveillance checks, supplier data verification and life stage linkage, and it is the evidence that allows a passport to be trusted after many updates by many actors. A passport without an audit trail is a current snapshot without a history, and an authority cannot tell whether the snapshot is the result of verified updates or of unchecked edits.

Audit trail design is a legal design task, not a logging convenience. The trail must record the actor, the field, the old and new values, the reason, the authority and the time, for every change that affects passport content, and it must record access decisions for restricted tiers. A general system log that records server events, without field level change records, does not meet the trail purpose, because the log cannot answer the question of who changed a specific field and why. The trail should be designed field by field, from the Annex XIII catalogue.

What events must the audit trail record?

The audit trail must record creation, introduction, modification, updating, correction, life stage linkage, access grants and denials for restricted fields, registry uploads and confirmations, and supplier data verification decisions. Each event record should carry the battery identifier, the field, the actor identity and role, the authority basis, the old and new values where applicable, the reason and the timestamp. An event record without a reason, or without an authority basis, is incomplete, because the reviewer cannot judge whether the change was authorised.

An event catalogue should list every event type, its required fields and its retention period, with the catalogue version controlled. A catalogue that lists event types without required fields will produce inconsistent records, because different parts of the system will record different detail for the same event. A catalogue with required fields per event type produces consistent records that can be queried and audited. The catalogue should be reviewed when a new update route or a new actor type is added.

How is the audit trail protected from alteration?

The audit trail is protected from alteration through append only storage, access control that separates trail writing from trail reading, integrity checks such as hashing or chaining, and separation of duties between the actor who makes a change and the actor who can view or export the trail. A trail that can be edited by the same role that edits passport fields can be altered to hide an unauthorised change, and the trail then proves nothing. Protection should be tested by attempting to alter a trail entry in a test system, and by verifying that the alteration is detected or prevented, with the test result filed.

Worked check: a test attempts to change a carbon footprint value in the trail to match a passport field that was edited without authorisation. The integrity check fails, the alteration is detected, and the incident is logged. A trail without integrity checks would accept the altered entry, and the unauthorised passport edit would appear authorised. The test proves the protection, and the proof should be filed with the software release record.

How are audit trail records retained and accessed?

Audit trail records are retained for the period required for technical documentation and conformity evidence, and must remain available to market surveillance authorities and notified bodies under the tier rules. Retention should be defined per event type, with the longest applicable period governing the trail as a whole, so that a trail is not deleted in part while the passport it supports remains live. Access to the trail should be controlled by role, with authority access provided through a defined export route that preserves integrity and completeness.

Retention and access should be documented in a trail policy, stating the retention period, the storage location, the backup arrangement, the access roles and the export route. A policy that states only a retention period, without storage and access detail, cannot be implemented. A policy with retention, storage, backup and access detail can be tested, and the test should include a restore from backup and an authority style export, with the results filed. The policy should be reviewed when the hosting arrangement changes.

How does the audit trail support market surveillance?

The audit trail supports market surveillance by allowing an authority to trace a passport field from its current value back through every change to its source, including supplier data, test evidence and operator verification. An authority request for a field should be answerable from the trail without reconstructing the history from emails, spreadsheets and memory. A trail that supports that trace, with source links for each change, reduces the time and dispute in a surveillance check, and it allows the operator to show that a field was verified rather than merely asserted.

Surveillance readiness should be tested by a mock authority request, in which an authority style query for a sample battery is answered from the trail and evidence files within a defined time, with the answer checked for completeness. A mock request that is answered from memory or from a search across inboxes will reveal the gap between the trail design and the trail in practice. The mock request should be carried out periodically, with the result and any corrections filed.

How are audit trail failures handled?

Audit trail failures, such as a missing event, a corrupted entry or a gap in the trail, should be treated as record incidents, with the affected batteries identified, the cause investigated, the trail reconstructed from source evidence where possible, and the incident recorded with the correction. A gap that is filled by recreating entries from memory, without source evidence, creates a false trail that is worse than a disclosed gap. A disclosed gap, with the reconstruction basis stated and the affected fields marked, preserves honesty and allows an authority to judge the remaining evidence.

Incident handling should include a trail integrity check after the correction, to confirm that the trail is complete from the correction point onwards, and a process change to prevent recurrence. A correction without a process change will recur, and a process change without a trail check will leave the operator uncertain whether the correction worked. Both steps should be recorded, with dates, and the incident file should be retained with the passport evidence.

What audit trail claims should be avoided?

Audit trail claims should avoid stating that a system is auditable because it logs activity, that a system is tamper proof because it uses a database, or that a system is compliant because it retains logs for a long period. Each claim needs a field level test: a trace test for auditability, an alteration test for integrity, and a retention and access test for availability. As checked on 28 October 2026, the audit trail design should be reviewed after each implementing act change that affects updating or access rules. This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting.

This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting. The audit trail is the history that makes a current passport trustworthy, and it should be tested by a mock authority request.