Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics → Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Log Plug-and-play starting point Data Integrity

Log: Audit Trail Exception Disposition

A ready-to-use running log that tracks every flagged audit trail exception from detection through disposition and escalation, so an inspector can trace any exception to its conclusion, with field definitions and a filled specimen.

Document type: Log

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

An audit trail review that flags exceptions but keeps no traceable record of what happened to each one leaves the same gap it was meant to close: nobody can prove the exception was resolved rather than quietly ignored. This running log tracks every flagged exception from detection to closure. It is the thread an inspector follows when they ask “you found this exception, what did you do about it?” Replace every <<FILL: ...>> placeholder, keep the log under document control, and retain it per your records schedule. Field definitions, a filled specimen, and the retention rules follow. Verify each cited regulation against the current source before you rely on it.

Why this log exists (regulatory basis)

Both record-level and periodic audit trail review generate exceptions that must be reviewed and dispositioned, with quality-relevant ones escalated to a deviation or investigation. The MHRA GxP Data Integrity guidance and PIC/S PI 041 expect each exception to be reviewed and its conclusion recorded; EU GMP Annex 11 section 9 expects GMP-relevant changes to be documented and reviewable. This log is the single place that makes the detection-to-closure thread traceable in both directions, from an exception to its deviation and back.

Field definitions

FieldFormatRequiredWho entersWhen
Exception ID<<FILL: prefix>>-YYYY-NNNYesReviewerAt detection
Date flaggedDateYesReviewerAt detection
System / recordTextYesReviewerAt detection
Source of detectionRecord-level / Periodic / TriggeredYesReviewerAt detection
Exception rule / triggerRule ID or descriptionYesReviewerAt detection
Event detailWho, when, what changedYesReviewerAt detection
Initial assessmentFree textYesReviewerAt detection
Data held pending resolution?Yes / No / N/AYesReviewerAt detection
DispositionAcceptable-with-rationale / EscalatedYesReviewerAt closure
Rationale or deviation refText or deviation numberYesReviewerAt closure
Closed by / dateName + dateYesReviewerAt closure
QA oversight / dateName + dateYesQAAt closure

Log

Exception IDDate flaggedSystem / recordSourceRule / triggerEvent detailInitial assessmentData held?DispositionRationale / deviation refClosed by / dateQA / date
<<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>>

Instructions for use

  1. Open a row the moment an exception is flagged, whether by record-level review, periodic review, or a triggered review. Do not wait for disposition to log it; the detection date must be the real date.
  2. If the exception is quality-relevant or unexplained, hold the affected data (do not release or use it) and record “Yes” under data held.
  3. Disposition every exception with either “Acceptable” plus a recorded rationale, or “Escalated” plus the deviation or investigation number. An exception is never closed blank.
  4. QA reviews and signs the closure. The person who generated the data being questioned must not be the sole closer of the exception about it.
  5. Review open rows at each data governance review so no exception ages silently.

Acceptance criteria

  • Every flagged exception has a row; the log count reconciles with the exceptions cited on the review records.
  • Every row reaches a disposition; no row is closed without a rationale or a deviation reference.
  • Escalated rows trace to a real deviation/investigation, and that record traces back to the Exception ID.
  • Data-held decisions are recorded, and no affected data was used before the exception was resolved.
  • Closure carries both the reviewer and QA signatures with dates.

Retention

Retain this log for not less than <<FILL: retention period, aligned to the associated GMP records>>, and at least as long as the batch or result records whose audit trails it references. Store it so it remains legible, attributable, and retrievable for the full period.


Filled specimen

Two illustrative rows show how the log reads when one exception is acceptable and one is escalated.

Exception IDDate flaggedSystem / recordSourceRuleEvent detailInitial assessmentData held?DispositionRationale / deviation refClosed by / dateQA / date
DI-EXC-2026-04708 Jul 2026CDS / HPLC-07-2207-031Record-levelR-02 reprocessanalyst_jr reprocessed std curve, reason “wrong calibration level assigned”Original retained, both visible, correction plausibleNoAcceptableScientifically justified, second-person verified; no deviationA. Patel, 08 Jul 2026R. Gomez, 09 Jul 2026
DI-EXC-2026-04808 Jul 2026CDS / HPLC-07-2207-031Record-levelR-06 reason qualityanalyst_jr entered reason for change as “x”Reason non-meaningful, cannot confirm change is properYesEscalatedDEV-2026-0142 opened; result heldA. Patel, 08 Jul 2026R. Gomez, 09 Jul 2026

The two rows show the log doing its job: the acceptable exception carries a real rationale, the escalated one carries a deviation number and a data-hold, and both are closed with QA oversight. An inspector can pick either Exception ID and follow it to its conclusion, or start from DEV-2026-0142 and land back on this row.

Common inspection findings this log prevents

  • Exceptions flagged during review but no evidence of what was done about them.
  • An escalated exception with no deviation number, so the thread dead-ends.
  • A quality-relevant exception where the affected data was used before the exception closed.
  • Exceptions closed as “acceptable” with no recorded rationale.
  • The data generator closing the exception about their own data with no independent oversight.

How to adapt this log

  1. Set your Exception ID prefix and align retention to the GMP records the exceptions reference.
  2. Point the rule/trigger field at your validated exception rule set specification so IDs match.
  3. Wire closure into your deviation SOP so escalated rows always carry a real deviation number.
  4. Add the log to your data governance review agenda so open rows are actively worked.
  5. Confirm the referenced regulations against their current published versions before issue.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.