In every audit, there comes a moment when the auditor singles out a specific change and asks: Who made this change, when, and why? Companies that can answer this question in a matter of minutes pass the audit. Companies that take days to answer or have no answer at all are issued a nonconformity.
The difference lies in a robust audit trail. Not a log file, not an Excel list with change notes, but an immutable, complete record that documents every change requiring verification, including the timestamp, user, and reason.
This article explains what an audit trail must specifically accomplish in manufacturing: the six mandatory fields, standard requirements ranging from IATF to FDA to GoBD, why immutability is the most critical and important characteristic, a maturity model for self-assessment, and a five-step path to an audit-proof audit trail.
Key Points at a Glance
|
In a nutshell
|
What an audit trail is and how it differs from a log file
An audit trail is a chronological, immutable record of all changes to a dataset that must be documented. It records not what a system did technically, but rather what business decision a user made—including the value before the change, the value after the change, and the reason for it.
This is precisely where the distinction from a log file lies. A log file is an operational log: It records logins, system errors, accesses, and reboots; it serves technical operations and is rotated and deleted after a certain period. An audit trail, on the other hand, is a verification tool. It must be immutable, retained for the full retention period, and provide business context that a log file simply does not offer.
Confusing the two is a common and costly mistake. Anyone who submits a log file as an audit trail record during an audit usually has timestamps and user information, but neither the previous value nor the reason for the change—and thus no reliable evidence.
| Characteristic | Log File | Audit Trail |
|---|---|---|
| Purpose | Technical operation of the application | Providing evidence to auditors |
| Content | System events, errors, accesses | Business changes with context |
| Previous value | Not included | Required component |
| Reason for change | Not included | Required component |
| Modifiability | Rotation and deletion are common | Immutable, additive correction |
| Retention | Short retention period, then deleted | Full statutory retention period |
The Six Required Elements of a Robust Audit Trail
An audit trail entry is only as good as its completeness. Six fields are considered mandatory. If one is missing, the documented change cannot be fully traced in the audit—and the auditor will consider this a gap.
The following four cards group the six fields into their respective functional categories. The “Object” field, along with the “Old Value” and “New Value” fields, together form the core content and are therefore included on a single card.
| Required Field 01 | What the field does: Timestamp |
| Date, time, and time zone of each event—synchronized against a reliable time source to ensure consistent chronology across systems. | |
|
Requirements
|
Evaluation → Without a reliable time, there is no chronology → Client time can be manipulated—never use it → Basis for every sequence of events |
| Audit Focus: Audit question: Where does the time come from, and can it be manipulated? | |
| Required Field 02 | What the field does: User identity |
| The unique identity of the user or system that triggered the event—specific to an individual, not a collective or functional account. | |
|
Requirements
|
Evaluation → Collective accounts render assignment meaningless → Assignment must be specific to an individual → Even automated changes require an identity |
| Audit Focus: Audit Question: Can a change be assigned to a real person? | |
| Required Field 03 | What the field does Affected object and values |
| The modified object as well as the old and new values—the actual substantive content of the entry. | |
|
Requirements
|
Evaluation → Without a "Before" value, true traceability is not possible → Old and new values must always be paired → Object reference makes the entry traceable |
| Audit Focus: Audit question: Is it clear what specifically has changed? | |
| Required Field 04 | What the field does: Reason for change |
| The business reason for the change—required for manual changes; for automated changes, it serves as a system or process identifier. | |
|
Requirements
|
Rating → The reason distinguishes the entry from the log file → Makes the intent clear → Most common gap in practice |
| Audit Focus: Audit Question: Is it clear why the change was made? | |
Which standards require an audit trail
Hardly any standard uses the term “audit trail” verbatim, but many require its essence: a traceable, time-stamped, user-identified, and tamper-proof record of changes. IATF 16949 Section 7.5.3 governs the control of documented information for the automotive industry. FDA 21 CFR Part 11 specifies this requirement for electronic records. EU GMP Annex 11 applies it to pharmaceutical manufacturing.
| Regulatory Framework | Reference | Scope | Core Requirement |
|---|---|---|---|
| IATF 16949 | Section 7.5.3 | Automotive | Control of Documented Information, Change Tracking |
| 21 CFR Part 11 | § 11.10 (e) | FDA / Pharmaceutical | Computer-generated, time-stamped audit trail |
| EU GMP Annex 11 | Section 9 | Pharmaceuticals | Audit trail for GMP-relevant data |
| GoBD | Rz. 58 ff. | Tax Law | Immutability and Traceability |
| ISO 9001 | Section 7.5 | Across All Industries | Control of Documented Information |
The common denominator is remarkably consistent: Whether in the automotive, pharmaceutical, or tax law sectors—there is always a requirement that changes be traceable, time-stamped, attributed to specific individuals, and recorded in an unalterable manner. A company that technically ensures these four characteristics simultaneously meets the audit trail requirements of virtually all relevant regulations.
What additional requirements are specified by customers
Beyond the standards, many OEMs impose their own requirements for documentation, known as Customer-Specific Requirements. These often go beyond the text of the standards, such as regarding the retention period for safety-critical parts or the required level of detail for traceability. Review these requirements early on, as they determine what data—and to what level of detail—must be included in the audit trail.
Why Immutability Is the Toughest Requirement
Of all the characteristics of an audit trail, immutability is the most important—and at the same time, the most difficult to achieve. The reason is simple: The entire evidential value of an audit trail depends on the fact that its entries cannot be altered retroactively. An editable audit trail proves nothing, because any entry could have been altered after the fact.
Auditors know this and specifically test for it. They don’t just ask whether an audit trail exists, but whether an entry can be deleted or overwritten—even by the administrator, if necessary. If they find a single record that can be altered, they cast doubt on the credibility of the entire system.
|
The Most Common Mistake: Correcting by Overwriting An incorrect entry is never overwritten. Corrections are made exclusively by adding new entries: A new entry corrects the old one and references it, while the original remains visible. No user or administrator may have write access to existing audit trail entries. Write protection must be enforced at the system level, not through a company policy. The deletion of entire entries must also be prevented. An administrator who can clear the audit trail technically undermines its evidential value. Read access itself is logged. Anyone who views the record leaves a trace. |
Typical gaps that stand out in the audit
Most audit trail findings follow a predictable pattern. These are rarely exotic special cases; rather, they are consistently the same four vulnerabilities. The following comparison shows each of them in terms of their vulnerable and secure states.
| Vulnerability 1: Who made the change? | |
|
✗ Vulnerable in the audit “Production” pool account as the user Multiple workers share a single login. A change cannot be attributed to any specific person—the user identity is meaningless. |
✓ Valid in an audit Individual user login for each worker Every change is assigned a unique user ID. The auditor can trace every action back to a specific person. |
| Why it matters: Eliminate collective accounts; technically enforce individual logins | |
| Gap 2: Why was it changed? | |
|
✗ Vulnerable during an audit Reason for change is optional or empty The “Reason” field exists but can be skipped. In practice, it almost always remains empty—the intent behind the change is lost. |
✓ Auditable Reason for change as a required field The change cannot be saved without specifying a reason. The business context is permanently preserved. |
| Why it matters: Configure “Reason for Change” as a required field that cannot be skipped | |
| Gap 3: What was the previous value? | |
|
✗ Vulnerable in an audit Only the new value is recorded; no previous value The entry shows the state after the change, but not the state before it. It is impossible to truly trace the change. |
✓ Audit-proof Old and new values recorded for every change Each entry shows both states. It’s clear at a glance exactly what has changed. |
| Why it matters: Record the previous value with every change | |
| Gap 4: Can it be changed retroactively? | |
|
✗ Vulnerable in an audit Entries can be edited via database access An administrator can modify or delete entries directly in the database. This renders the entire audit trail invalid as evidence. |
✓ Reliable for auditing Write protection at the system level, additive correction No account has write access to existing entries. Corrections are made only through new, referenced entries. |
| Why it matters: Enforce immutability technically, not through organizational controls | |
It is striking that none of these gaps can be closed by simply putting more effort into the audit itself. They all arise within the system and in the process leading up to it. If you don’t notice them until the auditor is on site, you can no longer fix them—the affected entries have already been created.
An audit trail cannot be repaired retroactively. Either it is complete and immutable from the start, or it is worthless at the crucial moment.
— Amadeus Lederle, Chief Technology Executive, CSP Intelligence GmbH
Maturity Model: How Robust Is Your Audit Trail?
Before investing in an audit-proof audit trail, you should understand your current situation. The maturity model classifies organizations based on the robustness of their record-keeping—ranging from paper documentation to cross-system integrated data capture.
| Level 1: Paper | Level 2: Editable | Level 3: Immutable | Level 4: Integrated |
|---|---|---|---|
|
Data Status Changes documented by hand or not at all. No previous value recorded. |
Data Status Recorded electronically, but can be modified retroactively (Excel, unspecified database tables). |
Data Status System-generated records with all six required fields, protected against modification. |
Data Status Consistent traceability across MES, ERP, and QMS based on a shared database, organized by serial number. |
|
Documentation No reliable audit trail. Vulnerable to audit scrutiny. |
Documentation Mapping is possible, but data integrity is not guaranteed. |
Documentation Complete audit trail from the time of capitalization. Audit-proof. |
Traceability The chain of events from goods receipt to shipment can be reconstructed. |
|
Next Step Implement electronic recording of data subject to change |
Next Step Technically enforce write protection on existing entries |
Next step Consistently link records across system boundaries |
Next step Implement automatic anomaly detection on the recordings |
The Five-Step Path to a Seamless Audit Trail
An audit-proof audit trail isn’t created by a single tool, but through five steps that build on one another. The first step clarifies what should be included, and the last ensures that you can provide the necessary information during an audit in a matter of minutes.
| Step 1 | Identify Data Subject to Documentation Goal: Know exactly what needs to be included in the record | |
|
Tasks
|
Result Catalog of data types subject to audit trail requirements |
|
| Step 2 |
Ensure the six required fields are | : Goal—every entry is complete and enforced automatically | |
|
Tasks
|
Result Complete field structure with no skippable fields |
||
| Step 3 | Technically enforce immutability Goal: No write access to existing entries—for anyone | |
|
Tasks
|
Result Technically immutable record |
|
| Step 4 | Ensure retention and readability Goal: Preserved and analyzable throughout the entire retention period | |
|
Tasks
|
Result Long-term, readable records |
|
| Step 5 | Establish audit readiness Goal: Be able to provide information during an audit in minutes rather than days | |
|
Tasks
|
Result A verifiable, complete chain of evidence, documented down to the minute |
|
CSP: Audit trail as a byproduct of production
|
Practical Tip CSP does not generate the audit trail as a separate step, but rather as a byproduct of the ongoing production process. Every change to a record subject to documentation requirements is recorded with all six required fields, protected against modification, and linked via the serial number as a unique primary key.
|
Frequently Asked Questions
What is the difference between an audit trail and a log file?
A log file records technical system events: logins, errors, accesses, and reboots. It is focused on application operations and is typically rotated and deleted after a specified period. An audit trail, on the other hand, documents business-relevant changes to data subject to audit requirements—including the old value, new value, user identity, and reason for the change. It is designed for audit purposes, must be immutable, and must be retained for the legally required retention period. A log file answers the question of what the system did. An audit trail answers who made a decision and why.
What fields must an audit trail entry contain?
A reliable entry requires six fields: first, a timestamp with date, time, and time zone, ideally synchronized with a reliable time source. Second, the unique identity of the user or system that triggered the action. Third, the affected object, such as a data record, field, or serial number. Fourth, the old value before the change. Fifth, the new value after the change. Sixth, the reason for the change. For automated changes, a system or process identifier replaces the human-provided reason. If any of these fields is missing, the change cannot be fully traced in the audit.
Which standards require an audit trail in manufacturing?
Several regulatory frameworks require traceability of changes, sometimes under different names. IATF 16949 requires, in Section 7.5.3, the traceability of changes—specifically, the control of documented information, including change tracking. FDA Rule 21 CFR Part 11 requires a computer-generated, time-stamped change history for electronic records. EU GMP Annex 11 requires the same for pharmaceutical manufacturing, while ISO 9001 addresses this across all industries. The GoBD requires that tax-relevant data be immutable and traceable. Despite differences in wording, the common core is identical: traceable, time-stamped, user-specific, and immutable.
Why must an audit trail be immutable?
Because its entire evidential value depends on its immutability. A record that can be edited retroactively proves nothing—since any entry could have been altered after the fact. Auditors therefore specifically check whether entries can be deleted or edited. If even a single record can be altered, the entire record loses its evidential value. Corrections must therefore always be made additively: An incorrect entry is not overwritten, but corrected by a new entry that references the original. This ensures that the complete history remains visible.
Is an audit trail in Excel or on paper sufficient?
This is usually not sufficient for reliable evidence. An Excel file can be edited at any time without leaving a trace, and a paper log can be added to or replaced retroactively. Neither meets the requirement of immutability. Excel may suffice as a temporary solution for internal initial documentation, but not for an audit-proof system. A record is only legally valid if it is protected against modification by the system, each entry is created automatically, and the association with the user and the time is technically enforced.
How long must an audit trail be retained?
The retention period is determined by the underlying retention requirement for the documented data, not by the audit trail itself. In the automotive supply industry, 15 years is standard depending on the customer and component; safety-critical parts may require longer retention periods. Tax-related data is subject to a ten-year retention period under the German Tax Code. In medical technology, the retention period is based on the product’s service life plus a surcharge. The key point is this: The record must be retained for at least as long as the data whose changes it documents—and must remain unaltered and legible throughout this entire period.
Can an audit trail be implemented retroactively?
Yes, for future events; no, for past ones. Such a record documents changes starting from the date of its activation. Events that occurred prior to its implementation cannot be reconstructed because the necessary baseline values and reasons for changes were not recorded. Therefore, implementation always marks a cutoff point: From the effective date onward, the audit trail is complete; prior to that, it is limited to what was already documented. The earlier the audit trail is activated, the more complete the subsequent audit trail will be. The sooner, the better.
Who is authorized to view an audit trail?
Read access should be governed by a role-based access control model. Auditors, quality management, and compliance need full read access, while functional departments require access limited to their specific area. A clear separation of read and modification rights is crucial: No one—absolutely no one—should have write access to existing audit trail entries—not even an administrator. Auditors specifically check for this separation of privileges because an administrator with delete privileges could technically undermine the evidential value of the data. Ideally, access itself is also logged.