What is an audit trail?
An audit trail is a record that lets you show a third party how a data record, a decision or a configuration reached its current state. Technical log files mainly serve operations and attack detection; an audit trail is kept as evidence. The same logging can feed both; for evidence, completeness, protection against alteration and retention count as well.
Which events a system logs technically and how they are analysed is covered in logging and monitoring. How logging and evidence fit into a management system is covered in the guide Implementing an ISMS.
What does an entry need?
An entry can be read without asking anyone if it contains these details:
| Field | Content | Why it matters |
|---|---|---|
| Who | unique user or system ID | no identifiable person stands behind a shared account |
| What | action: create, change, delete, approve, and for sensitive data also view | no statement without an action |
| On what | affected object with a unique ID | the entry must be traceable to the record |
| When | timestamp from a synchronised time source | otherwise order and deadlines cannot be shown |
| Before and after | old and new value | without the old value the original content cannot be determined |
| Why | reason, where the procedure requires one | for critical changes, auditors ask for the trigger |
| Context | system, source, result of the action | failed attempts are relevant too |
Fictional example: "14/10/2026 09:42:17 CEST, user m.keller, supplier master record 70412, IBAN field changed from '…2051' to '…3000', reason: ticket 4711 with call-back note, result: saved." Name, IDs and values are invented for illustration.
Which rules require an audit trail?
Several sets of rules require an audit trail in substance, even if not all of them use the term:
| Source | Applies to | Core requirement in our own words |
|---|---|---|
| ISO/IEC 27001:2022 Annex A 8.15 | organisations with an ISMS under ISO/IEC 27001 | logging; Annex A 8.17 adds clock synchronisation |
| Article 12 of Delegated Regulation (EU) 2024/1774 | financial entities in the regular ICT risk management framework under DORA | logging procedures covering events to log, retention period, protection against tampering, deletion and unauthorised access, detection of failures and synchronised clocks |
| § 146(4) of the German Fiscal Code (AO), § 239(3) of the German Commercial Code (HGB) | anyone obliged to keep books and records | the original content must remain determinable; it must also be clear whether a change was made originally or later |
| 21 CFR Part 11, § 11.10(e) (USA) | companies keeping electronic records under FDA rules | secure, computer-generated, time-stamped audit trails, retained at least as long as the records themselves |
The GDPR has no audit trail of that name. An audit trail does contain personal data as soon as it attributes actions to a person, so define its purpose, access and deletion as carefully as what it records.
What does DORA require for logging?
DORA regulates logging in Article 12 of Delegated Regulation (EU) 2024/1774. Under paragraph 2(c), financial entities log events relating to logical and physical access control and identity management, capacity management, change management, ICT operations and network traffic. The financial entity sets the retention period itself, taking into account business and security objectives, the reason for logging the event and the results of the ICT risk assessment.
How the technical standards under DORA are structured is covered in DORA RTS: what the technical standards require.
What do the AO and HGB require?
Under § 146(4) AO and § 239(3) HGB, a booking or record must not be altered in a way that makes the original content no longer determinable. Changes that leave it uncertain whether they were made originally or later are also not permitted. In an IT system, an audit trail that records the old value and a reliable timestamp shows both.
How this applies to IT-based bookkeeping is set out in the German GoBD (Federal Ministry of Finance letter of 28 November 2019, amended on 11 March 2024 and 14 July 2025).
Technical audit trail and management system audit trail
An ISMS audit looks at two levels. The technical audit trail sits in operating systems, databases and business applications: privileged access, configuration changes, granting of rights. It can be brought together in a SIEM.
The management system audit trail shows who assessed a requirement and when, with what audit evidence, who accepted a residual risk and when management was informed. If it is kept in spreadsheets and emails, it can only be reconstructed with effort for a past audit period.
Testing the audit trail: three samples
An audit trail has evidential value if it also covers the paths by which data can be changed around the log. Test in a test environment or with a test record:
| Sample | Action | Expected result | Evidence |
|---|---|---|---|
| normal change | test user changes a field of a test record | entry with ID, old and new value and a timestamp that matches the reference time | extract of the entry and time comparison |
| privileged change | administrator tries to switch off logging or delete an entry | the action is refused or is itself logged and triggers an alert to a second person | access concept, alert, log entry |
| export and re-import | data is exported, changed outside and imported again | the re-import appears with user, time and the changed values | re-import entry with field values |
Also check three conditions: no account with write access stands for a group rather than a person. Master data is versioned, not overwritten, so older documents keep their original content. Reviewing the audit trail has a fixed cycle and a responsible person. How changes are approved before they reach the audit trail is covered in change management.
The requirements audit trail in Rizzqo
Rizzqo models the part of the audit trail that concerns requirements: who answered and finalised them, and when. Requirements appear on supporting assets by category and subcategory, so the logging requirement from the ISO/IEC 27002 catalogue appears on the systems it applies to. An assigned owner answers it, can attach evidence and finalises the answer with name and timestamp.
Rizzqo computes coverage from the finalised answers; an answer finalised as "not fulfilled" is a gap. Daily snapshots record coverage, so its history over an audit period can be shown. Measures run as tasks with a planned risk reduction that sync both ways with Jira.