# Running a data audit: from access logs to inspection readiness
An FDA (US Food and Drug Administration) inspector sits down at a sponsor's office, opens a clinical database, and points to one field: a patient's adverse event severity rating, changed from "moderate" to "mild" four days before database lock. Her question is simple: "Who made this change, when, and why?" If your system cannot answer that in under five minutes, you have a finding. If it can, with a timestamped reason and an approver's name attached, the inspection moves on. This is the entire game of data audit readiness in pharma: not whether data is perfect, but whether every change to it is traceable, justified, and reviewed.
Regulatory inspections happen constantly across the industry. The FDA runs Bioresearch Monitoring (BIMO) inspections on clinical trial sites, sponsors, and labs. The EMA (European Medicines Agency) and national bodies like the UK's MHRA (Medicines and Healthcare products Regulatory Agency) run GxP inspections (Good Clinical, Laboratory, or Manufacturing Practice). All of them converge on the same question: can you reconstruct the history of your data?
This traces back to a foundational rule: 21 CFR Part 11, the FDA regulation governing electronic records and electronic signatures. It requires that computer systems used in regulated work maintain secure, time-stamped audit trails that record who created, modified, or deleted data, and that these trails cannot be altered after the fact. Europe's equivalent expectations sit inside EU GMP Annex 11 and GCP (Good Clinical Practice) guidelines from the EMA.
The underlying principle regulators use is a mnemonic worth memorizing: ALCOA+. Data must be Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available. Every audit check in this lesson maps back to one of these letters.
An access log records every login, query, and system entry tied to a user ID. In a clinical trial database (often an EDC, Electronic Data Capture system, like Medidata Rave or Oracle's Clinical One), access should be role-based: a Clinical Research Associate (CRA) can view but not edit certain locked fields; a data manager can query but not unblind treatment codes.
The concrete check: pull a report of everyone who accessed the adverse event module in the last quarter, cross-reference against the current staff roster and their assigned roles. Flag anyone who accessed data outside their study assignment, or any account still active after an employee left the company. This second one is a classic finding: orphaned credentials are a top-cited GxP data integrity gap.
This is the audit trail proper: a system-generated, immutable log of every edit, showing old value, new value, timestamp, user, and (for meaningful changes) a documented reason. Good systems make the reason field mandatory before a change saves.
Worked example of what an auditor expects to see for that adverse event field:
Field: AE_Severity
Record ID: SUBJ-0142-AE03
Old value: Moderate
New value: Mild
Changed by: jsmith (Data Manager, Site 04)
Timestamp: 2026-02-11 14:32:07 UTC
Reason: Correction per source document verification, see query Q-2291
Approved by: mrivera (Clinical Data Lead)If any of those fields is blank, missing a reason code, or backdated, that is a data integrity red flag. Auditors specifically look for patterns: bulk edits made right before database lock, edits with no corresponding query trail, or changes made by IDs with no matching training record.
A Standard Operating Procedure (SOP) is the documented, approved process a company commits to following. Having an audit trail feature turned on means nothing if staff were not trained on when to use it, or if the SOP for "data correction after monitoring visit" was ignored.
The concrete check: sample 10 to 15 changes from the audit trail, then trace each one back to its supporting SOP step. Was a query raised in the system before the edit? Was there a second-person review, as most SOPs for critical fields require? This is called a "trace-forward, trace-back" exercise, and it is exactly what BIMO inspectors do.
Companies that pass inspections cleanly rarely improvise. They run internal "mock inspections" on a schedule, often quarterly for active trials and annually for closed studies still in retention.
A practical checklist to run, sector-agnostic in tooling but pharma-specific in application:
For a structured reference, the FDA's own guidance on Data Integrity and Compliance With Drug CGMP is free and lays out the exact questions inspectors are trained to ask.
Vérification des acquis
1. An inspector asks who changed an adverse event rating and why. What is the fundamental principle being tested?
2. Why is 21 CFR Part 11 central to data audit readiness?
3. A sponsor's system logs every data change but allows those log entries to be edited later without a trace. What regulatory expectation does this fail to meet?
4. Select ALL correct answers about why regulatory bodies like the FDA, EMA, and MHRA converge on similar inspection questions.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about the ALCOA+ principle.
Sélectionnez toutes les réponses correctes.
Modern clinical and manufacturing systems increasingly build audit trails as a default, non-optional feature, partly because regulators have escalated enforcement. FDA warning letters citing data integrity failures (missing audit trails, shared login credentials, deleted records) have remained a recurring category in FDA inspection findings for over a decade; sponsors should treat any shared-password practice as an automatic audit failure waiting to happen.
The direction of travel is toward continuous, automated monitoring rather than periodic manual review. Some companies now run automated scripts that flag anomalies in real time, for example an edit made outside business hours, or a cluster of "moderate to mild" downgrades right before a filing deadline, rather than waiting for a quarterly human sample-check. This does not replace SOPs or human review, but it narrows the window between a problem occurring and someone noticing it.
🎬 [VIDEO: "21 CFR Part 11 Explained: Electronic Records and Signatures" - youtube.com - a walkthrough of what the regulation requires for audit trails, e-signatures, and system validation in pharma and biotech]
Think of an inspection-ready data system as answering three questions instantly, for any data point, at any time:
1. Who touched this, and were they authorized to?
2. What changed, when, and is there a documented reason?
3. Does the process followed match the SOP that was in force at that moment?
If any answer takes more than a few minutes to produce, or requires manually stitching together spreadsheets and emails, that is itself the finding, independent of whether the underlying data was ever wrong.