Software/Firmware
Configuration Baseline Record FAQ

General system documentation, like a URS or functional specification, describes what the system is supposed to do; a configuration baseline is the specific, point-in-time record of the exact settings, parameters, firmware or software version, and options actually configured in the live system — it's the difference between describing intended behaviour and recording the precise configuration that produces it.

Two systems can have identical general documentation but different configuration baselines if they were set up with different parameter values, and it's the baseline, not the general documentation, that lets you reproduce or verify a specific system's actual configured state.

Yes — a standalone instrument's firmware version and any configurable parameters need their own documented baseline, just as a server-based system does, since the same risk of undetected drift or an unverified update applies regardless of whether the software runs on a server, a networked application, or embedded firmware inside a piece of equipment.

The baseline should comprehensively capture GxP-critical settings — those affecting calculations, acceptance criteria, security, audit trail behaviour, or data handling — in full detail, while purely cosmetic or user-preference settings with no GxP impact can often be excluded or documented at a lighter level, provided that scoping decision is itself documented and risk-based.

The configuration baseline record is the current, definitive snapshot of a system's approved configuration state, while the change control record is the document that authorises and tracks the transition from one baseline to the next — change control drives the process of updating the baseline, but the baseline itself is the resulting reference document that reflects the system's currently approved state.

Fixed, GxP-critical settings should be captured as part of the formal, change-controlled baseline, while parameters that operators are legitimately expected to adjust during normal use — such as a process recipe parameter within an approved range — should be documented as an approved adjustable range in the baseline rather than a single fixed value, so routine, authorised adjustment within that range isn't mistaken for unauthorised drift.

A reproducible baseline is typically captured through a combination of an exported configuration file or report generated directly from the system, screenshots or documented values for settings that can't be exported, and the exact software or firmware version — ideally using an automated export or configuration management tool rather than manually transcribing settings, which is far more error-prone.

A new baseline is typically established following a significant change — a major version upgrade, a substantial reconfiguration, or a change affecting multiple GxP-critical settings at once — while minor, individual setting changes are usually documented as incremental updates to the existing baseline through change control, without needing to treat the entire configuration as a brand-new starting point.

This should be treated as a deviation — the baseline no longer accurately reflects the system's actual state, which undermines any subsequent verification or drift detection relying on it — and the corrective action should include immediately documenting the actual current configuration and investigating why the update bypassed the change control and baseline update process.

If the previous baseline was documented and archived, rolling back can revert to that prior documented baseline, provided it's confirmed the rollback genuinely restored the system to that exact prior state; if the rollback doesn't fully match the archived baseline, or no prior baseline was properly documented, a new baseline capture is needed to accurately reflect the system's actual post-rollback configuration.

Complex, multi-module systems generally need a baseline structured by module or functional area, each capturing its own GxP-critical settings, rather than one undifferentiated document — this makes it practical to update the baseline for a change affecting one module without having to fully reassess and reissue the baseline for the entire system.

Drift is typically detected through periodic verification checks that export or review the live configuration and compare it against the documented baseline, ideally supplemented by automated configuration monitoring tools that can flag a discrepancy in near real time rather than waiting for the next scheduled periodic review to catch it.

Verification involves exporting or extracting the system's current configuration using the same method used to originally capture the baseline, then comparing it setting by setting against the documented baseline, with any discrepancy investigated to determine whether it was an authorised change that simply wasn't reflected in the baseline update, or genuine unauthorised drift.

Genuine unauthorised drift — a configuration change with no corresponding change control record — should be treated as a deviation, with an assessment of what the changed setting actually affected and whether any GxP data or decisions were impacted while the system was in the drifted state; drift that turns out to be an authorised change simply missing from the baseline documentation is a lower-severity documentation gap, but still needs correcting.

For GxP-critical systems, a re-verification check after an unplanned reboot or power failure is good practice, since some systems can revert certain settings to a default state on restart, or a power event could coincide with an incomplete configuration write — a quick post-restart verification confirms the baseline is genuinely intact rather than assuming it is.

Yes — a vendor-pushed update to cloud-connected equipment still changes the qualified configuration baseline and needs to be assessed through change control before or immediately after it's applied, and the update mechanism itself should be evaluated to confirm the organisation retains visibility and control over when vendor-pushed changes actually reach GxP-critical equipment, rather than updates happening silently outside the site's own change management process.

Yes — interface and integration configuration, such as data mapping rules, API settings, or interface protocol versions connecting a system to another GxP system, should be part of the configuration baseline, since a change to these settings can silently break or alter data flow between systems in ways that are easy to miss if only each system's internal settings are tracked.

An inspection-ready baseline record should let a reviewer confirm the exact software or firmware version, every GxP-critical setting and its configured value, the date the baseline was established or last updated, and a reference to the change control record authorising the current state.

• System or equipment identifier and current software/firmware version.
• GxP-critical configuration settings and their approved values.
• Integration and interface settings with connected systems.
• Date the baseline was established or last updated.
• Reference to the change control record authorising the current baseline.
• Verification history confirming live configuration matches the documented baseline.

Configuration baseline records, including superseded prior baselines, should be retained for at least as long as the system remains in GxP use plus the site's standard retention period after decommissioning, since a historical baseline may be needed to explain the system's configuration during a period being investigated well after that configuration has since changed.

Inspectors typically compare the documented baseline against the system's actual live configuration to check for undetected drift, confirm that past configuration changes trace back to approved change control records, and check whether periodic verification of the baseline is genuinely being performed rather than existing only as a one-time document from initial qualification.

A frequent finding is a baseline document that was created during initial validation and never updated since, even though the system has clearly undergone changes — this suggests the baseline stopped being an active control shortly after go-live.

The most common mistake is treating the configuration baseline as a one-time deliverable from initial qualification rather than a living reference that's actively maintained and periodically verified against the system's real, current state — once the baseline stops being updated, it silently loses its value as a control, and nobody notices until an inspector or an investigation actually needs to rely on it.