Change control is the process that keeps validated systems in a validated state. A system that passed its original qualification in 2022 and has since had twelve software updates, three configuration changes, two interface modifications, and a server migration is not a validated system unless each of those changes was assessed and handled correctly.

This is one of the most common validation failures in pharmaceutical inspections: a system was once validated, but the ongoing change management wasn’t maintained. The original validation documentation is perfect. The system in production looks nothing like what the validation was done on.

What Constitutes a Change to a Validated System

Any modification to the validated state of a system requires a change control record. “Change to the validated state” means any change to:

  • The software (version, patch, hotfix, configuration setting)
  • The hardware (server, client, peripheral devices)
  • The operating system or database
  • Validated interfaces with other systems
  • User roles and permission matrices (if roles affect GxP functions)
  • Data retention or archival configuration
  • The use context (new user population, new intended use, new data types)
  • The operating environment (moving to a new server, migrating to cloud)

Changes that don’t require a change control record: changes entirely outside the GxP scope of the system (changing the display language, modifying a non-GxP report template, updating a user’s email address).

When in doubt, open a change control record. An unnecessary change control is administrative overhead. A GxP change without documentation is a regulatory finding.

The Impact Assessment

The impact assessment is the core analytical step of the change control process. It evaluates what the proposed change affects in the validated system.

Impact assessment questions:

  1. What GxP functions does this change potentially affect? Review the validated functions list (from the URS/FRS or RTM) and identify any that could be affected.

  2. Is the change within the validated design space? A software patch that addresses a security vulnerability in the operating system, with no changes to application functionality, may be within the validated design space if the validation documentation captures the relevant application behaviors and those haven’t changed.

  3. What are the risks associated with the change? Consider: unintended effects on validated functions, data integrity risks during transition, potential for configuration drift.

  4. What testing is needed to verify the change doesn’t adversely affect validated functions?

Impact assessment output: One of three conclusions:

  • No impact: Change doesn’t affect validated functions. Document the assessment and proceed. No revalidation testing needed.
  • Low impact: Change may have limited effects on non-critical functions. Verification testing required for affected areas. No full revalidation.
  • High impact: Change affects critical GxP functions or core system architecture. Revalidation testing required for affected functions.

Categorizing Changes

Most facilities categorize changes into tiers to streamline the process:

Category 1 (Minor): Changes with no GxP impact or minimal, well-understood effects on non-critical functions. Examples: adding a user account, updating a report header, patching a third-party library with no application-level impact, correcting a typo in a screen label.

Review process: Change requestor and QA review, brief impact assessment, no testing required, expedited approval. Often processed within days.

Category 2 (Major): Changes affecting non-critical GxP functions or the interface between the validated application and infrastructure. Examples: a new report template that generates data exports, a configuration change to user permissions for a non-critical function, a new integration point with a non-critical system.

Review process: Change requestor, IT, validation, and QA review, full impact assessment, targeted revalidation testing, standard approval process. Typically 2-4 weeks.

Category 3 (Significant): Changes affecting critical GxP functions, core application behavior, or system architecture. Examples: major software version upgrade, changes to audit trail configuration, new critical interface, database migration, change to electronic signature workflow.

Review process: Full cross-functional review, formal impact assessment, revalidation testing comparable to original validation scope for affected functions, QA approval required before implementation. Typically 4-12 weeks depending on scope.

Revalidation Scope Determination

Revalidation scope should be driven by the impact assessment, not by assumptions. The assessment should identify specifically which validated functions are potentially affected, and testing should cover those functions.

For software version upgrades:

Request the software vendor’s release notes. Identify all functional changes in the new version. Map each change against the validated functions list. Functions that are unchanged in the new version may not require retesting. Functions that changed, were added, or were modified by the upgrade require testing.

For major platform upgrades (e.g., moving from Empower 3 to Empower 3 FR5), the vendor may have a regulatory support package with qualification documentation for the new version. Review it. If it addresses your key critical functions, you can use it and supplement with site-specific testing only where needed.

For configuration changes:

Test the specific function affected. If you’ve changed the audit trail settings for one module of a LIMS, test that module’s audit trail. Don’t retest the entire LIMS.

For interface changes:

Test the interface in both directions (data flowing in and data flowing out). Verify data integrity through the interface: values don’t change, metadata is preserved, error handling works as expected.

Emergency Changes

Sometimes a change needs to be implemented immediately, before the full change control process can be completed. Security patches, critical bug fixes, and infrastructure failures may require emergency implementation.

The correct approach to emergency changes:

  1. Implement the change with minimum necessary QA oversight (verbal or email approval from QA, documented).
  2. Open a change control record immediately (same day or next day at the latest).
  3. Complete the full impact assessment retrospectively.
  4. Perform any required testing as rapidly as possible.
  5. Close the change control record normally.

Emergency changes don’t bypass the process. They delay part of it by necessity, and then complete it as quickly as possible. An emergency change documented only as “emergency implementation, approved verbally” with no subsequent impact assessment or testing is not a controlled change.

Configuration Baseline Management

Maintaining a configuration baseline means knowing the exact configuration of the validated system at any point in time: software version, patch level, OS version, database version, application configuration settings, user roles, integration configurations.

The configuration baseline is established during IQ and updated with each change control. At any point, you should be able to answer: what is the current validated configuration of this system?

Configuration baselines are reviewed during periodic review and during the impact assessment for proposed changes. If you don’t know what the current baseline is, you can’t assess the impact of a change against it.

For cloud and SaaS systems: Configuration baseline management is more complex because the vendor controls system updates. The vendor agreement must specify notification requirements before updates, and the system owner must have a process to assess updates before they take effect. An automatic cloud update that changes validated functionality without notification is a significant validation gap.

Change Control and Periodic Review

Periodic review (typically annual) confirms the validated system is still in its validated state. One of the primary periodic review activities is reviewing all change controls executed since the last review, confirming:

  • All changes were documented in the change control system
  • Impact assessments were completed for each change
  • Required testing was completed and documented
  • The configuration baseline has been updated for each change

If the periodic review finds changes that were implemented without change controls, those must be assessed retrospectively. In some cases, they may require retroactive validation testing. In all cases, they must be documented as deviations.

A periodic review that finds zero changes over a year is suspicious, not reassuring, unless the facility can demonstrate no changes actually occurred. Systems that have been running unchanged for years without any patches, configuration updates, or user changes are unusual and worth investigating.

Change Control for Manufacturing Processes and Equipment

Change control in the CSV context applies to computerized systems. The same logic applies to manufacturing processes and equipment, governed by the process validation program rather than the computer system validation program.

Process changes that trigger reassessment or revalidation:

  • Changes to critical process parameters or their operating ranges
  • Changes to raw material supplier or specification
  • Equipment modifications affecting product contact or critical process function
  • Scale changes (either direction)
  • Changes to manufacturing site (technology transfer)
  • Changes to cleaning procedure (triggers cleaning validation reassessment)

For process changes, the impact assessment evaluates whether the change is within the established design space (from process development and validation) or outside it. Changes within the design space may be implementable through a normal change control without additional batch manufacturing under new conditions. Changes outside the design space require additional process validation work.

What Inspectors Look For in Change Control

FDA investigators request change control records for recent changes and for changes associated with any deviations or OOS results under investigation. They look for:

Completeness of change documentation. Is there a change control record for every change that occurred? Do the records identify what changed, when, why, and what testing was done?

Quality of impact assessment. Does the impact assessment actually evaluate GxP function impact, or is it a generic statement? “This change does not affect GxP functions” without analysis of which functions were assessed is not a defensible impact assessment.

Testing appropriate to the risk. For significant changes to critical functions, is there testing evidence? For minor changes, is the rationale for reduced testing documented?

Closure and implementation. Were changes implemented after approval, not before? Were all required tests complete before the change was closed?

Configuration baseline currency. Does the current validated configuration documentation match what’s actually running?

A change control system that’s missing entries for half the changes that actually occurred tells an inspector that the validation program isn’t functioning. That’s often a more serious finding than any individual change that was implemented without documentation.