Audit Trail Review as a Data Quality Control: Two Pilots Every Pharma Site Should Run

Why Audit Trail Review Is a Data Quality Control

Ask a quality leader why their site reviews audit trails and a common answer is some version of “because the regulations say so.” That answer is correct, and it is also the reason so many programs deliver so little. When the purpose of a control is compliance alone, the natural goal becomes producing evidence that the review happened. When the purpose is data quality, the goal becomes finding the records that should not be trusted yet.

FDA’s data integrity guidance puts the idea in plain terms: “Audit trail review is similar to assessing cross-outs on paper when reviewing data.”¹ No experienced reviewer would sign a paper batch record without looking at the cross-outs. They would want to know what changed, who changed it, and why. Those are data quality questions. They ask whether the number on the page is the number the process produced, and whether any change to it was justified. An electronic audit trail answers the same questions for electronic records, often in more detail than paper ever could.

What an Audit Trail Tells You That a Result Cannot

A final result is a single value. The audit trail behind it tells you the story of how that value came to be. FDA defines an audit trail as a secure, computer-generated, time-stamped electronic record that allows reconstruction of the course of events relating to the creation, modification, or deletion of an electronic record. Its example is a chromatography run, where the audit trail should include the user name, the date and time of the run, the integration parameters used, and details of any reprocessing, along with a justification for that reprocessing.¹

Each of those elements says something about data quality:

• Who tells you whether the data is attributable, and whether the person had the right role to make the change.
• When tells you whether entries were contemporaneous or backfilled, and whether a change came before or after a result was known.
• What tells you whether the original value is still visible and how far the final value moved from it.
• Why tells you whether the change followed an approved procedure or was made to reach a desired outcome.

These map directly to the ALCOA+ attributes that most sites already use to define data integrity: attributable, legible, contemporaneous, original, and accurate, plus complete, consistent, enduring, and available. A result can look perfect and still fail several of those attributes. Only the audit trail shows it.

Two Uses of the Same Record

Most sites use audit trails in one way: a reviewer checks the audit trail for a specific batch or test before approving it. That is record-level review, and it is the use the regulations describe most directly. It answers the question “can I trust this record?”

There is a second use that far fewer sites attempt: trend review. Instead of looking at one record, you count certain kinds of events across many records over time. How many results were modified this month compared with last month? Which instruments generate the most reprocessing? Which user accounts have repeated failed logins? Trend review answers a different question: “where is our data most at risk?” It finds patterns that no single record review would notice, because each individual event may look justified on its own.

The two pilots in this article map to these two uses. Pilot one makes record-level review sharper and more consistent on one critical system. Pilot two adds a trend review that feeds the quality unit’s oversight. Together they turn the audit trail from a compliance artifact into a working data quality control.

What Regulators Expect From Audit Trail Review

Before designing any pilot, it helps to be precise about what the primary sources say. There is more agreement among regulators than most people assume, and the areas of agreement give you the design rules for both pilots.

FDA: Review With the Record, at a Frequency Set by Risk

FDA’s 2018 guidance, Data Integrity and Compliance With Drug CGMP: Questions and Answers, addresses audit trail review in two questions. On who should review, it says personnel responsible for record review under CGMP should review the audit trails that capture changes to data associated with the record as they review the rest of the record. It notes that all production and control records, which include audit trails, must be reviewed and approved by the quality unit under 21 CFR 211.192, while the regulations allow some activities to be reviewed by a person directly supervising or checking information.¹

On frequency, FDA gives a two-part answer. Where the CGMP regulations set a review frequency for the data, the audit trail review follows the same frequency, for example after each significant step in manufacture or before batch release. Where the regulations do not set a frequency, the site should decide using knowledge of its processes and risk assessment tools. In FDA’s words, “The risk assessment should include evaluation of data criticality, control mechanisms, and impact on product quality.”¹ A footnote lists examples of audit trails that may be appropriate to review on a risk-based frequency: those that capture instrument operational status, instrument communication logs, and alert records.

The same guidance makes a point that matters for pilot two. On reprocessed chromatography, FDA writes: “For most lab analyses, reprocessing data should not be regularly needed.”¹ If reprocessing should be uncommon, then its rate is worth watching.

The guidance is built on the regulation. 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, without obscuring earlier information.⁵ 21 CFR 211.194(a) requires laboratory records to include complete data derived from all tests.⁶ An audit trail that exists but is never read does not help a site show that its records are complete.

MHRA: Risk-Based, With Exception Reporting and Clear Limits

The MHRA’s GXP Data Integrity Guidance and Definitions (Revision 1, March 2018) says routine data review should include a documented audit trail review where a risk assessment determines it is needed. The review may be limited to audit trails with GxP relevance, and it may be done either as a list of relevant data or through exception reporting. MHRA defines an exception report as “a validated search tool that identifies and documents predetermined ‘abnormal’ data or actions, that require further attention or investigation by the data reviewer.”⁷

MHRA also sets a limit that many sites overlook: “It is not necessary for audit trail review to include every system activity (e.g. user log on/off, keystrokes etc.).”⁷ It adds that reviewers need enough knowledge and system access to review the relevant audit trails, raw data, and metadata. Both points shape who should do the review and what they should look at.

PIC/S PI 041-1: Critical and Non-Critical, Plus a Quality Unit Program

PIC/S PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments (1 July 2021), gives the most detailed structure of any of the sources.⁴ Several of its expectations translate directly into pilot design:

• Assess each audit trail during qualification. Section 9.6 expects regulated users to determine the GMP/GDP relevance of each audit trail, and which entries within it are significant enough to review at a defined frequency.
• Focus the review. The same section suggests reviews may concentrate on entries that relate to changes or modification of data, on review by exception for anomalous or unauthorized activity, and on systems whose limitations leave data open to change. It notes that well-designed systems with permission settings that prevent changes may reduce the need to examine related audit trails in detail.
• Separate critical from non-critical. Critical audit trails related to each operation should be reviewed independently with the other records for that operation and before its completion, for example before batch release. Non-critical audit trails can be reviewed during system reviews at a predefined frequency. In both cases the originating department performs the review, with verification by the quality unit where necessary.
• Write down how to review. Section 9.8 expects an SOP that describes in detail how to review audit trails, what to look for, and how to perform searches, and it expects the review itself to be documented and recorded.
• Run an ongoing program. The quality unit should establish a program and schedule of ongoing audit trail reviews, based on criticality and system complexity, to verify that controls are working and to detect potential non-compliance. These reviews should be part of self-inspection. PIC/S adds: “Audit trail reviews should be both random (selected based on chance) and targeted (selected based on criticality or risk).”⁴

Section 5.6 of PI 041-1, on reviewing the data governance system, also lists a risk-based sample of computerized system logs and audit trails, and a review of quality system metrics through trending, as ways to check whether data governance is working.⁴ That is the regulatory basis for pilot two.

EU Annex 11: The Current Text and the Draft Revision

The version of EU GMP Annex 11 in force is still the January 2011 revision. Its clause 9 on audit trails is short. It asks sites to consider, based on risk, building in a record of all GMP-relevant changes and deletions, with the reason documented, and it ends: “Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.”⁸

The draft revision of Annex 11, released for stakeholder consultation in July 2025 alongside a revised Chapter 4 and a new Annex 22, is far more specific.³ It is still a draft and not yet in force, but it shows what European inspectors are likely to expect. Section 12 includes these points:

• 12.5 Reviews: reviews follow a documented procedure for the specific system or type of system, stating who reviews, what is reviewed, and when. The use of tools to help is encouraged, and significant variations should be fully investigated and recorded.
• 12.6 Independent review: reviews should be done by personnel not directly involved in the activities covered.
• 12.7 Scope of review: “Reviewing all entries in an audit trail record may not be effective.” Reviews should be targeted, based on risk, and focused on detecting changes to critical processes or data that indicate a violation of GMP principles, including repetition of activities, errors, omissions, unauthorized process deviations, and loss of data integrity. The draft adds: “A key element should be to verify the reason why a change is made.”
• 12.8 Timeliness: reviews should happen in a timely manner according to risk, and before batch release unless the risk of later detection can be justified.

Note the phrase “repetition of activities” in 12.7. Repeated tests and repeated processing steps are among the most useful trend signals, and the draft names them as something the review should be designed to detect.

WHO and EMA Say the Same Thing

The WHO Guideline on Data Integrity (Technical Report Series No. 1033, Annex 4, 2021) says the routine review of GxP data and metadata should include audit trails, and that the criticality of the system and the category of audit trail information (batch specific, administrative, system activities) should be considered when setting the frequency of review. It also expects evidence of the review to be kept.⁹

EMA’s GMP questions and answers on data integrity explain why the electronic record, and not a printout, has to be reviewed: “The review of the raw electronic data should mitigate risk and enable detection of data deletion, amendment, duplication, reusing and fabrication which are common data integrity failures.” EMA also confirms that a risk-based review of electronic data is acceptable and that review by exception is permitted when scientifically justified.¹⁰

Where Audit Trail Review Programs Break Down

If the expectations are this consistent, why do so many sites struggle? The March/April 2026 issue of ISPE’s Pharmaceutical Engineering carried an article by Anna Dachs Soler and Sion Wyn on exactly this gap between regulatory expectation and practice.¹¹ Their observations, along with our own experience, point to four recurring failures.

Reviewing Everything, So Reviewing Nothing

The ISPE authors describe audit trail modules that produce thousands of entries a month across fragmented files, most of them irrelevant to data integrity or quality, which makes meaningful manual review impossible.¹¹ When a reviewer is handed an export of every event and asked to “review the audit trail,” the review becomes a skim. The reviewer signs because there is no practical way to do anything else. The signature then gives false comfort, because it implies a level of scrutiny that did not happen.

The fix is not more effort. It is a narrower, better defined review, which is what the draft Annex 11 means when it says reviewing all entries may not be effective.

Confusing Data Audit Trails With System Logs

The same ISPE article draws a line that many SOPs blur. Data audit trails are linked to GxP records and capture changes to those records. System or technical logs capture system-level events such as logins, password changes, configuration adjustments, and role management. The authors note that GAMP 5 (Second Edition) treats only audit trails linked to GxP-relevant records as requiring routine review, and that technical logs do not need routine or periodic review unless risk justifies it.¹¹ This is consistent with MHRA’s statement that audit trail review need not include every log-on or log-off.⁷

Sites that mix the two tend to fail in both directions. Some reviewers spend their time on login histories while missing a changed result. Others ignore system logs entirely, including the administrator actions that matter most. The Pharmaceutical Technology paper from the IQ Consortium working group, published in 2022, recommends that the system audit trail, which contains actions such as data deletion by administrators or changes to security settings, be reviewed at least periodically, and notes that user access reviews and configuration reviews can serve the same purpose.¹²

The two pilots in this article keep these separate on purpose. Pilot one is a data audit trail review at the record level. Pilot two uses some system log events, such as failed logins, but only as aggregated trend signals reviewed on a schedule, not as a line-by-line review attached to each record.

Reviewing the Printout Instead of the System

EMA’s questions and answers describe an inspection citation in which raw data for invalidated HPLC and GC runs was stored separately from the QC raw data packages and never included in the review. The site’s procedure did not require a review of the electronic raw data or the related audit trails, so those records were excluded, and the company could not explain why the data had been invalidated.¹⁰ A review built on printed reports will never see a run that was not printed.

What Enforcement Shows

FDA warning letters continue to show what happens when review does not reach the audit trail. In February 2025, FDA wrote to Aspen Pharmacare Holdings Limited: “Your Production and QU did not review electronic raw data and audit trails to ensure data integrity prior to batch release.” The letter describes operators who ran repeated filter integrity tests and reported only the final passing result. For one batch, four tests included three failures. For another, nine tests included five failures and three aborted tests, and only the last passing result was reported. FDA found the firm’s response inadequate in part because it did not state the scope and time period of its retrospective review.²

In March 2025, FDA wrote to International Laboratories Corp, a drug manufacturer, after an FDA investigator documented numerous examples of deleted electronic raw data files. The letter states that analysts had administrative rights capable of altering and deleting data, files, and folders on the chromatographic systems, including the date and time of tests.¹³

Pilot One: A Risk-Based Review of One Critical System

The first pilot takes one critical system and builds the audit trail review you would want every system to have: scoped by risk, driven by defined triggers, done by the right people at the right time, and recorded in a way that shows what was checked. Starting with one system keeps the effort manageable and gives you something concrete to show leadership and inspectors.

Choosing the System

Pick a system that generates data used directly for a quality decision and where changes to data are possible. Good candidates for most pharma sites include:

• The chromatography data system in the QC laboratory, which supports release and stability testing.
• The electronic batch record or manufacturing execution system, where parameters, entries, and exceptions feed batch release.
• The laboratory information management system, where results are entered, calculated, and approved.

The IQ Consortium authors report that, in an informal poll of member companies, data from GLP studies, cleaning verification, clinical product release, and stability were considered greater impact, while activities such as method validation may be rated lower depending on a company’s risk considerations.¹² That is a helpful starting list. Choose a system where you already suspect the review is weak, or where the audit trail volume is high enough that reviewers are skimming. A pilot that confirms an already strong process teaches you less.

Mapping the Audit Trails and Rating the Events

Most systems have more than one audit trail: a record-level audit trail for data changes, a system audit trail for configuration and administration, and often separate logs for instrument communication or alarms. PIC/S expects this assessment to happen during qualification.⁴ If it was not done then, the pilot is a good time to do it. For each audit trail, list the event types it records and rate each one.

A simple rating uses two questions drawn from FDA’s own risk factors: how critical is the data affected, and how well do the system’s technical controls prevent or reveal an improper change?¹ The IQ Consortium paper makes the same point in practical terms: prevention through technical controls is preferred where feasible, and where an action cannot be prevented, the review should be designed to detect it.¹²

The table is an example, not a template to copy. Your ratings depend on how your system is configured. If your chromatography data system blocks manual integration without supervisor approval, that event may drop in priority. If your analysts can still delete files, deletions become a per-record check rather than a periodic one.

Defining the Triggers

A trigger is a specific, observable condition in the audit trail that requires the reviewer to stop and resolve it before approving the record. Triggers are what turn “review the audit trail” into a task a reviewer can complete the same way every time. The IQ Consortium paper offers a useful list of critical changes to check: changes to test parameters, changes to data processing parameters, deletion of data, repeated analysis or reprocessing without justification, the change history of finished product test results, changes to sample sequences, changes to sample identification, and changes to critical process parameters.¹² Draft Annex 11 section 12.7 adds repetition of activities, errors, and omissions.³

For the pilot, write each trigger as a clear rule. For example:

• Any result whose processing method or integration was changed after the first result was generated.
• Any sample with more than one injection or test where only one result is reported.
• Any aborted or incomplete run within the sequence being approved.
• Any change to sample identity after data acquisition.
• Any change with a missing, generic, or unclear reason (for example “correction” or “per analyst” with no detail).
• Any change made by a user whose role should not permit it, or by an administrator account during routine work.
• Any entry whose timestamp falls well after the activity it records, beyond a window you define.

The reason-for-change trigger deserves attention. The draft Annex 11 calls verifying the reason for a change a key element of the review.³ In our experience, the reason field is where many data quality problems first appear, and where they are easiest to miss. A reason such as “integration adjusted” tells the reviewer what happened but not why, and a reviewer who accepts it has not verified anything.

Timing the Review

For critical data, the review happens before the data is used for a decision. FDA says the audit trail review follows the frequency the regulations set for the data itself, such as before batch release.¹ PIC/S expects critical audit trails to be reviewed before completion of the operation.⁴ For the pilot, build the audit trail review into the same workflow step as the result or batch approval, not as a separate task done later. A review that happens after release does not protect the release decision.

For the system audit trail and other lower-risk logs, set a fixed interval, such as monthly, and document why that interval fits the risk. The IQ Consortium authors note that the frequency should match the likelihood of the risk and may be adjusted based on documented history: “The frequency may be adjusted based on documented historical performance.”¹² That gives you a defensible path to reduce frequency later if the pilot shows few issues.

What to Measure During Pilot One

A pilot is only useful if it produces evidence for a decision. Measure these from the start:

• Trigger hit rate: the share of records with at least one trigger, by trigger type.
• Resolution outcome: for each trigger hit, whether it was justified and documented, corrected, or escalated to a deviation.
• Reason quality: the share of changes whose recorded reason was specific enough to verify without asking the analyst.
• Review time per record: before and after the pilot, so you can show the effect on reviewer workload.
• Review timing: the share of reviews completed before the approval or release decision.
• Findings missed by the old method: any issue the pilot review found that the previous review would not have caught.

Pilot Two: Turning Audit Trail Events Into Data Quality Signals

Record-level review asks whether one record can be trusted. Trend review asks where the process, the system, or the people using it are producing data that needs more attention. The second pilot builds that view.

Why Trends Find What Record Review Misses

Every individual event in an audit trail can have a reasonable explanation. A single manual integration may be justified by a poor baseline. A single repeat test may follow a documented instrument error. A reviewer looking at one batch will accept those explanations, and often should. The problem shows up only in aggregate: one instrument with three times the reprocessing rate of its neighbors, one shift with far more repeat tests, one product whose results are modified more often than others.

Look again at the Aspen letter. A reviewer who saw only the final passing filter integrity result had nothing to question. A trend count of filter integrity tests per batch would have shown batches with four and nine tests where one is expected.² The data needed to see the pattern was already being recorded.

This is also where the regulatory sources point. PIC/S asks the quality unit to run an ongoing program of audit trail reviews, both random and targeted, as part of self-inspection, and it lists trending of quality system metrics as a way to check whether data governance is working.⁴ Trend review is how you choose the targets.

Four Families of Signals

Start with four families of events that most GxP systems already record. Each one is a potential data quality signal, and each one needs a denominator so you are comparing rates, not raw counts.

The fourth family needs care. MHRA and the ISPE authors are clear that routine audit trail review does not need to cover every login event.⁷¹¹ Pilot two respects that. It does not ask anyone to read login histories. It counts failed logins and lockouts automatically and reviews the totals once a month. PIC/S expects systems to be able to list successful and unsuccessful login attempts, which means the data for this signal is usually already available.⁴ The draft Annex 11 also calls for an access log, separate or as part of the audit trail, that is sortable and searchable.³

Setting Baselines and Thresholds

Do not set thresholds on day one. Use the first two to three months of the pilot to collect data and understand normal variation for each signal. Then set two levels for each: a watch level, where the trend is noted and followed, and an action level, where a targeted audit trail review of the affected records is triggered. Base the levels on your own data, not on figures borrowed from another site, because instrument mix, product types, and system configuration all change what normal looks like.

ICH Q9(R1) supports this kind of scaled response. It states: “The level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk.”¹⁴ A signal at watch level warrants a note in the monthly review. A signal at action level warrants a targeted review, a documented conclusion, and possibly a deviation.

Where the Trend Review Fits

Trend review is not part of batch release. It runs on a schedule, usually monthly, and it belongs to the quality unit’s oversight. A good home for it is the same forum that reviews deviation trends and other quality metrics. The output is a short list of targets: specific instruments, products, users, or time periods that get a targeted audit trail review in the following month. Add a small random sample on top, so the program meets the PIC/S expectation of both random and targeted reviews and so you are not only looking where you already expect problems.⁴

What to Measure During Pilot Two

• Data availability: for each signal, whether the system can produce the count automatically, needs a manual export, or cannot produce it at all.
• Baseline and variation: the normal range for each signal by system and area.
• Targeted review yield: the share of trend-driven targeted reviews that found something needing action, compared with the random sample.
• Root causes found: how many signals traced back to methods, equipment, procedures, training, or access design, as opposed to individual behavior.
• Time to act: days from a signal crossing the action level to a completed targeted review.

The comparison between targeted and random yield is the most important measure in pilot two. If trend-driven reviews find more issues than random ones, the signals are working. If they find about the same, the signals need to be redesigned.

Who Reviews: Roles, Independence, and Training

Who performs the review matters as much as what they review. The sources give a clear division of labor, and both pilots should follow it.

The Originating Department and the Quality Unit

PIC/S assigns routine review to the originating department, with verification by the quality unit where necessary, and assigns the ongoing program of reviews to the quality unit.⁴ FDA places responsibility with the personnel responsible for record review, with the quality unit reviewing and approving production and control records.¹ In practice, that means the lab or production reviewer who checks the data also checks the related audit trail triggers in pilot one, and the quality unit owns the trend review in pilot two.

Independence

The draft Annex 11 says audit trail reviews should be done by personnel not directly involved in the activities covered by the review, a peer review.³ Most sites already use a second-person review for lab data, so this is usually a matter of confirming that the person reviewing the audit trail is not the analyst or operator who generated the data. For small teams, write down how independence is maintained when staffing is thin, because that is the situation in which it tends to slip.

Training and System Access

MHRA expects reviewers to have enough knowledge and system access to review relevant audit trails, raw data, and metadata.⁷ The ISPE authors identify a lack of reviewer training as a common gap, with reviewers who do not understand the data life cycle, the purpose of data audit trails, or the system’s technical capabilities.¹¹ Training for the pilots should cover how the system records each triggered event, what a good reason for change looks like, how to use the saved queries or exception reports, and what to do when a trigger cannot be resolved.

How to Document Both Pilots So They Hold Up

An inspector will ask three things about any audit trail review: what your procedure says, whether you followed it, and what you did when you found something. Documentation for the pilots should answer all three without needing someone to explain it in person.

The Procedure

PIC/S expects an SOP that describes in detail how to review audit trails, what to look for, and how to perform searches.⁴ The draft Annex 11 expects a documented procedure for the specific system or type of system that states who reviews, what is reviewed, and when.³ For the pilot, a system-specific work instruction under your existing data review SOP is usually enough. It should include:

• The list of audit trails in the system and the rating for each event type, with the reasoning.
• The written triggers and the query or report used to find each one.
• The timing of each review relative to approval or release.
• The roles, including how independence is maintained.
• What counts as an acceptable resolution for each trigger, and when to escalate.
• For pilot two, the signal definitions, denominators, watch and action levels, and the monthly review agenda.

The Review Record

WHO expects evidence of the review to be maintained and, where required, a documented, signed, and dated conclusion.⁹ PIC/S expects the review activity to be documented and recorded.⁴ A signature that says “audit trail reviewed” does not show what was reviewed. A better record lists which triggers were checked, which were hit, and how each hit was resolved. If no triggers were hit, the record should say so explicitly. If your system supports electronic review records, use them, because they tie the review to the specific data and version reviewed.

Validating the Queries and Exception Reports

Both pilots depend on filtered views, saved queries, or exception reports that find the right events. MHRA defines an exception report as a validated search tool.⁷ EMA says an automated system and its batch exception report must be tested and validated so that the functionality meets business and regulatory requirements.¹⁰ Treat each trigger query as a small, validated function. Test it against seeded records that should be found and records that should not. Keep the test evidence. Put the query under change control so that a system upgrade does not break it without anyone noticing.

This is the step sites most often skip, and it is the one that matters most. If the query misses a category of events, every review that relies on it inherits the gap, and every signature on those reviews carries it forward.

Escalation

PIC/S expects procedures to address and investigate audit trail discrepancies, including escalation to senior management and to national authorities where necessary.⁴ The draft Annex 11 expects any significant variation from the expected outcome to be fully investigated and recorded.³ For the pilots, define in advance which trigger outcomes become deviations, which trend signals at action level become deviations, and who decides. Make sure a deviation raised from an audit trail review is linked back to the review record, so the chain from detection to resolution is visible.

Reading the Results and Deciding What Comes Next

At the end of the pilots, the goal is a clear decision backed by evidence: adopt, adjust, or stop. Here is how to read what you find.

Signs That Pilot One Worked

• Reviewers can describe what they checked on a given record without looking it up.
• The share of reviews completed before approval or release is at or near all of them.
• Reason-for-change quality improved during the pilot, because analysts knew the reasons would be read.
• Review time per record fell or held steady while the number of issues found rose.
• The pilot found at least some issues the old review would have missed, or it showed with evidence that the old review was not missing anything in this system.

That last point matters. A pilot that finds very little is still useful if it shows, with documented triggers and tested queries, that the system’s controls are working. That evidence can justify a lighter review frequency for lower-risk events, as the IQ Consortium authors suggest when they note that frequency can be adjusted based on documented history.¹²

Signs That Pilot Two Worked

• At least some signals can be counted automatically, without manual exports each month.
• Targeted reviews found more issues than random ones.
• Several signals traced back to fixable causes such as methods, instruments, procedures, or access design.
• The monthly trend review produced actions that were completed, not just discussed.

Extending to the Next System

If pilot one works, the next system is easier, because the method is proven and the work instruction format already exists. Choose the next system by the same logic: critical data, possible changes, and a review you suspect is weak. If pilot two works, add each new system’s signals to the same monthly review, so the quality unit sees one view across systems rather than separate reports.

Two practical points help when extending. First, add audit trail review requirements to system requirements for new or upgraded systems. The ISPE authors recommend specifying filtering, keyword search, change flagging, and electronic review documentation during procurement.¹¹ The draft Annex 11 expects systems to allow audit trail data to be sorted and searched, or exported to a tool where that is possible.³ Second, fold the pilot results into periodic review of each system, so that the audit trail review design is revisited when the system changes.

Common Mistakes to Avoid

• Piloting on a system with no real risk. The results will not convince anyone.
• Relying on an untested query. A query that misses events is worse than no query, because it creates false confidence.
• Writing vague triggers. “Review for anomalies” is not a trigger. “Any result with a manual integration after the first result” is.
• Treating signals as findings. This damages trust and reduces honest recording.
• Letting trend review become a report nobody acts on. Every monthly review should end with named targeted reviews and owners.
• Reviewing login histories line by line. Count them; do not read them.

Conclusion

Audit trail review is one of the few controls in a pharma quality system that looks directly at how data came to be what it is. Most sites use only a small part of that. They review as a compliance step, often by skimming more entries than anyone could meaningfully read, and they rarely look across records to see patterns. The regulatory expectations from FDA, MHRA, PIC/S, WHO, and EU Annex 11 do not require that approach. They ask for a review that is risk-based, focused on critical changes, timed before decisions, done by the right people, and documented. That is also exactly what a good data quality control looks like. The two pilots in this article, a triggered review on one critical system and a trend review built from events the system already records, are a practical way to get there without rebuilding the whole program at once.

Sakara Digital works with pharma and biotech organizations that want their data integrity controls to improve data quality, not just produce records of compliance. If you are considering an audit trail review pilot and want an independent view on which system to start with, how to write the triggers, or how to set up a trend review your quality unit will use, we are happy to have that conversation.

For Further Reading