Audit Trail Review Workflow: Risk-Based GMP Review Steps

Audit Trail Review Workflow is a documented, risk-based process that assigns the scope, timing, reviewers, checks, escalation and evidence needed to assess changes and actions associated with GMP records.

Audit trail review and reviewing audit trails refer here to the assessment activity, not merely opening a history screen or exporting events. The workflow connects an electronic history to the record, process and decision it supports. See audit trail for the underlying record-history concept; this article focuses on selecting relevant histories, understanding events in context and documenting an assessment.

In practical terms, the reviewer asks whether recorded actions are understandable, justified and consistent with the activity being assessed. An edited result, for example, needs context from the original entry, the reason for the change and its effect on the decision—not just confirmation that an edit appears in the history.

The practical output is a review record identifying the assessed scope, evidence references, findings, reviewer and conclusion. A completed review records a supported conclusion for that scope; it does not necessarily mean no findings arose. An unresolved review identifies what still prevents a conclusion. Keeping these statuses distinct prevents an activity marked “reviewed” from concealing unanswered questions.

Start with an applicability map, not a universal audit-trail review checklist. Keep three decisions separate: which rules apply to the product and record; what the relevant authority says about the electronic history or its review; and how the site implements that expectation. The third decision is workflow design—not a new legal requirement.

Within the applicable Part 11 scope, 21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails independently recording the date and time of operator entries and actions that create, modify or delete electronic records. The same provision states that record changes must not obscure previously recorded information. These are binding electronic-record controls; distinguish them from the review expectations discussed below.

FDA guidance, question 7, explains that all production and control records, including audit trails, must be reviewed and approved by the quality unit, citing § 211.192. Attribute that explanation to FDA’s drug-CGMP guidance: the guidance is not itself binding legislation.

Annex 11, section 9, says reasons for GMP-relevant changes or deletions should be documented. It also says audit trails need to be available, convertible to a generally intelligible form and regularly reviewed. Treat this as official EU GMP guidance within the applicable GMP framework, not as a rule for every computerised manufacturing operation.

As a planning practice, document the product category, jurisdiction, record purpose, system use and applicability rationale alongside the selected authority. Check the current text of Part 11 and the applicable EU GMP framework for scope; use the Part 11 overview and cGMP context for orientation. Do not automatically transfer this drug-specific mapping to supplements, food, devices or chemicals.

Start with the decision the review supports: accepting a laboratory result, assessing a batch, or confirming that a record remains reliable. The following is a proposed site practice, not a prescribed regulatory template. Its boundary should let another reviewer reproduce the same selection.

Create a scope record containing the system and version, business process, product or batch where relevant, record identifiers, review window, event categories, source locations, report version, and exclusions with rationale. Use consistent production context tagging to connect events to the records being assessed.

Define the time-zone convention, including daylight-saving treatment, and the exact cutoff through which history is assessed. Distinguish that cutoff from the report extraction time. Where clocks differ, document the alignment basis; clock drift monitoring helps identify timing uncertainty.

• Results and calculations: edits that could change the reported outcome.
• Specifications, methods and master data: changes that could alter how an outcome is generated or judged.
• Privileged actions: access or configuration changes affecting record reliability.
• Ancillary status and communication events: assess their relevance before excluding them.

These are starting categories for site assessment, not fixed regulatory risk classes. For each, ask what a change could alter, whether another control would detect it, and whether delayed detection could affect a product or data decision. One technically small edit can matter more than thousands of routine events.

Include dependencies outside the primary record: the method version used for a calculation and the specification effective when a result was assessed. A laboratory boundary might span result edits and relevant method changes across the instrument and laboratory system. Exclude unrelated communication noise only after assessing its relevance and recording an intelligible reason; a default report filter is not a risk assessment.

Official guidance: tie timing to the record

For drug CGMP records, FDA guidance, question 8, recommends following the data-review frequency specified in CGMP regulations for the associated audit trail. Where regulations do not specify that frequency, it recommends determining timing through process knowledge and risk assessment, considering data criticality, control mechanisms and product-quality impact.

FDA guidance, question 7, connects responsibility to the underlying record: personnel responsible for record review should review the audit trails capturing changes to associated data as they review the rest of that record.

Implementation practice: assign decisions, not just access

• Record reviewer: assess the meaning of changes and their effect on the record’s conclusions.
• System owner: explain technical behaviour, including event generation and sequence.
• Administrator: support retrieval without substituting technical access for content review.
• Quality function: evaluate escalated quality concerns and determine the appropriate quality response.

Name deputies and define training expectations for each role. Address conflicts of interest explicitly: assigning another qualified reviewer to assess a person’s own changes is a risk-control design choice, not a universal legal formula.

Implementation practice: define checks and scheduling rules

Check the actor, timestamp and sequence, affected record, old and new values where applicable, reason, supporting reference, and relevant method or specification version. Ask whether the action changes a previously assessed conclusion. If timing appears inconsistent, use clock drift monitoring findings to investigate rather than assuming displayed order is reliable.

Distinguish an understandable correction from an unsupported explanation: “entry error” alone does not establish why the replacement value is credible. Compare the explanation with supporting records and the applicable version before accepting it.

Document the trigger or interval, why it fits the risk, the due-date rule, and who owns overdue work. A weekly or monthly interval is a site-specific choice requiring justification, not a universal requirement. Identify reassessment triggers—such as changed data criticality, weakened controls or a revised process—and connect them to change control. Make the due-date rule executable: specify its starting event and whether elapsed time means calendar or working days.

Use this proposed operating model within a controlled procedure. Entry requires a defined review trigger, an identified record set, an assigned reviewer and access to the relevant original context. Open an identifiable review instance; an exported file is an input, not a completed review.

1. Confirm the approved boundary: record identifiers, systems, time window and exclusions. Resolve any mismatch between the trigger and scope before proceeding.
2. Retrieve the records and associated histories, retaining the context needed to interpret changes, including original values, subsequent values and recorded reasons.
3. Establish extraction completeness against that boundary. Check retrieval limits, filters and coverage. If completeness cannot be established, record the gap and route the review for recovery rather than treating absent events as evidence of no changes.
4. Assess relevant changes in context. For each finding, connect the event to affected data, the reviewer’s question, supporting evidence, an impact assessment and an accountable decision.
5. Classify findings using local categories. Request clarification where needed; an unusual event is not, by itself, evidence of misconduct.
6. Resolve concerns with documented explanations or escalate through the applicable investigation or deviation process. Assign unresolved actions to an owner and retain their status in the review.
7. Record the conclusion using locally controlled decision codes. Identify who accepted each explanation and the basis for acceptance; do not close a concern merely because someone responded.

The workflow diagram summarises the proposed lifecycle: Trigger → Open review → Confirm boundary → Retrieve → Check completeness → Assess → Resolve or escalate → Record conclusion. Keep detailed checks in the procedure or checklist.

• Complete: no unresolved concerns.
• Complete: an identified explanation has been assessed and accepted.
• Incomplete or escalated: evidence or impact remains unresolved.

These labels are proposed, not prescribed. Completion needs an identifiable assessed scope, sufficient evidence, disposition of findings, reviewer attribution and a recorded completion time. Keep the human review conclusion separate from the authorised person’s batch disposition; software does not approve or release the batch.

These hypothetical cases test three different decisions: which changes need assessment, when a review should occur, and whether the review dataset is complete. All quantities and proposed decisions are illustrative industry practice, not regulatory thresholds or demonstrated performance outcomes.

For cross-system histories, including MES–historian integrations, use the following proposed reliability controls. Preserve source-system and event identifiers; record the extraction window, its boundary rules and time-zone conversion; and identify query or filter versions. Reconcile event membership, not just totals: equal counts can conceal a missing event offset by a duplicate or an unrelated event.

Recover without concealing the gap

1. Identify the affected records, systems and review window, and mark that review scope incomplete.
2. Preserve the incomplete extract, extraction parameters and error details so the failure remains reconstructable.
3. Obtain an authorised re-extraction or source-level assessment. Link each retry to the failed attempt and use source-system/event identifier pairs to detect duplicates rather than silently appending them.
4. Reconcile recovered events against the intended scope, resolving missing, repeated and unexpected entries.
5. Document the investigation and its effect on the review. Resume only when the recovered extract or source-level assessment supports the intended review scope.

For late-arriving events, document relevance to the earlier review window and conclusion; arrival time alone should not determine inclusion. If an event affects that conclusion, retain the original review history and create an attributable amendment or renewed review linked to it, rather than overwriting the earlier decision.

Recheck extraction logic after changes

In the EU GMP context, official guidance in Annex 11, section 10 calls for controlled computerised-system changes, including configurations, under a defined procedure. Proposed implementation controls within change control are to reassess report logic after connector, configuration or filter changes; test known included and excluded events; and define fallback access when a supplier-hosted interface is unavailable.

A completed review can conceal weak coverage or unresolved uncertainty. The following are practical investigation safeguards, not universal legal rules.

Attribution needs separate attention. FDA guidance, question 5, explains that shared login credentials prevent identification of a unique individual through the login. This is an attribution limitation, not a blanket judgment about every shared viewing arrangement; assess the action and its need for attributable recording.

For unattributable privileged activity, preserve available records, determine which changes and decisions could be affected, and escalate the uncertainty. Do not manufacture individual attribution by asking somebody to retrospectively sign for an unidentified action. Record what remains unknown without treating uncertainty alone as evidence of misconduct.

These activities answer different questions. The comparison below reflects common quality-system practice, not prescribed departmental ownership.

Official EU GMP guidance distinguishes periodic system evaluation from record-level review: Annex 11, section 11 describes periodic evaluation to confirm that computerised systems remain in a valid state and compliant with GMP.

Route an unexplained data change into deviation investigation, a permission concern into access remediation, and a recurring reporting weakness into system-change assessment. Link resulting records to the originating review; completion of one activity is not evidence that another occurred.

Use a review evidence package that lets another qualified person reconstruct the assessment without relying on the reviewer’s memory. The following evidence model and performance checks are proposed industry practices, to be adapted to local processes.

Evidence package and retention

• Record the scope and rationale, source-system and record references, extraction parameters, reconciliation results, and report version.
• Identify assessed events or queries, including filters and review cutoffs; retain findings and links to investigations.
• Capture reviewer identity, completion time and conclusion. A no-findings review still needs enough detail to establish what was assessed.

For closed systems within its scope, 21 CFR 11.10(e) requires audit-trail documentation to be retained at least as long as the subject electronic records and available for agency review and copying. This is not a fixed-year retention period.

For drug CGMP records, FDA guidance, question 9, links true-copy suitability to preservation of original content and meaning, including metadata. Assess exports against that principle; PDF format alone does not establish suitability.

Proposed data-model diagram: Review → Scope and extraction → Event references → Findings → Investigations; Review → Reviewer and conclusion. These are review-management entities, not a named application’s database schema or capabilities. Event references point back to source history rather than replacing it. Link investigation records through controlled MES–QMS integration where appropriate.

Performance and implementation checks

• On-time completion (%) = reviews completed by their due date ÷ reviews due in the defined cohort × 100. Report an empty cohort as not applicable.
• Report unresolved high-risk findings with age in days from identification; count evidence-retrieval failures separately from review findings.
• Use trends in management review; low finding counts alone do not demonstrate effective review.

At implementation and periodically, confirm approved scope, justified timing, trained reviewers and deputies, challenged report logic, tested exception recovery, clear escalation ownership and retrievable evidence. Reassess after relevant process or system changes.