Compliance
Dejan MurkoAudit Trail Example: An Annotated Record, Field by Field
At a glance
- An audit trail answers four questions for every change to a record: who, what, when, and (in regulated settings) why. This page shows a real annotated example rather than just defining the term.
- The core fields are user ID, timestamp, action, the record and field changed, the old value, the new value, and the reason for change. Read one row and you can read any audit trail.
- A general database audit log and a regulated (Part 11, clinical, healthcare) audit trail diverge on a few non-negotiables: the regulated one must be secure, computer-generated, time-stamped, attributable, and must not let changes obscure what was there before.
- The reason-for-change field is what most general logs omit and regulated ones require, and it is where inspections often turn.
- Audit trails matter because they make data integrity demonstrable: accountability, investigations, and inspection-readiness all rest on them.
Most “what is an audit trail” pages stay abstract: they tell you an audit trail “includes” who and when, then move on, often using finance receipts or login logs as examples and never showing a real regulated record. This page does the opposite. It hands you a single annotated audit-trail record, walks every field, and uses that one artifact to explain what a general database audit log carries versus what a regulated (FDA Part 11, clinical, healthcare) one must.
It is about the audit-trail mechanism and the example, not the broader rules around it. For the full 21 CFR Part 11 rule see the Part 11 explainer; for the data-integrity principles themselves see the ALCOA guide; for validation see the CSV guides. Here, the annotated example does the heavy lifting.
What is an audit trail?
An audit trail is a secure, chronological record of changes to data: for each change, it captures who made it, what changed, when, and, in regulated contexts, why. It lets someone reconstruct the history of a record long after the fact. The FDA’s data-integrity guidance puts it precisely: an audit trail is a secure, computer-generated, time-stamped electronic record that allows for reconstruction of the course of events relating to the creation, modification, or deletion of an electronic record (Data Integrity and CGMP Q&A). That reconstruction property is the whole point.
An annotated audit trail example
Here is a single change event as an audit-trail row, then the same event annotated field by field.
| Field | Value |
|---|---|
| Audit ID | A-100482 |
| User ID | jsmith (Jane Smith, CRC, Site 04) |
| Timestamp | 2026-03-14 09:42:17 UTC |
| Action | Modify |
| Record | Subject 04-017, Visit 3 |
| Field changed | Systolic BP |
| Old value | 138 |
| New value | 158 |
| Reason for change | Transcription error corrected against source |
The fields, line by line
- Audit ID uniquely identifies the audit entry itself, so the event can be referenced and is itself tamper-evident.
- User ID records who made the change, tied to a specific authenticated individual (not a shared login). This is attribution, the heart of an audit trail.
- Timestamp records when, with date and time (and ideally time zone). It must be system-generated, not user-entered, so it cannot be back-dated.
- Action records what kind of change: create, modify, or delete. These three are the events a regulated audit trail must capture.
- Record identifies which record was touched (here, a specific subject’s visit), so the change is locatable.
- Field changed narrows to the specific data point.
- Old value and New value together show what changed. Critically, the old value is preserved: the audit trail does not erase 138 when it records 158. This is the “do not obscure previously recorded information” property.
- Reason for change records why. For a modification to existing data, a regulated audit trail expects a reason; here, a transcription error corrected against source.
Reading a single change event end to end
The row above reads as a complete story: at 09:42 UTC on 14 March 2026, Jane Smith (an authenticated CRC at Site 04) corrected Subject 04-017’s Visit 3 systolic blood pressure from 138 to 158, because the original entry was a transcription error and the source document showed 158. An inspector reading that row can see who, what, when, the before and after, and the justification, without asking a single question. That is what a good audit trail delivers: a self-explanatory, reconstructable history.
What an audit trail must capture (the requirements)
Not all audit trails carry the same obligations. The fields above are the union; what is mandatory depends on context.
General / database audit trails
A general-purpose database audit log typically records who did what and when (user, action, timestamp, and often old and new values) for security, debugging, and accountability. There is no universal legal mandate on its fields; it captures what the system designers chose. A login log or a change history in a business application is this kind of audit trail. It may or may not preserve old values, and it usually has no reason-for-change field.
Regulated audit trails: FDA Part 11, clinical trials, healthcare
A regulated audit trail is held to specific, non-optional properties. Under 21 CFR Part 11, the audit trail must be secure, computer-generated, and time-stamped, must independently record the date, time, and author of entries that create, modify, or delete records, must not obscure previously recorded information, and must be retained at least as long as the underlying record and available to the agency (§ 11.10(e)). The data-integrity guidance reinforces the operator’s questions behind this: is each action attributable to a specific individual, can only authorized individuals make changes, is there a record of changes, and are records reviewed (Data Integrity and CGMP Q&A). The MHRA data-integrity guidance frames the same expectation through the data lifecycle: records must be complete, consistent, enduring, and available, with the integrity of the data maintained throughout (Data Integrity Guidance and Definitions). In a clinical or healthcare setting, those same properties apply to records of patient and trial data.
The practical upshot: a regulated audit trail must be attributable (tied to one authenticated person), time-stamped by the system, non-obscuring (old values preserved), secure (users cannot disable or edit it), and typically must carry a reason for change on modifications.
Audit trail in a database vs. a regulated audit trail (where they diverge)
| Property | General database log | Regulated (Part 11) audit trail |
|---|---|---|
| Who / what / when | Usually | Required, attributable to one person |
| Old value preserved | Sometimes | Required (must not obscure prior data) |
| Reason for change | Rarely | Expected on modifications |
| System-generated, secure | Varies | Required; users cannot disable or edit |
| Retention tied to record | Not necessarily | Required, as long as the record |
| Reviewed | Optional | Expected (unreviewed trails are a common finding) |
The divergence is not that a regulated trail has more fields for their own sake; it is that integrity, attribution, and reviewability are mandatory rather than optional. A general log that simply records changes is not automatically a Part 11 audit trail.
Why audit trails matter
An audit trail is how data integrity stops being a claim and becomes demonstrable. It provides accountability (every change traces to a person), it enables investigations (you can reconstruct what happened when a result looks wrong), and it underpins inspection-readiness (an inspector can verify the history of a record). When an audit trail is missing, disabled, or never reviewed, the data above it cannot be fully trusted, which is exactly why “audit trails that are never reviewed” is a recurring inspection finding.
What to look for in audit trail software
When evaluating whether a system produces a compliant audit trail, check that it is:
- Automatic and system-generated, not a manual log a user maintains.
- Secure and tamper-evident, so users cannot disable, edit, or delete entries.
- Attributable, tied to authenticated individual users, never shared accounts.
- Non-obscuring, preserving old values alongside new.
- Reason-capturing, prompting for a reason on changes to existing data.
- Exportable and reviewable, so it can be reviewed and produced for inspection.
Purpose-built clinical software typically maintains an audit trail of this kind as a matter of course. TrialTrack, for example, is a clinical project management tool whose vendor describes it as maintaining a Part 11-aligned audit trail of who changed what and when; that is TrialTrack’s own claim about its capabilities, and as always no tool makes a team compliant on its own. Evaluate any system against the properties above, not the badge.
Frequently asked questions
What does an audit trail look like? A chronological set of change records, each capturing who, what, when, the old and new values, and (in regulated settings) why, like the annotated row above.
What information must an audit trail capture? At minimum the user, timestamp, action, and what changed. A regulated audit trail must also be attributable, preserve old values, carry a reason for change, be system-generated and secure, and be retained as long as the record.
What are FDA / Part 11 audit trail requirements? Secure, computer-generated, time-stamped trails that independently record the author, date, and time of create/modify/delete actions, do not obscure prior information, are retained as long as the record, and are available to the agency (§ 11.10(e)).
What is the difference between a database audit trail and a regulated one? A general database log records changes for accountability with no universal mandate. A regulated audit trail must be attributable, non-obscuring, secure, reason-capturing, retained, and reviewed, those properties are required, not optional.
Why are audit trails important? They make data integrity demonstrable, supporting accountability, investigations, and inspection-readiness. Data without a trustworthy audit trail cannot be fully relied upon.
The bottom line
An audit trail is the who-what-when-why history of a record, and the fastest way to understand one is to read an annotated example: user, timestamp, action, record, field, old value, new value, reason. A general database log captures some of this; a regulated Part 11 audit trail must be attributable, system-generated, secure, non-obscuring, retained, and reviewed. Hold any system to those properties, and you will know whether its audit trail would survive an inspection.
Sources
Dejan Murko
Dejan is the co-founder of Mayet, building software for biotech and pharma teams.