Configuration Management and Baseline Standard

This is a ready-to-use configuration management standard. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach your configuration item register and tool references, and route it through your normal document control, review, and approval. Configuration management is the discipline that keeps the validated state of a system knowable: it records every part of the system that affects GxP function or data integrity, fixes those parts at an approved value (the baseline), controls how that value changes, and detects when the live system has quietly drifted away from what was approved. A worked filled specimen of a baseline record follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This standard defines how <<FILL: COMPANY NAME>> identifies, records, baselines, version-controls, and verifies the configuration of GxP computerized systems and their infrastructure. The objective is that the validated state of every in-scope system is documented, that any change to that state is deliberate and controlled, and that the live system can be shown, at any time, to match its approved baseline. Configuration management is what lets you answer, on the day of an inspection, the single question an inspector returns to: is the system today still the system you validated, and how do you know.

2. Scope

This standard applies to all GxP computerized systems and the infrastructure they depend on at the sites listed in the header, across the full lifecycle from initial baseline at release to retirement. In scope are applications, their as-configured settings, custom code, databases and schemas, operating systems and middleware, network and security configuration that bears on the validated state, and qualified infrastructure platforms. It works alongside change control, which authorizes changes, and periodic review, which confirms ongoing control. It does not replace either. Out of scope are non-GxP systems and <<FILL: any platform governed elsewhere, e.g. the corporate end-user device fleet>>, governed by <<FILL: cross-reference IDs>>.

3. Definitions

• Configuration item (CI): any component whose state must be controlled because a change to it could affect GxP function, a regulated calculation, data integrity, or security. A CI can be a piece of software, a setting, a script, a database, a server, a document, or an interface.
• Configuration item register (CMDB): the controlled list of all CIs, their attributes, their relationships, and their current approved version. The single source of truth for what makes up each system.
• Baseline: a formally reviewed and approved snapshot of the configuration of a system, or part of a system, at a point in time, that thereafter serves as the reference for development, build, qualification, and change. The validated baseline is the baseline that the qualification evidence was produced against.
• Version control: the controlled recording of successive versions of a CI such that any prior version can be identified and, where it is code or documents, retrieved unchanged.
• Drift: a difference between the live configuration of a system and its approved baseline that arose without a change record. Drift is, by definition, uncontrolled change.
• Drift detection: the activity, manual or tool-based, that compares the live configuration to the baseline and surfaces drift.
• Baseline verification: a periodic confirmation that the live configuration still matches the approved baseline, or that every difference is explained by an approved change.

4. Responsibilities

5. Configuration item identification

5.1 What to put under configuration management

A CI is anything whose uncontrolled change could break the validated state. Identify CIs at the level you can actually control and verify, not so coarse that a change hides inside a CI, and not so fine that the register is unmanageable. As a default, place the following under control for each system:

5.2 The configuration item register

Every CI is recorded in the register with a stable, unique ID that is never reused. The register is the authoritative inventory; if a CI is not in it, it is not under control.

State the source of record for the register: <<FILL: a validated configuration management database, OR a controlled spreadsheet under document control if no CMDB tool is used>>. If the register itself is a spreadsheet, it is itself a CI and is version-controlled and access-restricted.

6. Baselines

6.1 When a baseline is set

A baseline is established at defined points so that there is always a known, approved reference. At minimum:

6.2 What a baseline contains

A baseline is a complete snapshot, not a summary. It records the exact version of every CI that makes up the system at that point, captured so it can be reproduced or compared against later. A baseline record (section 11) carries, at a minimum: the baseline ID and date, the system and its release, every CI and its version, the change records that moved the system to this state since the last baseline, the evidence the baseline was captured from a real system, and the approval. Do not record “current version” loosely; record the actual version string, tag, or configuration export reference for each CI.

6.3 How a baseline is approved

The system owner reviews the baseline record for completeness and correctness, confirms it reconciles to the change records since the prior baseline, and confirms it was captured from the live system, not from intent or from a design document. Quality Assurance approves. Once approved, the baseline is frozen: it is a controlled record and is not edited. A subsequent change produces a new baseline; it does not amend an approved one.

7. Version control

7.1 Principles

Every CI carries a version. Versions advance only through controlled change, never silently. A prior version is always identifiable, and where the CI is source code or a controlled document, the exact prior version is retrievable, unchanged. Two systems with the same baseline ID must be the same system. The deployed instance of a coded CI traces to a specific repository tag, and the tag is what was reviewed and tested.

7.2 Version control by CI type

State the versioning convention once and apply it everywhere: <<FILL: e.g. semantic versioning MAJOR.MINOR.PATCH for code; date-based versioning for configuration exports>>. Numbers are not reused; a superseded version is retired, not overwritten.

8. Link to change control

Configuration management and change control are two halves of one control. Change control decides whether a change is allowed and assesses its impact; configuration management records the before and after state and keeps the register and baseline current. They are joined by an explicit rule: no CI changes in production except through an approved change record, and no change record closes until the configuration item register and, where the change altered the validated state, the baseline are updated.

For every change that alters a CI, the change record states the CI ID, the old version or value, the new version or value, the qualification or regression testing performed, and the new baseline ID produced. At change closure, the configuration manager reconciles the change to the register, advances the CI version, and the system owner confirms the updated baseline. A change that is approved but never reflected in the register, or a register entry that advanced with no change record behind it, are both findings: the first means the record is stale, the second means the change was uncontrolled. Cross-reference: change control SOP <<FILL: change control SOP-ID>>.

9. Drift detection

Drift is uncontrolled change: a live setting, file, version, or privilege that differs from the approved baseline with no change record to explain it. Drift is detected, not assumed absent.

9.1 How drift is detected

9.2 Frequency by risk

Set drift-detection frequency from the GxP criticality of the system. Document the basis for each system in the register.

9.3 Responding to detected drift

Any detected difference is one of two things, and you must determine which:

1. An authorized change that was not reflected in the register or baseline. Correct the record: update the register and baseline, and close the gap that let the record fall behind.
2. An unauthorized or unexplained change. Open a deviation per <<FILL: deviation SOP-ID>>, assess impact on data and product made while the system was off-baseline, restore the approved configuration or formally accept and re-baseline the new state through change control, and address the access or process gap that allowed the change.

Do not silently re-baseline drift. Re-baselining an unexplained difference without an investigation hides an integrity problem; the difference must be explained before the new state is accepted.

10. Periodic baseline verification

At a defined interval, and as part of periodic system review, confirm that the live configuration still matches the approved baseline or that every difference traces to an approved change. This is the planned, documented backstop to continuous drift detection.

A periodic review that asserts “configuration unchanged” without an actual comparison against the baseline is an assertion, not evidence, and inspectors treat it as such. Cross-reference: periodic review SOP <<FILL: periodic review SOP-ID>>.

11. Record generated: baseline record

This is the controlled record produced when a baseline is set. Complete one per baseline event.

12. Acceptance criteria

Configuration management for a system is in control when all of the following are true:

• Every GxP-relevant CI is in the configuration item register with a stable ID, an owner, and a current approved version.
• An approved validated baseline exists, was captured from the live system, and is reconcilable to the change records since the prior baseline.
• Every CI is version-controlled, prior versions are identifiable, and coded CIs trace from the deployed build to a specific tag.
• No CI has changed in production without an approved change record, and every closed change is reflected in the register and baseline.
• Drift detection runs at a risk-based frequency, and any detected drift was investigated and resolved, not silently re-baselined.
• Periodic baseline verification has been performed and signed, with every difference explained by an approved change.

13. References

21 CFR Part 11 (electronic records and signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (Computerised Systems), section 4.3 (inventory of systems) and section 10 (change and configuration management). EU GMP Annex 15 (Qualification and Validation), 2015 revision. ISPE GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems (2nd edition), configuration management and the configuration item concept. FDA Guidance, Computer Software Assurance for Production and Quality Management System Software (issued 3 February 2026, superseding the 24 September 2025 final). PIC/S PI 011, Good Practices for Computerised Systems in Regulated GxP Environments. ICH Q9, Quality Risk Management (for risk-based drift-detection frequency). IEC 62304 (medical device software lifecycle: configuration management), where the system is or contains a medical device. 21 CFR Part 820 (QMSR), effective 2 February 2026, incorporating ISO 13485:2016 by reference, where applicable.

Confirm the current version and clause numbers of each reference before issue.

14. Attachments

15. Revision history

16. Approvals

Filled specimen

The following shows a baseline record completed for an example laboratory information management system after a configured-report change, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.

Configuration items and versions (extract):

In this example the configuration manager captured the baseline from the live production system rather than from intent, reconciled it to the two changes closed since the prior baseline, found one setting that did not match (a 20-minute timeout against the approved 15), refused to re-baseline it silently, opened a deviation, restored the approved value, and only then put the baseline forward for approval. The two authorized changes advanced their CI versions; the unexplained difference was caught as drift. That sequence, capture to reconcile to drift-caught to deviation to restore to approve, is exactly what a reviewer is expected to demonstrate.

Common inspection findings this standard prevents

• No configuration item register, so no one can state what the system is actually made of or what version each part is at.
• A baseline that was written from the design specification or from intent, never captured from the live system, so it cannot prove the running system matches it.
• Live settings that differ from the approved configuration with no change record, that is, uncontrolled drift that no one detected because no comparison is ever run.
• Drift found and quietly re-baselined as the new “approved” state, with no investigation of how the change happened or what data it affected.
• Closed change records that never updated the register or the baseline, so the controlled record is stale and the validated state is unknown.
• Custom code or configured reports in production that trace to no repository tag, so the deployed version cannot be shown to be the version that was reviewed and tested.
• A periodic review that asserts “no changes” without any actual comparison of the live configuration against the baseline.
• Version numbers reused or overwritten, so a prior validated state can no longer be identified or retrieved.

How to adapt this standard

1. Set your document number, owner, and effective date in the header, and link your change control, CSV, periodic review, and backup procedures.
2. Decide your CI granularity in section 5 and list the CI categories your systems actually have; record which form your register takes, a validated CMDB tool or a controlled spreadsheet.
3. Confirm the baseline points in section 6 match your lifecycle, and set who approves a baseline and a re-baseline.
4. State your one versioning convention in section 7 and apply it across code, configuration, schema, documents, and infrastructure.
5. Set drift-detection frequency by system criticality in section 9, and name the tool or the manual method you will actually use.
6. Align periodic baseline verification in section 10 to your periodic review cycle and point the cross-reference to your periodic review SOP.
7. Confirm every regulation in section 13 against the current published version before issue.