GxP / Guide 7
Change control and configuration management
Change classes, impact on the validated state, pipelines as change records, drift detection, patching validated systems, and emergency changes.
A validated system stays validated only if every change to it is assessed, approved, tested and recorded. On premises, change control meant a form and a CAB meeting. In the cloud, change is far more frequent, so the goal is a process where the safe path is also the fast one: most changes flow through a pipeline that records itself, and humans spend their time on the few changes that could affect GxP data.
Change classes
| Class | Examples | Approval | Testing |
|---|---|---|---|
| Standard (pre-approved) | Monthly OS patching, adding a user to a role, scaling within qualified limits, certificate renewal | Procedure approved once by QA; each run recorded | Automated checks defined in the procedure |
| Normal, low impact | New alert rule, tag changes, a new non-GxP resource in a GxP subscription | System owner and IT | Verification in the change record |
| Normal, GxP impact | Application upgrade, database version change, network change affecting data flow, new interface | System owner, QA, IT | Risk-based regression and new function tests in validation first |
| Emergency | Security fix under active exploitation, restoring service | Named emergency approver, recorded at the time | Minimum needed, then retrospective review and testing within a set number of days |
Getting the standard class right is what makes GxP change control workable. Write the procedure once, including its tests and rollback, have QA approve it, and each run becomes a record rather than a meeting.
Impact assessment
Every normal change needs a short, honest impact assessment. The questions that matter:
- Does it touch a function or setting that a user requirement relies on? (Trace to the URS.)
- Could it change how GxP data is created, calculated, stored, transferred or displayed?
- Does it affect audit trails, access control, backup, time or logging?
- Does the validation environment need the change first, and which tests must be re-run?
- Do procedures, training or the system's documentation need updating?
Record the answer and the reasoning. "No GxP impact because the change only affects the monitoring agent's alert thresholds" is an assessment; "N/A" is not.
Pipelines as change records
When infrastructure and configuration live in code, the delivery pipeline can be the change record:
- A pull request links to the change ticket, describes the change and impact, and is approved by someone other than the author.
- Branch protection stops anyone from merging without review, and stops direct pushes to the main branch.
- The pipeline deploys to validation, runs automated tests and evidence checks, and waits for an approval gate before production.
- The run history keeps who approved, what commit was deployed, when, and the test results.
Validate the pipeline itself (it's a GAMP category 1 or 4 tool, depending on how much you configured it) and control changes to it, because it now enforces your change process.
Stopping changes outside the process
The biggest risk is a change that bypasses the process: a portal click at 2 a.m. that nobody records. Reduce who can make them, and detect them when they happen:
- Prevent: no standing write access to GxP production for people; changes through the pipeline's identity. On Azure, deployment stacks with deny settings and resource locks; on AWS, SCPs and permission boundaries that only allow the deployment role to change core resources.
- Detect: Azure Policy compliance and activity log alerts on writes by anyone other than the pipeline identity; AWS Config rules, CloudFormation drift detection and EventBridge rules on CloudTrail events from human roles.
- Respond: treat an unexplained change as a deviation: record it, assess impact, then either bring it into the code through change control or revert it.
Patching validated systems
Unpatched servers are a GxP risk too: inspectors now treat known, exploited vulnerabilities as a data integrity problem. A workable pattern:
- Classify OS and database patching of GxP servers as a standard change, with a QA-approved procedure.
- Patch the validation environment first, run automated smoke tests of critical functions (application starts, users sign in, a test record is created, audit trail entry appears, interfaces pass data).
- Patch production in its window with Azure Update Manager or AWS Systems Manager Patch Manager, then run the same checks.
- Keep the patch compliance report and test results as the record.
Application upgrades and database version changes are normal changes with GxP impact, and need regression testing based on risk.
Configuration baseline
Keep a baseline for each GxP system: the IaC repository at a tagged version, plus application configuration exported or documented. At periodic review (Guide 10), compare the running system to the baseline and explain every difference. Evidence scripts help here, because they check the settings your validation assumed: logs exported, backups running, access limited.