Audit Trails, Data Changes and Review Controls

An audit trail is a secure, computer-generated, time-stamped electronic record that allows the sequence of events affecting another electronic record to be reconstructed.

A useful audit trail should show:

what happened;
who performed the action;
when the action occurred;
which record or configuration item was affected;
the original information;
the changed information; and
why the change was made when a reason is required.

Audit trails support accountability and data review, but their existence does not by itself establish data integrity. The system must generate appropriate events, protect them from alteration, retain them with the related records, make them available for review, and support an effective review process.

Audit-trail controls should be based on:

the system’s intended use;
applicable predicate-rule records;
21 CFR Part 11 applicability;
data and metadata criticality;
opportunities to create, change, delete, invalidate, or reprocess records;
configuration and master-data risks;
user privileges;
system capabilities; and
consequences of undetected activity.

Audit-Trail Applicability

Audit-trail applicability should be determined through a documented assessment rather than by assuming that every system event requires identical treatment.

Audit trails are generally expected where a computerized system allows users or technical processes to:

create regulated electronic records;
change or correct regulated data;
delete or invalidate records;
change record status;
reprocess data;
repeat an analysis;
change calculations or processing parameters;
modify specifications or limits;
change master data;
modify security roles;
change configuration affecting regulated functions;
execute electronic signatures;
change system time;
modify audit-trail settings; or
perform other actions affecting the meaning, reliability, or availability of regulated records.

The assessment should identify:

relevant record types;
critical fields and metadata;
functions capable of changing them;
expected audit-trail events;
review requirements;
responsible reviewers;
review timing;
retention requirements; and
known system limitations.

Not every technical log is a GMP audit trail. Operating-system logs, application logs, security logs, database logs, and interface logs may provide supporting evidence, but they may not capture the complete business context required to reconstruct changes to regulated records.

Regulatory Basis

21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify, or delete electronic records.

The regulation also requires that:

record changes do not obscure previously recorded information;
audit-trail documentation be retained at least as long as the associated electronic records; and
audit trails be available for FDA review and copying.

FDA’s Data Integrity and Compliance With Drug CGMP guidance defines an audit trail as a secure, computer-generated, time-stamped electronic record that permits reconstruction of events related to the creation, modification, or deletion of an electronic record.

Part 11 requirements should be interpreted together with the applicable predicate rules. For example, laboratory records must also satisfy 21 CFR 211.194, including complete data derived from testing and documentation of modifications to established methods.

Events the Audit Trail Should Capture

The audit trail should capture events relevant to the reliability and meaning of the regulated record. Depending on the system, these may include:

record creation;
data entry;
data correction;
value modification;
status change;
approval or rejection;
electronic signature;
record invalidation;
deletion attempt;
result reprocessing;
calculation rerun;
repeated analysis;
parameter change;
method change;
report regeneration;
attachment replacement;
configuration change;
master-data change;
user-role change;
audit-trail setting change; and
restoration of archived or backed-up records.

The event design should distinguish normal workflow actions from exceptional activity. For example, approving a completed record is different from changing an approved result, even if both events affect record status.

Complete Audit-Trail Event

A complete event should retain enough information to reconstruct the action without relying on memory or unsupported assumptions. Relevant event elements include:

affected record or object;
field or attribute changed;
action type;
previous value;
new value;
user identity;
date and time;
reason for change;
record version;
workflow status;
source function or module;
associated electronic signature;
system-generated event identifier; and
related transaction or investigation reference.

The old and new values are especially important where a user changes critical data. Recording only that a field was “updated” does not show what changed or allow the reviewer to assess its significance.

Anatomy of a complete audit-trail event showing the affected record, old value, new value, user identity, timestamp, reason for change, source, and event identifier. — A complete audit-trail event preserves the original information, changed information, responsible user, timestamp, reason, and associated record context.

Creation of Records

Record creation should be attributable to the user or technical process responsible for creating it.

The audit trail or associated metadata should identify:

record creator;
creation date and time;
originating system or device;
initial record identifier;
initial status;
source data or transaction;
applied method, template, or configuration; and
relevant relationships to samples, batches, materials, equipment, or other records.

Where records are created automatically, the event should identify the applicable service account, interface, instrument, or system process. The responsible technical process should remain distinguishable from human-user activity.

Data Modification and Correction

Systems should provide controlled methods for correcting data without overwriting the original information.

The correction process should preserve:

the original entry;
the corrected entry;
identity of the person making the correction;
correction date and time;
reason for correction;
record status;
associated approval when required; and
any effect on downstream records or decisions.

Direct database editing, file replacement, or use of administrative tools to bypass the controlled correction function should be prohibited except under exceptional, authorized, and fully documented circumstances.

A data correction is not necessarily a system change-control event. Correcting an individual record under an approved workflow differs from changing the software, configuration, calculation, or master data that governs many records. The relationship with system changes is addressed in Computerized System Change Control, Patching, and Revalidation.

Deletion and Invalidation

Where regulated records may be deleted, the system should preserve sufficient evidence to determine:

what was deleted;
who performed or attempted the deletion;
when it occurred;
why it occurred;
whether authorization was required;
whether related records were affected; and
whether the content can be recovered.

Permanent deletion of regulated records during the required retention period should generally be prevented.

Where an incorrect or unusable record must be removed from active use, controlled invalidation is usually preferable to physical deletion. Invalidation should preserve the original record while clearly identifying:

invalid status;
reason for invalidation;
responsible user;
date and time;
approving person where required; and
replacement or related record.

A deleted result, aborted run, canceled transaction, or voided record may remain relevant to data review and investigation even when it is excluded from the final reported result.

Reprocessing and Repeated Activity

Reprocessing can include:

reintegration;
recalculation;
reanalysis;
re-execution;
reclassification;
rerunning a report;
changing processing parameters;
applying a different method; or
repeating an interface transaction.

The audit trail should permit reviewers to determine:

which original data were used;
which processing method or parameters were applied;
who initiated the reprocessing;
when it occurred;
why it was performed;
what result was generated;
whether earlier results remain available; and
which result was ultimately reported or approved.

Repeated processing should not be concealed merely because the final result is acceptable. Unexpected repetitions, selective reporting, or repeated changes to processing parameters may indicate procedural, technical, training, or data-integrity problems.

Configuration Changes

Configuration changes can alter how the system creates, processes, controls, or reports regulated data. Relevant changes may include:

workflow steps;
status transitions;
role permissions;
audit-trail settings;
electronic-signature settings;
calculation parameters;
report templates;
units and rounding;
interface mappings;
alarm limits;
retention settings;
date and time settings;
record numbering;
enabled modules; and
security configuration.

The audit trail should identify the configuration item, previous setting, new setting, user, date and time, and associated change-control reference where applicable.

Configuration audit trails should be reviewed following significant changes and during periodic review. Where the system cannot provide a meaningful configuration audit trail, controlled configuration baselines and documented comparisons may be required.

Master-Data Changes

Master data control values used repeatedly across transactions or processes. Examples include:

specifications;
methods;
recipes;
product codes;
materials;
units;
sampling plans;
acceptance limits;
equipment lists;
supplier status;
user roles;
lookup tables;
storage conditions; and
reason codes.

Master-data changes may affect many subsequent records. The control should therefore address:

authorized creation and modification;
effective dates;
approval;
version control;
old and new values;
reason for change;
impact on open transactions;
downstream transfer;
testing where required; and
retirement of obsolete values.

The system should prevent unauthorized users from changing master data that control their own work or acceptance decisions.

Metadata

Metadata provide the context needed to understand and reconstruct electronic data. Relevant metadata may include:

user identity;
date and time;
instrument or equipment identity;
method and version;
units;
processing parameters;
calculation settings;
record relationships;
status;
electronic signatures;
audit-trail events; and
file or object identifiers.

The audit trail should remain associated with the related data and metadata throughout retention, archival, migration, and inspection retrieval.

Exporting a final value without its supporting metadata and audit trail may not produce a complete regulated record. The complete-record concept is addressed further in ALCOA+ Data-Integrity Principles and System Controls.

User Identity and Attribution

Audit-trail events should identify the individual user or controlled technical account responsible for the action.

Human users should operate through unique accounts. Shared accounts prevent reliable attribution and should not be used for regulated activities.

Service accounts should identify the automated process involved and should not be used interactively by personnel. Privileged accounts should remain individually attributable where technically possible.

Requirements for unique identities, privileged users, service accounts, and access review are covered in User Access, Privileged Accounts, and Electronic Signatures.

Timestamps and Controlled Time

Audit-trail timestamps should be generated automatically using controlled system time.

Controls should address:

system-clock source;
time synchronization;
authorized time changes;
time-zone configuration;
daylight-saving changes;
display format;
interface timestamps;
cloud-hosting locations;
archived-record interpretation; and
detection of time discrepancies.

Users should not be able to change system time to alter record chronology.

Where systems operate across multiple time zones, the organization should define whether timestamps are stored in Coordinated Universal Time, local time, or another controlled format. Displayed records should provide enough information to interpret the time correctly.

Time changes themselves should be logged and reviewed when they could affect regulated records.

Reasons for Change

A reason for change should be required where the context is not evident from the controlled workflow or where the change could affect the meaning, acceptance, or reliability of the record. Reason controls should avoid vague or meaningless entries such as:

correction;
mistake;
update;
as requested;
other; or
test.

Where predefined reason codes are used, they should:

cover expected situations;
be clearly defined;
require comments when additional explanation is necessary;
be controlled as master data; and
support meaningful trending.

The reason should explain why the change was necessary, not merely repeat that a change occurred.

Audit-Trail Security

Audit trails should be generated independently by the system and protected from user alteration. Security controls should prevent ordinary users from:

disabling the audit trail;
changing which events are captured;
modifying audit-trail entries;
deleting audit-trail records;
changing audit-trail timestamps;
concealing previous values; or
selectively excluding events from retained records.

Administrative capability to modify audit-trail configuration should be strictly limited and monitored. Changes to audit-trail settings should themselves be recorded and controlled.

Audit-trail data should receive appropriate protection through:

access control;
database security;
backup;
restoration testing;
retention;
archival;
cybersecurity controls; and
change control.

Availability and Retention

Audit trails should remain available for at least as long as the associated regulated records. Retention controls should ensure that:

audit trails remain linked to their records;
archived audit trails remain readable;
search and filtering remain functional;
timestamps remain understandable;
user identities remain interpretable;
reasons and old values remain available;
migrations preserve event relationships;
backup and restoration include audit trails; and
audit trails can be provided during inspection.

A screenshot or printout may not be sufficient where it loses filtering, sequence, metadata, or relationships between events.

Retention and archival requirements are addressed further in Electronic Records Lifecycle, Retention, and Archival.

Filtering, Search, and Export

Audit-trail review becomes ineffective when the system presents thousands of undifferentiated technical events without practical search or filtering.

The system should support appropriate filtering by:

date and time;
user;
record;
record type;
field;
event type;
old or new value;
module;
workflow status;
reason code;
configuration item; and
source system or interface.

Search results should remain complete and should not silently omit events because of date limits, pagination, archived partitions, or unsupported filters.

Export functionality should preserve:

record identifiers;
user identities;
timestamps;
event sequence;
action types;
old and new values;
reasons;
metadata relationships; and
evidence that the export is complete.

Exported files should be protected against uncontrolled modification when they are retained as review evidence.

Audit-Trail Review Responsibilities

The procedure should define who reviews audit trails and which qualifications are required. Possible reviewers include:

data reviewer;
record approver;
laboratory reviewer;
production supervisor;
Quality Unit;
system owner;
process owner;
security reviewer; and
investigator.

The person reviewing the audit trail should:

understand the business process;
understand expected system behavior;
recognize significant events;
have access to supporting records;
be sufficiently independent from the activity reviewed;
document the review; and
escalate exceptions.

A reviewer should not merely confirm that an audit-trail report exists. The review must evaluate whether the recorded activity is appropriate and consistent with the applicable process and record.

Routine Record Review

Routine audit-trail review should be integrated with review of the associated regulated record when the audit trail could reveal information affecting its reliability. For critical records, the audit trail should generally be reviewed before the data are relied upon for an important decision, such as:

result approval;
specification approval;
investigation closure;
batch disposition;
product release;
regulatory submission; or
final report approval.

Routine review may focus on:

data changes;
invalidated records;
deleted or aborted activities;
reprocessing;
repeated testing;
changes after approval;
unusual timing;
unauthorized users;
unexplained status changes;
incomplete reasons; and
discrepancies between displayed and underlying records.

The review procedure should define the records and events included rather than instructing users to review “all audit trails” without usable criteria.

Event-Driven Review

Event-driven review is initiated by a specific trigger. Triggers may include:

suspected unauthorized access;
unexpected data changes;
missing records;
audit-trail gaps;
failed interfaces;
unusual repeated processing;
incorrect timestamps;
configuration changes;
disabled controls;
cybersecurity incidents;
complaints;
deviations;
internal-audit findings; or
regulatory observations.

The review scope should follow the event rather than being limited to one record. It may need to include:

affected users;
related records;
connected systems;
configuration history;
master data;
privileged activity;
interface transactions;
backups;
supplier activity; and
earlier comparable events.

Periodic Trend Review

Periodic trending identifies patterns that may not be apparent during individual record review. Trending may evaluate:

frequency of data changes;
users performing unusual numbers of changes;
repeated reason codes;
changes outside normal hours;
invalidated records;
repeated processing;
recurring failed transactions;
configuration changes;
privileged activity;
audit-trail setting changes;
delayed reviews;
recurring exceptions; and
supplier-related limitations.

Trend results should be evaluated with process context. A high number of changes may reflect legitimate process complexity, while a sudden reduction may indicate that changes are no longer being captured or reported.

Significant trends should be entered into the pharmaceutical quality system and may require investigation, CAPA, system remediation, procedure changes, training, or expanded review.

Risk-based audit-trail review model comparing routine record review, event-driven review, and periodic trend review by timing, scope, responsibility, and evidence. — Routine, event-driven, and periodic audit-trail reviews serve different purposes and require defined timing, scope, responsibility, and evidence.

Review Frequency

Review frequency should reflect risk rather than convenience. Factors include:

data criticality;
decision supported by the data;
ability to change or delete records;
user privilege;
detectability of inappropriate activity;
system complexity;
volume of records;
previous findings;
supplier capability;
automated exception detection; and
applicable procedure or regulatory requirement.

The control strategy may combine:

review with each record;
review before approval or release;
daily or shift-based exception review;
review following defined triggers;
periodic review of selected audit trails;
periodic privileged-activity review; and
periodic trending.

Less frequent review requires a documented rationale and should not allow critical problems to remain undetected until after the data have been used.

Review Evidence

Audit-trail review should produce documented evidence. The record should identify:

system;
review scope;
records or date range reviewed;
filters or searches used;
reviewer;
review date;
expected event types;
exceptions found;
assessment of exceptions;
related investigation or deviation;
required actions;
completion status; and
approval where required.

A checkbox stating “audit trail reviewed” may be insufficient when it does not establish what was reviewed or how exceptions were evaluated.

Where the system electronically records review completion, the configured review function should be validated.

Exception Handling

An audit-trail exception is an event requiring evaluation because it differs from expected, authorized, or procedurally acceptable activity. Examples include:

unexplained data change;
deletion attempt;
use of an inappropriate account;
repeated reprocessing;
change after approval;
missing reason;
unusual timestamp;
administrative access to regulated data;
disabled audit trail;
incomplete event history;
unexplained master-data change; or
audit-trail export discrepancy.

The initial assessment should determine:

whether the event is technically or procedurally expected;
significance of the affected data;
whether the record was used in a decision;
immediate containment required;
possible product or patient impact;
whether similar records may be affected; and
whether a formal investigation is required.

Investigation

Significant audit-trail findings should be investigated through the applicable quality-system process. The investigation should reconstruct:

what occurred;
who was involved;
when the activity began;
which records and systems were affected;
whether the activity was intentional or accidental;
why existing controls did not prevent or detect it;
whether reported data remain reliable;
whether product decisions were affected; and
whether the problem is isolated or systemic.

The investigation should consider technical and organizational causes, including:

inappropriate access;
poor role design;
inadequate procedures;
system limitations;
missing training;
workload;
weak supervision;
supplier activity;
interface failures;
configuration errors; and
quality-culture concerns.

Closure should document the impact decision, corrections, CAPA, expanded review, residual risk, and approval.

Audit-trail exception workflow covering detection, triage, investigation, disposition, documented closure, periodic trending, and remediation triggers. — Audit-trail exceptions progress from detection through impact assessment and documented closure, while periodic trending identifies recurring or systemic weaknesses.

Supplier Limitations

Commercial systems may have audit-trail limitations such as:

no audit trail for particular records;
audit trail not enabled by default;
missing old values;
missing reasons for change;
incomplete configuration history;
difficult search;
limited filtering;
unreadable technical terminology;
no practical export;
audit trails stored separately from records;
limited archived-data access;
supplier-only access to logs;
uncontrolled administrator capability; or
inability to record service-account activity clearly.

Supplier claims that a system is “Part 11 compliant” do not replace evaluation of its configured functions and site-specific use.

Limitations should be assessed during:

system selection;
supplier assessment;
requirements definition;
configuration;
risk assessment;
validation;
release;
change control; and
periodic review.

Potential responses include:

selecting a different product;
enabling additional audit-trail functions;
changing configuration;
restricting system use;
adding controlled procedural review;
using supporting logs;
introducing independent reconciliation;
upgrading the system;
formally remediating legacy use; or
replacing the system.

Procedural controls should not be used to justify a critical technical limitation when the procedure cannot reliably prevent or detect the relevant failure.

Validation of Audit-Trail Controls

Validation should verify that audit-trail functionality works for the configured system and intended use. Testing should challenge:

record creation;
data modification;
old and new value capture;
deletion or invalidation;
repeated processing;
reasons for change;
user identity;
timestamp accuracy;
status changes;
electronic signatures;
configuration changes;
master-data changes;
privileged activity;
audit-trail security;
filtering;
searching;
export;
retention;
backup and restoration;
migration; and
archived-record retrieval.

Negative testing should confirm that unauthorized users cannot:

disable the audit trail;
alter audit-trail entries;
delete audit-trail records;
conceal previous values;
modify system time;
perform restricted changes; or
bypass required reasons and approvals.

Validation evidence should be traceable to the applicable requirements and risks.

Maintaining Effective Audit-Trail Controls

Audit-trail controls should be reassessed following:

software upgrades;
configuration changes;
new modules;
workflow changes;
master-data redesign;
role changes;
identity-provider changes;
migration;
archival changes;
supplier releases;
infrastructure changes;
security incidents; and
audit or inspection findings.

Periodic review should confirm that:

applicable audit trails remain enabled;
event capture remains appropriate;
users cannot alter audit trails;
timestamps remain controlled;
search and export remain usable;
reviews are completed at the required frequency;
exceptions are investigated;
trends are evaluated;
retention remains adequate; and
supplier limitations remain acceptable.

The objective is not to accumulate technical logs. It is to maintain a secure and understandable history that permits regulated records and significant system events to be reconstructed, reviewed, investigated, and explained.