GxP Configuration Management: Baselines and Control

GxP configuration management keeps the approved system state visible. It covers more than source code. Roles, workflows, rules, interfaces, reports, master data, and settings can all change the validated outcome. The practical rule is to make the decision visible, connect it to evidence, and keep the approved state current.

Shortcut: Start with intended use, the record, and the failure that matters. Choose the evidence after that.

At a glance

Define the configuration item

Begin with an inventory of items that can affect the intended use. Include application version, modules, workflows, user roles, approval rules, calculations, interfaces, reports, controlled data, operating procedures, and relevant infrastructure settings. The list should reflect the process, not just what the supplier calls a release.

Give each item an owner, identifier, version or effective date, and relationship to the system baseline. Record what is controlled by the supplier and what is controlled locally. This prevents teams from assuming that an unchanged application binary means an unchanged regulated process. For GxP configuration management, keep the decision close to its evidence. A reviewer should be able to identify the accountable owner, the relevant record, and the reason the control is proportionate.

Create an approved baseline

A baseline is the approved reference state against which a proposed change is assessed. Capture enough detail to reconstruct the state, including configuration exports where available, role definitions, interface mappings, report versions, and effective procedures. Store the baseline under controlled access.

Avoid a baseline that is only a label such as “production current.” A reviewer needs to know what current means. Link the baseline to the approval, environment, date, responsible owner, and supporting validation evidence. If a setting cannot be exported, describe how it was inspected and recorded. For GxP configuration management, keep the decision close to its evidence. A reviewer should be able to identify the accountable owner, the relevant record, and the reason the control is proportionate.

Control access to settings

Configuration control fails if too many people can change settings without review. Use role-based access, least privilege, segregation where appropriate, and periodic review of privileged access. Test that permissions match the work people actually perform.

Keep administrator actions attributable. Where the system provides an audit trail, verify that configuration changes are recorded and reviewable. Where it does not, use a controlled change record and compensating procedure. The control should make it possible to explain who changed the state, why, when, and with what approval. For GxP configuration management, keep the decision close to its evidence. A reviewer should be able to identify the accountable owner, the relevant record, and the reason the control is proportionate.

Assess interfaces and reports

An interface can change the meaning of a record without changing the source application. Mapping, field transformation, timing, error handling, and duplicate management all belong in configuration scope. Reports also need control when users rely on filters, calculations, or status logic.

Test the parts of the configuration that matter to the process. Reconcile representative inputs and outputs. Include an error path. Confirm that changes are visible to the receiving process and that an operator can identify an incomplete or rejected transfer. Keep interface ownership shared when more than one team controls the flow. For GxP configuration management, keep the decision close to its evidence. A reviewer should be able to identify the accountable owner, the relevant record, and the reason the control is proportionate.

Tie configuration changes to evidence

A proposed change should identify the affected baseline items, reason, risk, required approvals, test or review activity, implementation plan, rollback approach, and post-change check. Do not let a ticket number stand in for impact reasoning.

After implementation, verify the actual state rather than assuming the deployment matched the request. Record the new version, evidence, deviations, and approval. If the result differs from the planned state, stop and assess it. The baseline should be updated only after the approved conclusion is clear. For GxP configuration management, keep the decision close to its evidence. A reviewer should be able to identify the accountable owner, the relevant record, and the reason the control is proportionate.

Keep configuration useful in an audit

A configuration register earns its place when it answers ordinary operating questions quickly. Can the owner identify the current role model? Can quality see which report version was approved? Can a change owner find the relevant test? Can an auditor follow the history?

Remove obsolete states from active use without deleting required history. Archive superseded baselines with their approvals and effective periods. A clean history is more useful than a large folder of similarly named exports. Configuration management is a control system, not a museum of screenshots. For GxP configuration management, keep the decision close to its evidence. A reviewer should be able to identify the accountable owner, the relevant record, and the reason the control is proportionate.

Put the method into practice

The method becomes useful when it is part of ordinary work. Use the following sequence for GxP configuration management, adapting the depth to the system and process risk:

1. Set the boundary: name the process, intended use, users, records, interfaces, and exclusions.
2. Identify the failure: describe what could go wrong and the effect on a regulated decision.
3. Choose the control: select preventive, detective, procedural, technical, or review controls that address the failure.
4. Define the evidence: write the expected result, data, owner, execution method, and approval point before work starts.
5. Challenge the edge: include abnormal, rejected, corrected, interrupted, or incomplete conditions where the risk requires them.
6. Confirm the state: compare the approved baseline with the actual configuration, records, roles, and operating procedure.
7. Close the loop: route failures through deviation, change, incident, or CAPA processes without rewriting the original result.
8. Set the next review: record the owner, review trigger, and signals that would require earlier assessment.

This sequence is deliberately plain. It gives business, quality, IT, suppliers, and reviewers a common way to discuss the work. It also makes the limits visible. A control is not complete because a document exists. It is complete when the intended result, evidence, ownership, and follow-up are clear.

Questions before approval

Before approving the record, ask questions that expose gaps rather than reward document volume:

• Can a new reviewer explain the intended use without asking the author to translate a product feature list?
• Can the evidence be tied to a risk or requirement by a stable identifier and current version?
• Can the process handle a failure without losing the original record, reason, owner, or escalation path?
• Can the team prove the actual state matches the approved configuration, procedure, role model, and interface map?
• Can an operator maintain the control during routine work, supplier change, incident response, and periodic review?
• Can the organisation state what remains uncertain and who accepted that residual risk?

If the answer is no, record the gap and decide whether it blocks release, needs a compensating control, or belongs in a controlled follow-up. That is more useful than hiding uncertainty behind a pass label.

Keep the decision connected to the current system, process, owner, and evidence. Review the record when the service, configuration, workflow, data flow, or regulated use changes. That small discipline prevents yesterday’s approval from being treated as proof of today’s state.

What does not solve the problem

A large document count is not proof of control. A copied supplier statement, an unsigned template, a risk score without an action, or a screenshot without context can create the appearance of diligence while leaving the important question unanswered. The useful measure is whether a competent reviewer can understand the decision and reproduce the conclusion.

Frequently asked questions

What belongs in a GxP configuration baseline?

Include application version, roles, workflows, rules, interfaces, reports, relevant master data, procedures, and other settings that affect the intended use.

Who may change configuration?

Only authorised personnel under the defined change process. Privileged access should be limited, attributable, and periodically reviewed.

Is an application release the only configuration change?

No. A role, mapping, report, workflow, rule, or master-data change can alter the approved state without changing the application binary.

How often should baselines be reviewed?

Review them when changes occur and during periodic review. Frequency should reflect system risk and the pace of change.

Conclusion

GxP configuration management keeps the approved system state visible. It covers more than source code. Roles, workflows, rules, interfaces, reports, master data, and settings can all change the validated outcome. Put the next decision on the lifecycle map, assign its owner, and define the evidence before work starts. That is how GxP configuration management becomes an operating discipline rather than a once-a-year exercise.