Computerized System Change Control, Patching, and Revalidation

Computerized systems continue to change after release. Application upgrades, configuration changes, security patches, report revisions, interface modifications, master-data updates, and infrastructure replacements can alter validated functions or the electronic records they create and maintain.

Change control provides a documented process for evaluating, approving, implementing, verifying, and releasing these changes while maintaining the validated state. It should determine what evidence is required for each change rather than automatically requiring full revalidation or allowing technical changes to proceed without GxP assessment.

The required effort should reflect the intended use, affected functions and records, failure risk, technical complexity, supplier evidence, and extent of change.

Purpose of Computerized-System Change Control

Computerized-system change control should ensure that:

• changes are identified before implementation;
• affected systems, functions, records, and dependencies are understood;
• product-quality, patient-safety, data-integrity, and regulatory impacts are assessed;
• validation activities are proportionate to risk;
• required approvals are obtained;
• changes are implemented in a controlled manner;
• testing confirms the intended result;
• unintended effects are evaluated;
• rollback or recovery is available;
• documentation and training remain current;
• the production baseline is updated; and
• the system remains suitable for its approved intended use.

Change control begins after initial release and continues through system retirement. It connects the release process described in Computerized System Validation Deviations and Release with periodic review and continued maintenance of the validated state.

Changes Requiring Assessment

A change should be assessed whenever it can affect a GxP process, system function, electronic record, technical control, operating environment, or system dependency. The assessment should not be limited to changes made within the main application.

Application Changes

Application changes include:

• version upgrades;
• module additions or removals;
• feature activation;
• vendor releases;
• service packs;
• hotfixes;
• application programming interface changes;
• custom-code revisions;
• scripts and macros; and
• replacement of application components.

A supplier may describe a release as minor, but the regulated organization should determine its significance for the implemented configuration and intended use.

Configuration Changes

Configuration changes may affect system behavior without changing the underlying source code. Examples include:

• workflows;
• status transitions;
• approval rules;
• business rules;
• role permissions;
• audit-trail settings;
• electronic-signature settings;
• alarms;
• notifications;
• code tables;
• data-entry restrictions;
• calculations;
• enabled modules; and
• retention settings.

Configuration changes should be evaluated against the approved Functional, Design, and Configuration Specifications for Computerized Systems and the current configuration baseline.

Report and Calculation Changes

Report and calculation changes may affect regulated decisions even when the main application remains unchanged. The assessment should address:

• formulas;
• algorithms;
• rounding;
• precision;
• units;
• conversion factors;
• data selection;
• filtering;
• date ranges;
• status logic;
• report layouts;
• calculated fields;
• aggregation;
• exception handling; and
• exported values.

A cosmetic report change may require limited verification. A change to a release calculation, specification comparison, stability result, or product-status logic may require detailed specification review, independent calculation verification, boundary testing, and regression testing.

Interface Changes

Interface changes include modifications to:

• source or destination systems;
• field mappings;
• data formats;
• units and precision;
• transformation rules;
• message structures;
• middleware;
• application programming interfaces;
• transfer frequency;
• service accounts;
• encryption;
• certificates;
• acknowledgments;
• error handling;
• retries;
• reconciliation; and
• monitoring.

Interface assessment should consider both ends of the transfer and any middleware between them. The controls are addressed further in Computerized System Interfaces and Data-Transfer Controls.

Database and Data-Model Changes

Database changes may affect:

• tables and fields;
• relationships;
• indexes;
• stored procedures;
• data types;
• constraints;
• timestamps;
• audit trails;
• retention;
• performance;
• reporting;
• archival; and
• record retrieval.

The assessment should determine whether existing data must be converted, recalculated, reindexed, or migrated and whether the change could alter record meaning, relationships, metadata, or accessibility.

Infrastructure Changes

Infrastructure changes may include:

• server replacement;
• virtual-machine changes;
• operating-system upgrades;
• database-platform upgrades;
• storage changes;
• network changes;
• cloud-service changes;
• middleware updates;
• backup-agent updates;
• monitoring changes;
• load balancers;
• endpoint changes;
• time-service changes;
• certificates;
• firewall rules; and
• environmental relocation.

Qualification of shared infrastructure may provide evidence for several applications, but each affected application should still be assessed for compatibility and GxP impact. See IT Infrastructure Qualification for GMP Computerized Systems.

Identity-Service and Access-Control Changes

Changes to directory services, single sign-on, multifactor authentication, role mappings, privileged-access tools, or account provisioning can affect:

• user identification;
• authentication;
• authorization;
• segregation of duties;
• electronic signatures;
• service accounts;
• session management;
• emergency access; and
• audit attribution.

Testing should confirm the affected access and security controls rather than only demonstrating that users can log in.

Master-Data Changes

Master data may include:

• specifications;
• methods;
• products;
• materials;
• equipment;
• sampling plans;
• units;
• limits;
• recipes;
• calculation factors;
• organizational structures;
• reason codes; and
• status codes.

Routine master-data maintenance may follow an approved operational procedure rather than full project change control. The procedure should define authorized roles, independent review, effective dates, verification, audit-trail review, and escalation criteria.

Changes that alter business logic, calculations, regulated decisions, or data interpretation require formal impact assessment.

Supplier and Service Changes

Supplier-related changes may include:

• product releases;
• service-model changes;
• hosting changes;
• subcontractor changes;
• support changes;
• data-location changes;
• security-control changes;
• backup changes;
• release-cadence changes;
• end-of-support notices; and
• service retirement.

The organization should evaluate supplier notifications according to Computerized System Supplier Assessment and Evidence Leverage. Supplier approval of its product does not constitute site-specific approval for regulated use.

Cybersecurity Changes

Cybersecurity changes may include:

• patches;
• vulnerability remediations;
• antivirus or endpoint-control changes;
• firewall modifications;
• network segmentation;
• encryption changes;
• certificate replacement;
• authentication changes;
• security-agent deployment;
• logging changes;
• remote-access restrictions; and
• compensating controls.

Cybersecurity changes should be managed as part of data integrity, availability, and the validated state. Security urgency may require accelerated implementation, but it does not eliminate the need for documented assessment and verification.

Change Categories

Change categories help establish approval routes, documentation, implementation controls, and verification expectations. The governing procedure should define each category clearly.

A standard change should not be defined only by frequency. It should have predictable outcomes, clear prerequisites, documented execution steps, established rollback, and approved verification.

Examples may include routine certificate renewal or installation of a previously assessed security definition. A change should leave the standard route when its prerequisites are not met, execution differs from the approved method, or unexpected results occur.

A major change does not necessarily require complete repetition of original validation. It requires a sufficiently detailed assessment to determine the affected lifecycle evidence and justified revalidation scope.

Change Request and Initial Screening

The change record should identify:

• the proposed change;
• the business and technical reason;
• affected systems and environments;
• affected functions, records, interfaces, and users;
• supplier release or patch information;
• cybersecurity urgency;
• planned implementation date;
• requested change category;
• related incidents, deviations, or defects;
• proposed testing;
• proposed rollback; and
• responsible owners.

Initial screening should determine whether the request is complete enough for impact assessment and whether additional business, technical, supplier, validation, security, or Quality input is required.

A proposed solution should not be approved before the underlying problem and affected process are understood.

Impact Assessment

Impact assessment is the central control in risk-based change management. It should determine what may change, what can fail, which evidence could become invalid, and what work is required before release.

The assessment should consider:

• approved intended use;
• GxP applicability;
• Part 11 applicability;
• product-quality and patient impact;
• data integrity;
• regulated records and metadata;
• system architecture;
• software category;
• configuration;
• custom components;
• infrastructure;
• interfaces;
• supplier responsibilities;
• cybersecurity;
• availability and recovery;
• procedures;
• training;
• validation documentation; and
• cumulative effects of earlier changes.

The assessment should identify both direct effects and dependencies. Updating a database platform may not change a workflow requirement, but it can affect calculations, timestamps, interfaces, reports, audit trails, performance, backup, restoration, or record retrieval.

Data and Record Impact

Every significant change should be assessed for its effect on existing and future data. The review should determine whether the change can affect:

• original records;
• metadata;
• audit trails;
• electronic signatures;
• timestamps;
• record status;
• calculations;
• data relationships;
• units and precision;
• reports;
• search and retrieval;
• retention;
• archival;
• backup;
• restoration;
• exported records; or
• inspection copies.

A change should not silently reinterpret historical data. If a revised calculation or reference table applies only to new records, the effective-date logic should be defined and tested.

Where existing records must be transformed, moved, or recalculated, the work should be controlled through the principles described in Computerized System Data Migration Validation.

Defining Validation Deliverables

The impact assessment should define which lifecycle documents require creation or revision. Depending on the change, deliverables may include:

• change plan;
• intended-use revision;
• updated system boundary;
• GxP or Part 11 reassessment;
• supplier assessment;
• risk assessment;
• updated requirements;
• functional or design specifications;
• configuration specification;
• architecture or data-flow diagrams;
• migration plan;
• test plan;
• test scripts;
• regression assessment;
• traceability updates;
• deployment instructions;
• rollback plan;
• procedure revisions;
• training records;
• validation summary;
• release approval; and
• updated configuration baseline.

Documentation should be scaled to the change. A low-risk parameter change may require an approved change record, configuration evidence, and focused testing. A major platform upgrade may require a project-level validation plan and several revised lifecycle documents.

Risk-Based Revalidation Decisions

Revalidation is the planned verification needed to demonstrate that the changed system remains suitable for its intended use. The decision should not be based only on the change category or a numerical risk score.

The assessment should consider:

• significance of the affected function;
• impact on patient safety and product quality;
• importance of affected records;
• effect on data integrity;
• degree of technical change;
• novelty and complexity;
• configuration or customization;
• affected interfaces;
• supplier evidence;
• existing controls;
• detectability of failure;
• prior defects and incidents;
• extent of historical testing; and
• consequences of an incorrect result.

The resulting scope may be:

• Documentation only: justified when the change has no effect on system operation, regulated records, or validated controls.
• Targeted verification: appropriate when specific functions or technical components are affected and dependencies are understood.
• Broader revalidation: required when the change affects intended use, critical functions, architecture, data structures, major interfaces, security controls, or multiple dependent processes.

“No impact” should be supported by analysis. It should not be used as a default conclusion for infrastructure, supplier, or cybersecurity changes.

Patches and Hotfixes

Patches and hotfixes should be evaluated before production implementation unless immediate action is required to protect the system or records. The assessment should review:

• supplier description;
• affected components;
• corrected defects;
• known limitations;
• security severity;
• exploitability;
• system exposure;
• compatibility;
• prerequisites;
• installation method;
• database or configuration changes;
• service interruptions;
• rollback limitations;
• supplier testing;
• site-specific testing; and
• affected validated functions.

Patches should not be delayed automatically because a system is validated. Failure to apply a necessary patch can create unacceptable risks to record integrity, availability, authentication, or business continuity.

Conversely, a supplier’s recommendation to install a patch does not eliminate the need to assess compatibility and site-specific impact.

When immediate installation is not possible, documented compensating controls may include network restriction, enhanced monitoring, removal of vulnerable services, access limitation, or isolation. The residual risk and planned resolution date should be approved.

Supplier Evidence

Supplier evidence can reduce unnecessary duplication when it is relevant, current, and credible. Useful evidence may include:

• release notes;
• impact statements;
• supported-version information;
• installation instructions;
• test summaries;
• known-defect lists;
• compatibility statements;
• security advisories;
• vulnerability information;
• rollback instructions; and
• updated technical documentation.

Supplier evidence should be evaluated against the implemented version, configuration, infrastructure, and intended use.

It may support the rationale for reduced testing, but it does not replace verification of site-specific workflows, configuration, interfaces, data, access controls, reports, procedures, or recovery arrangements.

Regression Testing

Regression testing confirms that a change has not adversely affected previously acceptable functions. The regression scope should be based on dependencies rather than simply repeating a fixed percentage of historical tests.

It should consider:

• affected requirements;
• related workflows;
• shared calculations;
• common configuration objects;
• roles and permissions;
• audit trails;
• electronic signatures;
• reports;
• interfaces;
• migrated or historical data;
• error handling;
• backup and restoration;
• performance; and
• connected systems.

Testing may include:

• focused scripted tests;
• automated regression tests;
• exploratory testing;
• positive and negative challenges;
• boundary conditions;
• data comparison;
• interface reconciliation;
• security testing; and
• representative end-to-end workflows.

The rationale for included and excluded tests should be documented. Requirements coverage should be updated through Requirements Traceability and Validation Evidence.

Migration and Data Conversion

Changes that modify data structures, platforms, applications, or interfaces may require data migration or conversion. The plan should define:

• affected data;
• inclusion and exclusion rules;
• mappings;
• transformations;
• legacy codes;
• metadata handling;
• audit-trail treatment;
• signatures;
• attachments;
• relationships;
• migration tools;
• security;
• reconciliation;
• exception handling;
• rollback; and
• acceptance criteria.

Migration should be tested in advance when practical. Production execution should use approved tools, instructions, access, and reconciliation controls.

A technically successful upgrade should not be released if the associated records are incomplete, inaccurate, unreadable, or no longer linked correctly.

Rollback and Recovery

The change plan should define what will occur if implementation or verification fails. Rollback planning should address:

• decision authority;
• rollback trigger;
• previous software and configuration;
• database restoration;
• data entered during the change window;
• interface queues;
• delayed transactions;
• reconciliation;
• user communication;
• supplier support;
• business-continuity procedures; and
• verification after restoration.

Some database conversions or cloud-service releases cannot be reversed easily. In those cases, forward-recovery arrangements, tested backups, alternative processing, and supplier escalation should be defined before implementation.

A backup alone is not an adequate rollback plan unless restoration has been demonstrated and the effect on related systems and transactions is understood.

Implementation and Verification

Approved changes should be implemented through controlled instructions in the appropriate environment.

Implementation records should identify:

• date and time;
• affected environment;
• personnel performing the work;
• application and component versions;
• configuration changes;
• scripts or commands used;
• database actions;
• supplier participation;
• observed results;
• discrepancies;
• rollback decisions; and
• post-implementation verification.

Testing should be performed in a representative nonproduction environment when practical. Production verification should confirm deployment and critical operability without introducing inappropriate test records into the regulated process.

Unexpected results should be handled through documented deviation or defect processes. Repeated execution until a test passes is not an acceptable substitute for investigation.

Procedures and Training

Changes may require updates to:

• operating procedures;
• work instructions;
• data-review procedures;
• audit-trail review;
• access administration;
• backup and recovery;
• interface monitoring;
• incident response;
• business continuity;
• support procedures;
• configuration management; and
• periodic review.

Affected users and support personnel should complete required training before the changed function is used.

Training may be limited to an awareness communication for a minor user-interface change. Changes to workflows, responsibilities, approvals, security controls, exception handling, or record review normally require documented role-based training.

Release of the Change

A change should be released only when the approved acceptance criteria are met. Release readiness should confirm:

• required documentation is approved;
• implementation is complete;
• testing is acceptable;
• deviations and defects are resolved or accepted;
• migration is reconciled;
• interfaces are ready;
• security access is approved;
• procedures are effective;
• training is complete;
• backup and rollback arrangements are available;
• residual risk is accepted;
• the production baseline is updated; and
• required Quality and business approvals are complete.

Conditional release may be used only when remaining items do not prevent compliant operation and restrictions, compensating controls, ownership, and completion dates are documented.

Emergency Changes

Emergency changes may be necessary to:

• restore a failed GxP service;
• correct a critical defect;
• prevent record loss;
• respond to an active cybersecurity threat;
• renew an expiring certificate;
• restore an interface;
• recover infrastructure; or
• protect manufacturing or laboratory operations.

The emergency route may reduce the time available for advance documentation, but it should not remove control.

Before implementation, the organization should document, to the extent practical:

• the emergency condition;
• affected systems and operations;
• proposed action;
• immediate risks;
• authorized approvers;
• minimum verification;
• backup or rollback; and
• communication requirements.

After implementation, a retrospective review should confirm:

• what was changed;
• whether the change achieved its purpose;
• what verification was completed;
• whether data or records were affected;
• whether deviations occurred;
• whether additional testing is required;
• whether procedures or specifications require revision;
• whether the configuration baseline was updated; and
• whether the emergency exposed a broader control weakness.

Retrospective review should be completed within a defined period. Emergency classification should not be used to avoid normal planning for foreseeable work.

Cumulative Change

Individually minor changes can collectively alter a system substantially. Periodic review should consider cumulative changes to:

• configuration;
• custom reports;
• calculations;
• interfaces;
• master data;
• infrastructure;
• security controls;
• supplier services;
• procedures;
• operating practices; and
• unresolved defects.

The organization should determine whether the accumulated changes have:

• altered intended use;
• created undocumented dependencies;
• invalidated earlier specifications;
• reduced meaningful traceability;
• increased configuration complexity;
• affected system performance;
• introduced inconsistent controls; or
• created a need for broader regression testing or revalidation.

Cumulative-change review prevents a system from gradually moving away from the configuration and assumptions represented by its original validation evidence.

Maintaining the Validated State

Closure of an approved change should confirm that the validated state has been re-established. The closure record should show:

• the final implemented condition;
• completed validation activities;
• approved deviations;
• accepted residual risk;
• updated requirements and specifications;
• current traceability;
• revised procedures;
• completed training;
• updated inventory and architecture;
• current software and infrastructure versions;
• updated configuration baseline;
• release authorization; and
• required follow-up actions.

Under 21 CFR 11.10, closed systems require appropriate validation, record protection, access controls, audit trails, and revision and change-control procedures for system documentation.

For drug-manufacturing systems, 21 CFR 211.68 addresses appropriate controls for computerized systems, including authorized changes and checks of system operation.

FDA’s Data Integrity and Compliance With Drug CGMP guidance emphasizes flexible, risk-based strategies grounded in process understanding and knowledge of the technology and business model.

Practical Change-Control Outcome

Effective computerized-system change control produces more than an approved change ticket. It establishes:

• what is changing and why;
• which systems, records, and processes are affected;
• what could fail;
• which validation evidence requires revision;
• what testing is necessary;
• how data will be protected;
• how the change can be reversed or recovered;
• which procedures and training must change;
• who accepts the remaining risk;
• what configuration is authorized for production; and
• how the validated state will be maintained.

The objective is not to prevent change. It is to introduce necessary technical, operational, supplier, and security changes without losing control of the system’s intended GxP use, records, and lifecycle evidence.