What Is Change Management in a Quality System? Process and Regulatory Requirements
Somewhere between the intent to improve a manufacturing process and the actual implementation, quality systems fail. A formulation is adjusted to reduce costs. A supplier swaps a raw material. A software update changes how a batch record is generated. Each of these is a change, and in regulated industries, each one carries the potential to affect product safety, efficacy, or compliance if it happens without proper control.
Change management in a quality management system (QMS) is the structured process for proposing, evaluating, approving, implementing, and documenting changes before they affect production or released products. Under FDA regulations, ISO standards, and ICH guidance, it sits alongside CAPA and complaint handling as one of the three most critical post-market quality processes.
This article covers what change management requires across the main regulatory frameworks, the types of changes that need formal control, and where most organizations accumulate risk by treating some changes as exempt.
What Change Management Actually Covers in a QMS
Change management in a quality context covers more than product design updates. It applies to any modification that could affect:
- Product safety, performance, or efficacy
- Manufacturing processes, equipment, or facilities
- Quality system procedures, work instructions, or specifications
- Software used in production or quality data management
- Supplier-provided materials, components, or services
- Labeling, packaging, or storage conditions
The breadth of this scope is where organizations run into compliance problems. Teams often understand that design changes require formal approval. They are less consistent about applying the same rigor to facility changes, software updates, or supplier-initiated substitutions.
The Regulatory Framework
Medical Devices — QMSR and ISO 13485
Under the FDA's QMSR (21 CFR Part 820, effective February 2, 2026), change management for medical devices is governed by ISO 13485:2016, which the QMSR incorporates by reference. The relevant clauses cover change control at multiple levels:
ISO 13485 clause 7.3.9 (Design and development changes): Design changes must be identified, documented, reviewed, verified, validated (as appropriate), and approved before implementation. The review must assess whether the change affects in-process and finished products already delivered. For changes that affect regulatory submissions or the device's intended use, the review must also determine whether re-filing or regulatory notification is required.
ISO 13485 clause 6.3 (Infrastructure changes): When infrastructure changes affect product quality, organizations must evaluate and document the impact before implementation.
ISO 13485 clause 7.6 (Changes to control of monitoring and measuring equipment): Any change to the equipment or software used in measurement activities requires documented evaluation of impact on prior measurement results.
ISO 13485 clause 5.4 (QMS planning): When the organization determines that changes to the quality management system are needed, those changes must be planned and implemented in a way that maintains the system's integrity.
Under the QMSR, design change records must be retained in the Design History File, and any change affecting a cleared or approved device may require submission of a process change notification or a new 510(k) or PMA supplement to FDA, depending on whether the change affects safety or effectiveness.
Pharmaceutical cGMP — 21 CFR Part 211 and ICH Q10
For pharmaceutical manufacturers, change control requirements appear throughout 21 CFR Part 211 and are explicitly addressed in ICH Q10 (Pharmaceutical Quality System), which FDA adopted as guidance.
21 CFR 211.68 requires that changes to computerized systems be validated before implementation. 21 CFR 211.100 requires that written procedures for production and process controls be reviewed, approved, and dated before use, and that any revision follow a documented review and approval process.
ICH Q10 addresses change management directly in section 3.2, placing it as a core element of the pharmaceutical quality system alongside complaint management and CAPA. The guidance specifies that the change management system should:
- Define the scope of changes subject to formal control
- Include an assessment of potential impact on product quality, process capability, and regulatory status
- Require documented approval before implementation
- Ensure that changes are communicated to affected personnel before they go live
- Provide for post-implementation verification that the change achieved its intended effect
ICH Q10 also distinguishes between changes that require prior regulatory approval and those that can be implemented through internal notification. For post-approval changes to drug products, FDA's guidance on annual product reviews (21 CFR 314.81) and supplements (21 CFR 314.70) governs what must be filed versus what can be handled internally.
ISO 9001:2015 for General Manufacturing
ISO 9001:2015 addresses change management in two separate clauses that operate at different levels.
Clause 6.3 (Planning of changes): When an organization determines that changes to the QMS are needed, those changes must be carried out in a planned manner. The planning must consider the purpose of the change, potential consequences, the integrity of the QMS, the availability of resources, and responsibility and authority for the change.
Clause 8.5.6 (Control of changes): For production and service provision, organizations must review and control changes to the extent necessary to ensure continued conformity with requirements. They must retain documented information describing the results of the review, the personnel who authorized the change, and any necessary actions arising from the review.
Together, these clauses mean that ISO 9001 requires both high-level QMS planning for changes and operational controls at the production level.
Types of Changes That Require Formal Control
Most quality teams have a clear mental model of what requires change control: a design modification to a device, a new manufacturing process, a change to a critical raw material specification. The changes that get missed tend to fall into categories that feel routine:
"Equivalent" material substitutions. A supplier notifies a manufacturer that a component is moving to a new lot or grade but claims it is functionally equivalent. Without a formal evaluation, that substitution bypasses risk assessment and may not be captured in the Device History Record or Batch Record.
Software updates. Updates to ERP systems, LIMS, or QMS platforms that affect how production data is recorded, calculated, or reported require validation under 21 CFR Part 11 and ICH Q7. Many organizations apply patches without documenting the change's potential impact on data integrity.
Facility and utility changes. Moving a manufacturing line within a facility, adding HVAC capacity, or changing water system parameters each has the potential to affect product quality. These changes frequently skip change control because they are categorized as "infrastructure," not "product."
Procedure revisions. Updates to SOPs and work instructions that alter how a critical process is performed — even if the underlying requirement hasn't changed — should go through change control. FDA inspectors look at the version history of procedures associated with 483 findings to determine when a deficient practice was introduced.
Supplier-initiated changes. Under ISO 13485 clause 7.4 and 21 CFR Part 820, suppliers are required to notify manufacturers of changes that could affect product quality. But that notification is only useful if the manufacturer has a process for capturing it and routing it through change control.
The Change Control Process
A complete change control process follows five stages regardless of the industry or regulatory framework:
1. Change proposal. The requestor documents the proposed change, its rationale, and the scope of what will be modified. The proposal should identify the product, process, document, or system affected and provide enough detail for the impact assessment team to evaluate it.
2. Impact assessment. The evaluation determines how the change affects product safety, efficacy, process capability, regulatory submissions, validation status, and the existing risk register. For design changes under ISO 13485, the assessment must specifically determine whether the change invalidates prior verification or validation activities. For pharmaceutical changes, the assessment must identify whether the change triggers regulatory filing obligations.
3. Review and approval. The change request and its impact assessment are reviewed by appropriate functions — typically quality, regulatory, engineering, and operations, depending on the scope. Approval must be documented with reviewer names, roles, and dates.
4. Implementation. Once approved, the change is implemented according to the documented plan. This includes updating all affected documents, training affected personnel, updating validation records as required, and communicating the change to relevant parties — including suppliers and customers where appropriate.
5. Verification and closure. After implementation, the QMS must verify that the change was carried out as approved and that it achieved the intended effect without introducing new problems. This includes updating the audit trail with closure documentation, confirming that any required regulatory submissions were made, and archiving all change control records.
The "Minor Change" Exemption Problem
The most common change management failure pattern in FDA warning letters is not that companies have no change control process. It is that their change control procedure carves out a "minor change" or "administrative change" category, and that category gradually absorbs changes that should receive full review.
A labeling change is administrative — until it involves a claim that affects the device's intended use. A process parameter adjustment is minor — until it creates an out-of-spec rate. A software update is routine — until it changes how electronic signatures are applied to batch records.
When FDA inspectors examine change control records, they specifically review changes that were routed through the minor-change pathway. They look for evidence that the minor designation was justified by a documented rationale, not just assumed because the requestor didn't want to go through a full review.
Organizations with strong change management programs define "minor" with specific, enumerated criteria rather than a general description. If a proposed change doesn't fit the specific criteria, it goes through full review regardless of how simple it seems at submission.
Where Change Management Goes Wrong
Beyond the minor-change problem, change control failures in regulated industries tend to cluster around four patterns:
Retroactive documentation. Changes implemented first and documented after the fact. This is particularly common when engineering or operations teams make adjustments during production to solve an immediate problem. The fix works, but the change control record is filed after the batch has already shipped.
Incomplete impact assessments. Change proposals approved without a documented evaluation of impact on regulatory submissions, validation status, or supplier agreements. The most common version: a process change is assessed for product quality impact but no one checks whether it requires a 510(k) supplement or prior approval supplement for a drug application.
No post-implementation verification. Changes approved, implemented, and closed without documented evidence that the change achieved its intended effect. Under ICH Q10, post-implementation verification is explicitly required. Many organizations close change records at the point of implementation, not at the point of verified effectiveness.
Training not completed before implementation. Changes to procedures or processes go live before affected personnel are trained. This is identifiable during FDA inspections when training records show completion dates after the change implementation date.
Audits and Change Management Integration
Change management does not function in isolation. A well-built QMS connects change records to the documents, processes, and records they affect. When an internal audit identifies a gap, the corrective action often involves a procedure change — and that change needs to go through change control. When a complaint investigation reveals a product quality issue tied to a recent process adjustment, the link between the complaint, the root cause investigation, and the change record needs to be preserved and visible.
Organizations that manage change control in a spreadsheet or standalone system lose these connections. The change record exists, but it has no link to the CAPA it generated, the updated procedure it produced, or the validation records it modified.
Change Management in Cloudtheapp
Cloudtheapp's Change Management application manages the full change control workflow from proposal through impact assessment, approval, implementation, and verified closure. All records include electronic signatures with date and timestamp, meeting 21 CFR Part 11 requirements for audit trail integrity.
The platform connects change records directly to the documents, CAPA records, validation activities, and supplier records they affect. When a change modifies a procedure, the document control system automatically requires the updated version to go through its own review and approval workflow. When a change triggers a CAPA, the two records are linked and both must be closed before either is considered complete.
Cloudtheapp's built-in analytics surface open changes by status, age, type, and product, so management review meetings have documented input rather than verbal updates.
For quality teams managing change control across device and pharma portfolios, Cloudtheapp supports configurable workflows that match the specific requirements of QMSR, ISO 13485, ISO 9001, and ICH Q10 environments.
To see how a connected QMS handles change management from proposal to verified closure, request a demo at https://www.cloudtheapp.com/demo/.
