Audit Trail: Keeping Changes and Interventions Traceable

What an audit trail means

The MHRA describes an audit trail as the reconstructable history of electronic records. A change must not obscure or overwrite earlier information.^[1]

An audit trail is therefore more than a long list of technical messages. Its purpose is to preserve the history of a record relevant to review in an understandable form. A reviewer must be able to identify the original value, the new value entered, the identity that performed the action, and how the change relates to the operational process. This reconstruction is an important component of data integrity.

The MHRA and FDA apply the term to the creation as well as the modification and deletion of electronic records. PIC/S specifies details including identity, action, old and new values, time, reason for the change and, where applicable, the person authorizing it.^[2][3]

42.6 becomes 24.6: What must the review establish?

The following fictional example concerns a temperature record. The value entered was 42.6 °C, later corrected to 24.6 °C. The reason states only “typing error.” Both values are visible. This makes the change apparent, but does not yet explain it adequately.

The reviewer needs the link to the specific measurement and the underlying equipment record. If that record confirms 24.6 °C, it can support the explanation of a transcription error. The identity and authority of the person making the correction, the chronological sequence, and the use of the old value still need to be checked.

If 42.6 °C has already triggered a subsequent decision, that decision requires a separate assessment. A correct new value does not automatically resolve the effects of the earlier record. If the equipment record is missing, the remaining uncertainty must stay visible; the stated reason for the correction cannot replace it.

The review records which documents were checked, whether the correction is traceable, and which follow-up review remains open. This produces three distinct statements: the change occurred; its justification was assessed; and its possible effects were addressed or explicitly left open.

Recording alone is not enough: Audit trails must be reviewed

An audit trail can be complete yet ineffective in practice. If no one reviews relevant entries, the codes displayed are incomprehensible, or critical changes are hidden in an unstructured list, there is no effective control.

The review should be linked to the associated record and the operational process. For critical records, it may be required before completion, release, or a batch decision. For less critical operations, a predefined periodic review may be appropriate. PIC/S accordingly distinguishes between critical audit trails, reviewed together with the record before completion or release, and noncritical audit trails with a defined review frequency.^[2]

The FDA generally assigns responsibility to the people who also review the respective record. Where no specific review frequency is prescribed, it should be determined on a risk basis, considering data criticality, control mechanisms, and the potential impact on product quality.^[3]

An audit trail review should therefore answer at least the following questions:

• Were there relevant changes, deletions, or repeated entries?
• Are the old and new states and the reason for the change understandable?
• Was the person performing the action authorized to do so?
• Does the chronological sequence match the actual process?
• Was a required review or approval carried out?
• Do patterns suggest a systemic problem?

The review result also needs a documented identity, a date, and a traceable decision. Otherwise, the change will be visible later, but its substantive assessment will not. When selecting compliance software, this reviewability can be demonstrated: from the change entry through its evidence to the documented assessment and any follow-up review still open.

What information is needed for reconstruction

A useful audit trail entry must contain more than a timestamp and the word “changed.” The information required depends on the data type, process risk, and regulatory framework. A relevant data change typically requires the following elements together:

• Identity: the uniquely attributable person or technical instance that performed an action,
• Action: creating, recording, changing, confirming, deleting, releasing, or another relevant action,
• Affected object: for example, a measurement value, review decision, document, material transaction, or batch state,
• Old and new content: where a change was made,
• Time: date and time on a traceable time basis,
• Reason: a justification understandable in its operational context, where the operation requires one,
• Authorization: the identity performing the review or granting approval, where a controlled process requires it.

These details must not exist in isolation. An old and a new value without a link to the affected measurement point remain ambiguous. A user identifier without role and permission context says little about whether the action was permitted. A reason such as “correction” is formally present, but does not explain which error was corrected.

The system must therefore preserve not only individual fields but also their relationships: to the record, task, batch, specification used, responsible role, and, where applicable, a review or release. Only this context turns logged data into an understandable history.

The correction must not make the original disappear

Incorrect entries must remain correctable. A controlled correction does not conflict with record integrity. It becomes problematic when the original state can no longer be identified, a change lacks an identity, or someone can retrospectively clean up the history.

The central requirement is therefore not “data must never be changed,” but that relevant changes must be traceable while the previous information is preserved. For closed systems, the FDA states that changes must not obscure previously recorded information; the audit trail retention period is tied to the associated electronic records.^[5]

In practice, this may mean that a measurement value is not directly overwritten. Instead, a new version or correction operation links the old value, new value, reason, person performing the action, and any required review. The current display may highlight the approved value. It must still provide a traceable route to the earlier record.

This principle also appears in ALCOA+: records should, among other things, be attributable, contemporaneous, original, accurate, complete, consistent, enduring, and available. An audit trail supports several of these properties. It does not replace the other controls.

Identity and permissions belong together

“Who” requires a unique identity. Shared accounts, passed-on credentials, or system identifiers that can no longer be attributed retrospectively weaken an audit trail's evidential value. This remains true even if all changes were fully logged at a technical level.

Roles and permissions determine who may enter, correct, review, release, or administer data. Ordinary users should not be able to disable audit trail functions or alter or delete existing entries. Actions by administrators must themselves be recorded. The MHRA and PIC/S explicitly emphasize this separation.^[1][2]

Protecting only a particularly powerful administrator account is not enough. Granting, changing, and revoking permissions are themselves relevant actions. Annex 11 requires the creation, change, and cancellation of access authorizations to be recorded. The system should also record the identity of people who enter, change, confirm, or delete data, including the date and time.^[4]

A unique user identifier nevertheless does not prove that the right person actually acted or that the decision was correct in substance. Authentication, organizational accountability, training, the role model, and substantive review must work together.

Time, sequence, and granularity must fit the operation

A change history is reliable only if its chronological order is reliable. Dates and times should be generated automatically and must not be arbitrarily adjustable by ordinary users. In distributed systems, the time zone or common time basis used by the entries must also be clear.

PIC/S calls for timely recording and a level of granularity that allows relevant events to be distinguished.^[2] A daily summary entry is insufficient, for example, when several changes to a critical test value must be assessed in their actual sequence.

Conversely, extremely detailed technical logging does not automatically provide greater operational value. If every mouse movement, screen access, and internal database operation appears equally important, relevant actions may disappear in a mass of meaningless entries. The granularity must therefore represent the operation relevant to review.

In a batch process, it may be sufficient to record the start and completion of a guided task, entered results, corrections, review decisions, and releases separately. Within an automated measurement, calibration status, links to raw data, calculation steps, and subsequent parameter changes may instead be relevant.

A reviewable history needs an understandable presentation

Audit trail data is often stored in tables whose technical field names are difficult for domain users to understand. An effective presentation translates this structure into its operational context: affected batch, task, record, old and new values, acting role, time, reason, and review status.

PIC/S requires a meaningful format and the ability to provide audit trails as a printout or electronic copy. Search and export functions should be retained where possible.^[2] Annex 11 also requires a generally intelligible form and regular review of relevant logs.^[4]

A PDF alone may be sufficient for a specific review, but may lose filters, relationships, or dynamic metadata. An export is therefore a suitable copy only if it preserves the content, meaning, and necessary context.

Exception reports can make large volumes of data manageable. They must not, however, act as an opaque filter. The rules used to highlight or hide entries must be validated, documented, and proportionate to the risk. Reviewers also need a route to the complete underlying data.

Audit trails, system logs, and process histories are not the same

Digital systems generate different kinds of history. Their terms are often conflated, even though they answer different questions.

• Audit trail: Which relevant record was created or changed, by whom, when, how, and for what reason?
• System log: Which technical or security-related operations occurred in the system, such as a login, service startup, error, or configuration change?
• Process history: Which operational tasks, states, checks, and decisions formed the actual process?
• Event log: Which structured event data is available for process analysis?
• Change control: How is a planned change to a system, process, or configuration assessed, approved, and implemented?

These perspectives overlap. A release can be part of the process history, an audit trail entry, and an event for later analysis. Nevertheless, their purposes, required information, and retention logic differ.

An audit trail documents changes to records; it does not replace a procedure for controlled changes to a system. Annex 11 distinguishes these tasks: Section 9 addresses audit trails; Section 10 requires changes to computerized systems, including their configuration, to follow a controlled approach under a defined procedure.^[4] Likewise, a technical system log should not be presented as an operational audit trail without review. A successful login, for example, does not explain which measurement value was subsequently changed.

An event history needs additional review information

Event sourcing can derive a current state from stored events. Whether those events also form a suitable audit trail depends on their content and design: are old and new information, identity, required reasons, and the review context available?

Reconstructing today's numerical value does not yet explain why a correction was permissible. Data provenance can provide additional relationships describing how the data originated. For review, these relationships and the change records must be accessible in an understandable context.

Regulatory finding

Finding: The FDA cited changes to electronic batch records that a quality assurance employee had instructed the software vendor to make. One change replaced an employee identification number. This change was neither captured in the audit trail nor noted in the electronic batch record.^[6]

Assessment: Corrections made on request must also remain traceable. The change history must include interventions by vendors and support personnel, regardless of who requests them.

Review question: Can vendors or support personnel change data without the change appearing in the audit trail?

Letter dated 30 March 2026 · Source checked on 18 September 2026.

This section presents the selected regulatory finding as stated at the time of the letter. Company responses and subsequent developments are not assessed here; this account does not describe the company’s current compliance status.

A visible correction is the beginning of the review

The change from 42.6 to 24.6 can be displayed without any technical gaps and still remain unresolved in substance. Only the supporting records and the documented review show how the change was assessed.

A useful audit trail therefore leads from the current record to its history and to open questions. It supports review; it must not prejudge the outcome merely because a log is complete.

An audit trail does not create automatic compliance. Requirements and review intervals depend on the use, risk, and applicable regulatory framework.

For automated compliance evidence, the required information must be connected during execution so that it supports a verifiable statement about the specific operation.