IT Change and Configuration Management for GxP: Bridging ITIL and Validation

A validated GxP system does not sit still. The operating system underneath it gets patched on Patch Tuesday. The database engine reaches end of support and has to move a major version. The virtualization host is migrated to new hardware. A security team pushes a configuration change to a load balancer at 2 a.m. to stop an active exploit. Every one of these touches the validated state, and most of them are driven by an IT organization that runs on ITIL, not on 21 CFR Part 11.

The job of IT change and configuration management for GxP is to make those two worlds meet without either breaking the validated state or grinding IT operations to a halt. This page covers how patch management, emergency change, and the configuration management database (CMDB) work in a regulated shop, and exactly where the ITIL change record hands off to the validation change control record.

If you have not already, read Change Control for Validated Systems and GxP Computerized Systems Operations first. This article assumes you know what a validated system is and focuses on the IT-operations layer underneath it.

Why this is a regulated activity, not just IT housekeeping

A computerized system that supports a GxP decision must remain in its validated state for as long as it is in use. That principle is not subtle in the regulations.

EU GMP Annex 11 (2011), clause 10 requires that any change to a computerized system, including its system configurations, be made only in a controlled way and under a defined procedure.

EU GMP Annex 11 (2011), clause 8.1 requires the ability to obtain clear printed copies of electronically stored data, and clause 12.1 requires physical and/or logical controls that restrict system access to authorized persons. A configuration change to access control is therefore a regulated change.

The US side rests on the predicate rules. 21 CFR 211.68(a) requires that automatic, mechanical, or electronic equipment used in manufacture, processing, packing, or holding be “routinely calibrated, inspected, or checked according to a written program designed to assure proper performance.” 21 CFR 211.68(b) requires that “appropriate controls” be exercised over computer systems to assure that changes are “instituted only by authorized personnel.” 21 CFR 11.10(j) requires written policies that hold individuals accountable for actions taken under their electronic signatures, and 11.10(a) requires validation of systems to ensure accuracy, reliability, and consistent intended performance. Most directly on point for this article, 11.10(k)(2) requires revision and change control procedures that maintain an audit trail documenting the time-sequenced development and modification of systems documentation.

The practical translation: an OS patch, a database upgrade, a firmware update, a TLS certificate rotation, or an access-control tweak on a GxP system is a change to a validated computerized system. It has to be controlled, risk-assessed, and documented, and the validated state has to be re-established or shown to be intact before the system is used for GxP work again.

GAMP 5 Second Edition (ISPE, 2022) frames the same thing through the lifecycle: infrastructure and operational processes (change management, configuration management, backup, security, incident management) are part of keeping a system fit for intended use across the operational phase. The PIC/S guidance PI 011-3 “Good Practices for Computerised Systems in Regulated GxP Environments” reinforces that change control must cover the full system, including the platform and infrastructure it runs on, not only the application.

A revision is coming: draft Annex 11 and the new Annex 22

The Annex 11 you control to today is the 2011 version, and it is the in-force text. But a substantial revision is moving. On 7 July 2025 the European Commission published, for stakeholder consultation, a draft revised Annex 11 on computerised systems, a brand-new draft Annex 22 on artificial intelligence in manufacturing, and an updated Chapter 4 on documentation. The consultation ran three months and closed on 7 October 2025. As of August 2026 the texts are still drafts: EMA convened a further Annex 22 expert workshop on 30 June and 1 July 2026, the concept paper’s mid-2026 publication target has slipped, and final versions are now expected no earlier than 2027, after which a transition period is likely before compliance is mandatory.

For IT change and configuration management, the direction of travel matters now even though the text is not yet final. The draft Annex 11 expands from a short document into a far more detailed framework that addresses cloud computing, cybersecurity, and data integrity with much greater specificity than the 2011 version, which is exactly the territory this article covers. The draft Annex 22 brings AI and machine-learning models under explicit lifecycle expectations including change control, performance monitoring, and human review. Do not rewrite your procedures around a draft, and do not cite draft clause numbers as if they were in force. Do track the revision, because a patch, a cloud change, or a model update that is lightly governed under the 2011 text may sit under sharper expectations once the revision lands. Verify the published status and effective dates before you rely on either annex.

The risk rationale is concrete. A patch can silently change a rounding behavior, break a report, alter a time-zone handling, or disable an audit trail. A database upgrade can change a collation that reorders query results that feed a release calculation. A firewall rule can cut off a time server and let a system clock drift. None of these are application “features,” yet every one can corrupt GxP data or invalidate a result. That is why infrastructure change is in scope.

ITIL and GxP: same goal, different vocabulary

ITIL (the IT service management framework, current version ITIL 4) gives IT a mature, well-understood machine for handling change and configuration. GxP change control gives quality a defensible, regulator-facing record. They overlap heavily but are not the same, and confusion at the seam is where findings happen.

The single most important design decision in a regulated IT shop is how the ITIL change process and the validation change control process connect. Two patterns work:

• One process, GxP-aware. The ITIL change tool is configured so that any change flagged as touching a GxP system triggers extra mandatory fields (validation impact assessment, QA approval, regression test reference) and routes to Quality. There is one change record per change.
• Two processes, linked. IT runs its ITIL change in its tool; when the change touches a GxP system, a linked validation change control record is opened in the quality system and the two are cross-referenced. The GxP record gates go-live.

Both are acceptable. The failure mode is a third pattern that exists by accident: IT makes the change under ITIL, Quality never sees it, and the validated state is altered with no GxP record. Inspectors find this by sampling the IT change log and looking for GxP systems that changed without a corresponding quality record.

The configuration management database (CMDB) and the configuration baseline

What it is and why it matters

A CMDB is the inventory of configuration items and their relationships: which application runs on which server, which database, which OS build, which network segment, which storage. In ITIL it is the backbone of change and incident management. In GxP it serves a second purpose: it is part of how you prove you know the boundary of your validated system and its current configuration.

GAMP 5 and Annex 11 both expect that you can describe the system, its components, and its environment. Annex 11 clause 4.3 requires an up-to-date listing of relevant systems and their GMP functionality. The CMDB, when kept honest, is a large part of that evidence.

What goes in it for a GxP system

A useful CMDB entry for a validated system, at minimum:

• CI identifier and friendly name
• GxP classification (GxP / non-GxP) and the data criticality it handles
• GAMP software category (1 infrastructure, 3 non-configured, 4 configured, 5 custom) for context
• System owner, business owner, QA contact
• Validation status (validated, in validation, retired) and link to the validation summary report or system file
• Software versions: application, OS, database, middleware, firmware where relevant
• Configuration baseline reference (the controlled record of the configured settings)
• Hosting model (on-premises, virtual, IaaS, SaaS) and physical or logical location
• Relationships: depends-on / depended-on-by (the application depends on a database CI, which depends on a server CI, which depends on a storage CI)
• Patch and maintenance window
• Backup configuration reference and last successful restore test

The configuration baseline

The CMDB tells you what the system is. The configuration baseline tells you how it is configured: the specific settings that were verified during validation and that, if changed, would require assessment. Examples of baseline-controlled settings:

• Audit trail enabled, and the events it captures
• Time synchronization source and time-zone handling
• Password and account-lockout policy
• User roles and the privileges attached to them
• Data retention and archival settings
• Calculation parameters, rounding rules, and significant-figure settings
• Interface and integration endpoints
• Report templates that produce GxP output

The baseline is established at the end of validation and is the reference point for every future change. A change is, by definition, a deviation from the baseline that must be controlled and then folded back into a new baseline.

Acceptance criteria for the CMDB

You know the CMDB is doing its GxP job when:

• Every GxP application in the validated system inventory has a corresponding CI, and the two lists reconcile with no orphans on either side
• For any GxP CI you can answer, in under a minute, “what version of OS and database is it on, and when was it last patched”
• A periodic reconciliation runs (commonly quarterly) and discrepancies are investigated, not just corrected silently
• The configuration baseline for each system exists, is version-controlled, and matches the running system at the time of a periodic review

The classic finding is a CMDB that drifted: it says the database is version X but production has been on X+1 for eight months because a DBA upgraded it under an IT change that never reached Quality. The CMDB looks complete on paper and is wrong in fact.

Patch management: the day-to-day battlefield

Patching is where IT change and GxP collide most often, because it is high-volume, vendor-driven, and security-urgent. The goal is a risk-based, repeatable program, not a per-patch panic.

The regulatory hook

There is no regulation that says “you must apply every patch,” and there is none that says “you may never patch.” Annex 11 clause 10 (controlled change), 211.68(b) (changes by authorized personnel), and Part 11.10(a) (maintained validated state) together mean: patches are changes; assess them, control them, and keep the system validated. Security guidance pulls in the same direction. The FDA’s posture on legacy systems and on medical device cybersecurity, and the general expectation that you maintain a secure environment, mean that not patching a known-exploited vulnerability is itself a quality and compliance risk. You cannot hide behind “validation” to run a system with an unpatched critical vulnerability.

A risk-based patch classification

Build a small, documented decision model and apply it to every patch or patch group. A workable scheme:

A security-only patch with no change to the application’s GxP behavior can usually be pre-approved as a standard change with a defined, repeatable regression test, so it does not need a fresh full change control every month. That is how you keep patching at IT speed without abandoning control. What makes it defensible is the documented rationale (vendor release notes reviewed, no GxP-relevant change identified), the standing regression test, and a record that it ran and passed.

Risk-based remediation timelines

Classification tells you how to route a patch; severity and exposure tell you how fast it has to land. Set a target remediation window for security patches from the vulnerability severity and how exposed the system is, and track open items to closure against it. A patch backlog with no timeline is how a known-exploited vulnerability quietly ages on a GxP server for a year. The windows below are illustrative defaults to adapt to your own risk policy, not regulatory figures.

The point is not the exact numbers, which you set, it is that the window is defined, risk-based, and tracked. “It is validated” is never a reason to leave a known critical vulnerability open; an unpatched, actively exploited flaw on a GxP system is itself a quality and compliance risk. The Patch Management SOP carries this table as a fillable policy and ties it to the standing regression test.

Step-by-step patch procedure

1. Intake and triage. Vendor or security team announces patches. The system owner and a CSV or IT-quality person review the release notes and security advisories. Classify each patch using the model above. Record the classification rationale, especially the “no GxP-relevant change” judgment.
2. Impact assessment. For normal and major changes, assess: does this touch a baseline setting, a calculation, an audit trail, an interface, a report, time handling, or access control. List affected GxP functions. Decide the testing needed.
3. Schedule and approve. Pre-approved patches go into the standing maintenance window. Normal and major changes get a change control record approved by the owner, QA, and, where relevant, the vendor or SME.
4. Test in a non-production environment. Apply to a qualified test or staging environment that mirrors production. Run the regression test set: the GxP-critical functions, the reports, the interfaces, the calculations, an audit-trail spot check, and a login/role check.
5. Back up and snapshot production. Before applying to production, take a verified backup and, for virtual systems, a snapshot or restore point. Confirm the rollback path actually works, not just that it exists.
6. Apply to production in the window. Apply, then run the production verification: a smoke test of the GxP-critical paths and a confirmation that the audit trail still records.
7. Update records. Update the CMDB version fields, the configuration baseline if a setting changed, and close the change record with the test evidence attached.
8. Periodic review. At periodic review, confirm the running versions match the CMDB and that all patches applied since the last review have a record.

Acceptance criteria for the patch program

• Every GxP system has a defined patch policy (cadence, classification model, who approves)
• A patch backlog report exists and known critical vulnerabilities on GxP systems are tracked to closure with risk-based timelines
• Pre-approved patch changes carry a standing regression test that is actually executed each cycle, with evidence
• Test-environment results precede every production change for normal and major patches
• No GxP system is found running a version that has no corresponding change record

Emergency change: doing it right under pressure

Emergency change is the highest-risk path because the normal gates are compressed or moved after the fact. It is also unavoidable: a failed disk, an expired certificate that just took the system offline, an actively exploited vulnerability. Regulators do not object to emergency change. They object to emergency change with no record, no QA awareness, and no retrospective assessment of the validated state.

What makes an emergency change defensible

• A pre-defined emergency change procedure exists before you need it, with named authorizers reachable out of hours
• The minimum necessary change is made to restore service or security, nothing more
• The change is recorded contemporaneously or as close to it as the emergency allows, even if it is a phone-authorized verbal approval logged immediately after
• A retrospective review by QA happens within a defined window (commonly 1-3 business days), assessing impact on the validated state and on data
• Any data created or modified during the unstable period is reviewed for integrity
• If the emergency fix altered a baseline setting, a follow-up normal change formalizes and fully tests it

Worked emergency-change example

A GxP chromatography data system loses TLS connectivity because the server certificate expired overnight, blocking analyst logins. The on-call IT engineer:

1. Invokes the emergency change procedure, gets verbal authorization from the duty manager, and logs the emergency change record with timestamp.
2. Installs a new valid certificate (a like-for-like replacement of an expired credential, no change to application logic).
3. Confirms analysts can log in, the audit trail records, and no data was written during the outage.
4. Files the contemporaneous record with screenshots and the new certificate details.
5. QA reviews within two business days, confirms the change was a like-for-like certificate rotation with no impact on the validated state or on data, updates the CMDB certificate-expiry field, and closes the record.

This is clean because the change was minimal, recorded, and reviewed, and the validated state was never actually altered. Contrast with the bad version: the engineer also “took the opportunity” to bump the OS to the latest build because it was right there, told no one, and the next report run produced a different time-zone stamp. Now you have an undocumented major change discovered through a data anomaly.

Worked example: a fleet-wide zero-day emergency change

The single-system certificate example above is the common case. The harder case is a security team finding an actively exploited vulnerability in a component deployed across many GxP systems at once, a widely used web server package, for instance, running on a LIMS, a manufacturing execution system, a chromatography data system, a document management system, and an electronic lab notebook.

1. Fleet identification. The security team queries the CMDB for every CI running the vulnerable component version, which is exactly the payoff of keeping the CMDB accurate: a five-minute query instead of a week of asking around.
2. One parent record, several child records. A single emergency change is opened describing the vulnerability and the fix, with a linked child emergency change record per affected system, because each system has a different owner, a different QA reviewer, and different verification evidence. The parent record carries the shared facts, the vulnerability, the patch, the shared regression approach, and each child carries the system-specific authorization, execution, and sign-off.
3. Triage by exposure, not by convenience. Internet-facing or high-exposure systems move first, on the shortest remediation window; internally segmented systems follow on the standard critical window. Not every system in the fleet patches at the same hour, and that is correct, not a shortcut.
4. A shared smoke test where the systems share the same component. Because the vulnerable component and the fix are identical across systems, one smoke test, does the service restart clean, does the process respond, is the certificate or configuration intact, runs on each system rather than being reinvented five times, while the GxP-specific verification, login behavior and audit trail confirmation, still runs per system.
5. One system fails and is handled on its own. Say the patch breaks a legacy integration on the document management system that the other four systems do not have. That system alone rolls back to its tested restore point and escalates to a deviation while the rest of the fleet closes cleanly. A fleet action does not mean a fleet disposition; each system’s outcome stands on its own evidence.
6. QA retrospective review, batched but not blurred. QA confirms the same root cause and the same fix across the fleet in one sitting, but still performs the system-specific data-integrity check on each system’s unstable window, because different systems had different users and different data moving at the moment of patching.
7. One trend entry, not five. The change-control metrics register records this as a single fleet-driven emergency event with five linked records, not five unrelated blips in the emergency-change rate. Counting it as five independent events would inflate the trend past what it represents; rounding it down to one uncounted line would hide how much exposure a single vulnerability actually created.

This generalizes past one example: a CMDB that can answer “everywhere this version runs” in minutes, and a change-control tool that can link one root cause to many system-specific records, are what make fleet-wide speed possible without trading away the per-system QA accountability that makes any of it defensible.

See Deviation Management for how a botched emergency change becomes a deviation, and Backup, Restore, and Disaster Recovery Validation for the rollback evidence the procedure depends on.

The handoff: where ITIL change control becomes GxP change control

This is the interface that earns or loses inspection points. Draw it explicitly in your procedures.

The triage gate

Every change request hitting the IT change process must pass through a GxP-impact triage. The triage answers one question: does this change touch a system, or the infrastructure of a system, that is in the validated GxP inventory. The CMDB’s GxP classification flag is what makes this fast and reliable. If yes, the change cannot close on the ITIL side alone; it requires the GxP path (impact assessment, validation activities, QA approval).

The gate is a short decision, and drawing it as one keeps it from being skipped:

The gate is only as trustworthy as the CMDB flag behind it. If a GxP system is missing from the inventory or mis-flagged as non-GxP, its changes route around the gate silently, which is precisely the seam inspectors sample for.

Classifying the change once it is in the GxP path

The triage gate above answers one binary question. It does not say how fast the change has to move or how much testing it needs, and that is a second decision that deserves its own explicit routing rather than being worked out case by case in someone’s head. The patch classification model described earlier is one instance of a more general rule that applies to any infrastructure change, not only patches: a firewall rule, a load balancer configuration, a storage array firmware update, a hypervisor migration.

Two failure patterns show up around this tree, and both are worth naming. The first is routing straight to “emergency” for anything inconvenient, which is why the emergency work instruction insists on a genuine, pre-defined trigger and trends the emergency rate. The second is routing everything as “pre-approved” because a form for it exists, which is why the pre-approved path requires a standing regression test that is actually run, not a checked box. Route on the facts of the change, not for convenience, and audit the population, not just individual records, to catch drift toward either extreme; see the change control metrics register for how to trend that.

Roles and responsibilities at the seam

A worked end-to-end example: a database major-version upgrade

The database under a validated LIMS is reaching end of vendor support and must move from a major version to the next.

1. IT raises the RFC in the ITIL tool. The GxP-impact triage flags the LIMS as a validated GxP system. A linked validation change control record is opened in the quality system, cross-referenced to the RFC.
2. Impact assessment (CSV with the system owner and a LIMS SME): a major DB version can change collation, sort order, default date handling, and query performance. The LIMS uses sorted query results in a result-selection step and stores audit data in the DB. Assessed as high impact. Required: regression testing of result calculations, sort-dependent screens, audit-trail integrity, report output, and a data-comparison before and after.
3. Approval: system owner, QA, and CSV approve the change control. The vendor confirms supported upgrade path.
4. Execution in qualified staging: clone production data into a qualified staging LIMS, perform the upgrade, run the regression suite, and compare a set of known records and calculations before and after. A sort-order difference is found in one screen; the vendor provides a configuration setting to preserve the prior collation. The fix is added to the baseline and re-tested.
5. Production change in the maintenance window: verified backup taken, rollback path confirmed, upgrade applied, production verification run, audit trail confirmed recording.
6. Close-out: CMDB updated to the new DB version, configuration baseline updated with the collation setting, validation summary or system file updated, both the RFC and the change control record closed with the test evidence. The change is reportable at the next periodic review.

This is exactly the kind of change that Change Control for Validated Systems governs at the application level and that Infrastructure Qualification and Spreadsheet Validation covers at the platform level.

Cloud, IaaS, and SaaS change: what you do and do not control

Everything above assumes the organization can see a change coming and has a hand in scheduling it. That assumption gets weaker as more of the GxP estate moves onto a vendor-operated platform, and it deserves its own treatment rather than a footnote on the CMDB’s hosting-model field.

The shared responsibility model, in GxP terms

Cloud computing is commonly described across three service models, infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS), a categorization set out in NIST Special Publication 800-145, The NIST Definition of Cloud Computing (2011). Moving up that list hands more of the technology stack to the vendor and takes more of it out of direct change control.

The bottom row is the point that gets lost. Moving to SaaS moves who executes a change. It does not move who is accountable for showing the validated state is intact afterward. A regulator does not accept “the vendor did it” as a substitute for a documented impact assessment; it accepts it as an explanation of who holds the technical detail needed to write one.

Vendor-pushed changes you cannot schedule

The practical problem with SaaS, and to a lesser extent PaaS, is that the vendor’s release cadence is not your change window. A vendor may push a feature update, a calculation change, or a UI change to a multi-tenant platform on its own schedule, sometimes with a notice period measured in days, sometimes with almost none for a security fix. Three things make this workable instead of a standing risk:

1. A change-notification clause in the quality or technical agreement, obligating the vendor to notify you, with enough lead time and enough technical detail, before a change that could affect GxP-relevant function, calculation, data structure, or interface. See the cloud and SaaS quality technical agreement for fillable clause language.
2. A defined internal process to receive, triage, and act on that notice, the same GxP-impact triage this article describes for internally initiated change, applied to a notice received rather than a request raised. The SaaS vendor release review log is where that intake is recorded so a notice never sits unread in an inbox.
3. A sandbox or staging tenant, where the vendor’s release lands first so it can be tested before it reaches production, where the vendor’s release process supports one. Not every SaaS vendor offers this; where one does not, say so in the risk assessment rather than assuming parity with an on-premises staging environment.

Where none of the three exist, the honest statement in the validation documentation is that vendor-initiated changes are accepted on the vendor’s schedule with limited advance visibility, compensated by more frequent post-change verification of GxP-critical functions rather than pre-change testing. That is a describable risk position, not a compliance gap by itself, provided it is stated rather than assumed away.

Where triage still applies

The GxP-impact triage gate described earlier does not disappear for a SaaS system; it runs on a different trigger. Instead of “IT raised a change request,” the trigger is “the vendor’s release note, status page, or account notice arrived.” Route that notice through the same gate: does it touch a GxP-relevant function or configuration, and if so, does it need an impact assessment and testing before, or where no advance notice was given, promptly after, the change lands. See the cloud and SaaS shared responsibility matrix for assigning who at the organization owns each side of that intake.

Full treatment of qualifying a cloud or SaaS system in the first place, not only changing one, is in Cloud and SaaS Validation.

Configuration management discipline that holds up in an inspection

Beyond the CMDB inventory, configuration management means controlling the actual configured state of systems and detecting drift.

Version and configuration control

• Application and infrastructure versions are recorded and changes are controlled. You can state, for any GxP system, exactly what is running.
• Configuration as code, where it exists, lives in a version-controlled repository with controlled change. Infrastructure-as-code templates, scripts, and parameter files are configuration items too. See Validating Scripts and Low-Code Analytics and Agile and DevOps in CSV for how this works in modern pipelines.
• Drift detection: a periodic or automated comparison of running configuration against the approved baseline. Unexplained drift is investigated as a potential uncontrolled change.

Network and firewall change control

Network changes deserve their own line of attention because they are usually owned by a team, network engineering or security operations, that does not think of itself as the system owner of anything and so does not naturally route its work through a system’s change control. A firewall rule, a routing change, a DNS entry, a load balancer configuration, or a VPN and segmentation change can break a validated system’s function without anyone touching the application, the server, or even a CI that the application’s own CMDB entry lists.

The fix is to make the dependency visible rather than to hope the network team remembers it. Record, for each GxP system, the network paths it depends on for correct GxP function: its time-synchronization source, the interfaces it uses to send or receive regulated data, and any firewall rule that specifically exists to support it. Put those paths in the CMDB as relationships, not as a note in someone’s head, so a change to a network CI trips the same GxP-impact triage gate as a change to the server it serves.

A short worked scenario: a security team tightens outbound firewall rules to reduce attack surface after an incident elsewhere in the company. The change is reviewed as a security improvement with no GxP system named in the request, because no one thought to ask. It happens to close the port a validated system uses to email a distribution list as a required step in a release notification. The email step fails silently for two weeks before anyone notices product was released without the notification going out. The finding is not that the firewall change was wrong; it is that nothing connected “this port” to “this validated system’s GxP function” so the change could be triaged before it shipped.

Container and orchestration platform drift

Where a GxP system, or a component it depends on, runs in containers under an orchestration platform, the traditional model of “the server has a version” breaks down in a specific way. A running instance sits on a node the orchestrator picked, can be rescheduled onto a different, freshly built node without anyone initiating a change, and is built from an image that may be referenced by a mutable tag rather than a fixed identifier. NIST Special Publication 800-190, Application Container Security Guide (2017), describes this class of platform and the configuration and image-integrity concerns it raises in general terms; the GxP-specific reading is that several things that used to be implicit in “the server” are now explicit configuration items that need their own place in the register:

• The container image, identified by its content digest, not only its tag. A tag such as “latest” or “stable” is a pointer that can move to a different image entirely without a version number changing anywhere a human would notice, which makes it an uncontrolled change by definition if nothing recorded that the pointer moved.
• The orchestrator manifest or deployment definition (replica count, resource limits, network policy, secrets and configuration mounts), itself a baseline-controlled setting once it affects GxP function or data integrity.
• The cluster or control-plane version and its patch level, tracked the same way an operating system version is tracked elsewhere.
• The image registry and whatever vulnerability-scan gate sits in front of deployment, since that gate is part of how a patch actually reaches a running container.

The practical control is unglamorous: pin any GxP-relevant container to an immutable image digest, not a floating tag; redeploy that pinned image through the same change-control gate as any other patch, with the same regression expectations; and keep the orchestrator manifest under version control as configuration-as-code, per the general principle earlier in this section. A drift check for a containerized system compares the running image digest and the applied manifest against what was approved, exactly as a drift check for a conventional server compares an OS build number against a baseline, with a different set of fields.

Periodic review ties it together

At the system’s periodic review (see Validation Master Plan and Periodic Review), reconcile four things: the CMDB record, the running configuration, the configuration baseline, and the change-control history. They should all agree. Where they do not, you have found either a documentation gap or an uncontrolled change, and either is better found by you than by an inspector.

Acceptance criteria

• The running configuration of each GxP system matches its documented baseline, or every difference is explained by a closed change record
• Drift checks run on a defined cadence and discrepancies are investigated
• Configuration items that are code or templates are under version control with controlled change
• The four sources (CMDB, running config, baseline, change history) reconcile at periodic review
• Network dependencies (time source, interfaces, firewall rules) and, where used, container image digests and orchestrator manifests are recorded as configuration items subject to the same triage gate as any other change

Common mistakes and real inspection-finding patterns

These are the patterns inspectors and auditors cite, described generically.

• Infrastructure changes with no GxP change record. The IT change log shows OS patches, DB upgrades, or firewall changes on GxP systems that have no corresponding change control or impact assessment. This is the single most common finding at the ITIL/GxP seam.
• CMDB and validated-system inventory disagree. The CMDB lists versions that do not match what is running, or GxP systems are missing from one list, breaking the claim that you know your validated estate.
• “Standard change” used as a loophole. Changes are classified as standard or pre-approved to skip review, but the standing regression test is not actually run, or the classification rationale was never documented, so there is no evidence the change was harmless.
• Emergency changes never retrospectively reviewed. The emergency procedure exists but the QA back-review step is skipped, so emergency changes accumulate with no assessment of impact on the validated state or on data.
• No testing in a representative environment. Patches go straight to production with no qualified staging environment, so the first place a regression appears is in GxP data.
• Audit trail silently disabled by a patch or config change. A change altered logging behavior and no one checked the audit trail afterward, surfacing later as a data-integrity gap. See Audit Trail Design and Review.
• Rollback that does not work. A documented rollback plan that was never tested, so when a production change fails there is no clean recovery and the system is left in an unknown state.
• Cloud and SaaS changes invisible to the customer. A SaaS vendor pushes a change that alters GxP behavior and the regulated company has no notification mechanism in the quality agreement, so it learns of the change after the fact. See Cloud and SaaS Validation.
• Time source disrupted by a network change. A firewall or routing change cuts a GxP system off from its NTP source and the clock drifts, corrupting timestamps. See Time Stamps and System Clock Control.
• A floating container image tag treated as a fixed version. “latest” or “stable” pulls a different image on the next redeploy with no version number changing anywhere visible, so the system changes with no change record behind it.
• A network or firewall change made by a team that never considered itself the owner of a GxP system’s dependency, so the change never reaches the triage gate at all, and the break surfaces as a mysterious functional failure days or weeks later.

Interview-ready: questions you will be asked and how to answer

“How do you keep a validated system patched without re-validating every month?” Risk-based classification. Security-only patches with no GxP-relevant change are handled as pre-approved standard changes with a standing regression test, documented rationale from the release notes, and evidence the test ran. Functional and major changes go through full change control with targeted regression testing and staging. You patch at IT speed for the low-risk majority and reserve full validation effort for changes that can actually alter GxP behavior.

“Where does ITIL change control stop and GxP change control start?” At the GxP-impact triage gate. Every IT change is screened against the validated system inventory, usually via the CMDB GxP flag. If it touches a GxP system or its infrastructure, an ITIL change alone cannot close it; it requires the GxP path: validation impact assessment, defined testing, and QA approval before go-live. There is either one GxP-aware change record or two linked records, but the GxP record gates the change.

“Walk me through your emergency change process.” A pre-defined procedure with named out-of-hours authorizers. Make the minimum necessary change, record it contemporaneously even if approval was verbal, restore service or security, then have QA retrospectively review within a defined window to assess impact on the validated state and on any data created during the unstable period. If the fix altered a baseline setting, a follow-up normal change formalizes and fully tests it.

“What is a CMDB and why does Quality care about it?” It is the IT inventory of configuration items and their relationships. Quality cares because, reconciled with the validated system inventory, it is part of how you prove you know the boundary and current configuration of every validated system, which Annex 11 clause 4.3 expects. A CMDB that has drifted from reality undermines the whole change-control claim.

“How do you detect an uncontrolled change?” Configuration drift checks against the approved baseline, plus reconciliation at periodic review of four sources: CMDB, running configuration, baseline, and change history. Any difference not explained by a closed change record is investigated as a potential uncontrolled change and, if confirmed, handled as a deviation.

“A security team needs to patch a critical zero-day on a GxP system today. What do you do?” Treat it as an emergency security change. The security risk of leaving a known-exploited vulnerability open generally outweighs the change risk, but you still control it: emergency change record, minimum necessary patch, apply with a verified backup and tested rollback available, run a smoke test of GxP-critical functions and confirm the audit trail still records, then QA retrospective review and CMDB/baseline update. You do not use “it is validated” as a reason to leave it unpatched.

“What goes wrong most often at this interface?” Infrastructure changes that happen entirely inside the IT/ITIL world and never reach Quality, so the validated state is altered with no GxP record. Inspectors find it by sampling the IT change log against the GxP inventory. The fix is a hard triage gate driven by an accurate CMDB.

“A SaaS vendor just pushed a change to a validated system with no advance notice. What do you do?” Treat the vendor’s release note or status-page notice as the trigger for the same GxP-impact triage described earlier for internally raised changes, just running after the fact instead of before it. Assess whether the change touches a GxP-relevant function, verify the affected function promptly, and document the gap in advance notice as a known limitation of that vendor relationship rather than pretending it did not happen. Longer term, fix the quality agreement’s change-notification clause so the next one arrives with lead time, and use a sandbox or staging tenant where the vendor offers one.

“How would you handle a zero-day that affects five different GxP systems at once?” As one emergency event with linked, system-specific records, not five unrelated ones. Use the CMDB to find every affected system in minutes rather than by asking around. Open a parent emergency record for the shared vulnerability and fix, and a child record per system carrying that system’s own authorization, verification, and QA sign-off, because each system has its own owner and its own data to check for the unstable period. Triage the order by exposure, patch internet-facing systems first, and if one system’s fix fails, roll that one back and escalate it on its own without holding up or hiding behind the rest of the fleet’s clean closure.

Practical tips

• Make the CMDB the single source of the GxP flag, and wire your change tool to read it. The triage gate is only as good as that flag.
• Write the emergency change procedure and name the authorizers before you need them. The worst time to design the process is during the outage.
• Keep a standing, version-controlled regression test set per system for routine patches. It is what turns “pre-approved” from a loophole into a controlled practice.
• Test the rollback, do not just document it. A backup you have never restored is a hope, not a control. Pair this with Backup, Restore, and Disaster Recovery Validation.
• After any change, explicitly check the audit trail and the system clock. These two break quietly and surface as data-integrity findings months later.
• For SaaS, put change notification and the right to assess in the quality agreement up front. You cannot triage a change you are not told about.
• Reconcile the CMDB, baseline, running config, and change history at every periodic review. Finding your own gaps is cheap; an inspector finding them is not.
• Pin any GxP-relevant container to an image digest, not a floating tag, and redeploy it through the same change gate as any other patch.
• Put the vendor change-notification clause in the quality agreement before you need it, not after a surprise release; a SaaS vendor’s release schedule moves whether or not your change control is ready for it.

Related reading

• Change Control for Validated Systems
• GxP Computerized Systems Operations
• Infrastructure Qualification and Spreadsheet Validation
• 21 CFR Part 11 and EU Annex 11
• GAMP 5 CSV Framework
• Cloud and SaaS Validation
• Computer Software Assurance (CSA)
• CSV Cybersecurity and Access Control
• Agile and DevOps in CSV
• Validation Master Plan and Periodic Review