The call comes with forty-eight hours notice. The FDA inspector — or an internal auditor, or a customer qualification team — will be on site in two days. The question immediately in front of the QA team: what is the current configuration of every critical system, and how far back can we document it?
For most manufacturing operations, that question triggers a scramble. Engineers are pulled to produce documentation. Log files are searched. Change management records are reviewed. Someone reconstructs what the system looked like during the batches in question from fragments of information spread across multiple systems.
Sometimes it holds together. Sometimes it doesn't. Either way, it consumes days of effort that should have been unnecessary.
What auditors are actually looking for
GMP audits related to equipment and system configuration tend to focus on a consistent set of questions. Was the system qualified? Has it remained in its qualified state? How do you know what the configuration was at the time of a specific batch or deviation? What is your change control process, and does it capture all changes — including unplanned ones?
These questions are not new. What has changed in recent inspection cycles is the depth of evidence expected in response. Regulators are increasingly alert to the gap between a robust-looking change control procedure and the actual completeness of the change record. A procedure that requires documentation of all changes is not sufficient if unplanned changes go uncaptured.
Data integrity is the framework through which inspectors now approach these questions. A configuration record that was assembled after the fact, or that relies on manual logging that may have been inconsistently applied, is vulnerable. An automatic, continuous record that captures every change as it happens is not.
The anatomy of an always-ready configuration audit trail
An always-ready audit trail has four components that work together. First, immutable baselines captured at each phase boundary — installation, qualification, production start — that represent the system's in-control states over time.
Second, continuous change detection that captures every deviation from baseline as it occurs: what parameter changed, on which device, from what value to what value, and when. The record is automatic and does not depend on the engineer who made the change choosing to log it.
Third, a version history that is complete and time-ordered — not a selection of significant changes, but a full record of every change, searchable and exportable for any time period.
Fourth, role-based access controls that ensure only authorised personnel can make configuration changes in the first place, with a complete record of who accessed which system and when.
Together, these components mean that the answer to "what was the configuration during batch 4471?" is always available, always complete, and always verifiable — not because someone assembled it in response to the audit request, but because it was built continuously as a byproduct of normal operations.
Change control versus configuration monitoring
Change control and configuration monitoring are complementary, not interchangeable. Change control manages planned changes: the approval workflow, the risk assessment, the implementation record. It is essential and should be rigorous.
Configuration monitoring captures what actually happened to the system — including changes that bypassed the change control process, whether intentionally or accidentally. It is the difference between a change control record that says "these changes were approved" and a configuration record that says "these are all the changes that occurred." See OT change management for how the two layers fit together.
In a regulated environment, both are necessary. The change control record demonstrates governance. The configuration monitoring record demonstrates completeness. The combination — where every change either has a change control record or appears as an unexplained deviation — is what gives QA teams confidence that the record is genuine.
The regulatory case for continuous configuration monitoring
FDA 21 CFR Part 11, EU Annex 11, and GAMP 5 all address computerised system validation and the requirements for audit trails in GMP environments. While none prescribes a specific configuration management tool, the consistent theme is that audit trails should be computer-generated, should capture all relevant changes, and should be protected from modification.
A continuous, automated configuration monitoring system satisfies these requirements more robustly than a manual or procedural approach. It removes the dependency on human consistency. It produces a record that is time-stamped, attributed, and complete by construction — not by hope. The companion discipline at the network layer is covered in OT network qualification.