Author: Parveen K Kohli

Why MOC?

As per Q1 clause 5.10.1, the phrase “MOC to maintain the integrity of the quality management system when changes occur” means that the Management of Change (MOC) process aims to ensure that any change within an organization does not disrupt or compromise the functioning of its Quality Management System (QMS).

The integrity of the QMS refers:

  • Consistently meeting quality requirements,
  • Maintaining compliance with standards and specifications, and
  • Delivering products or services that satisfy customer and legal requirements.

Changes—whether they are organizational, procedural, critical supply chain, or related to resources—can introduce risks or create gaps in how deliverable quality is managed. By using the MOC process, organizations can:

  • Proactively identify and mitigate risks,
  • Protect the QMS’s effectiveness, and
  • Ensure the QMS functions as intended despite the changes.

When shall the Management of Change (MOC) be applied?

As per Q1 clause 5.10.2, the requirement to “use MOC for changes that may negatively impact the quality of the product” refers to any modifications or alterations when planned (see Q1 clause 5.3.2.3)—that could impact product quality. Examples include changes that may affect:

  • Product quality: Deviations in meeting quality standards,
  • Performance: Variations in how the product functions,
  • Reliability: A drop in long-term consistency, and
  • Compliance: Issues with adhering to defined standards or customer requirements.

In short, if a change has the potential to:

  • Introduce risks,
  • Lead to defects or inconsistencies, or
  • Reduce adherence to quality requirements,

Then, the MOC process must be applied.

The goal is simple:

  • Address risks proactively,
  • Ensure the product’s quality remains intact, and
  • Evaluate each change carefully to mitigate potential negative impacts before introducing it.

Does Every Change Outlined in Q1 Clause 5.3.2.3 Require MOC?

Not necessarily. MOC is applied only to changes that may negatively impact product quality. Organizations should:

  • Conduct an assessment to determine the potential risks.
  • If no negative impact on product quality is identified, completing the MOC process is not required.

However, it is recommended to:

  • Maintain records of the assessment.
  • Document the rationale for deciding not to apply the MOC process.

Understanding MOC Through an Inspection Procedure Example

To better understand the Management of Change (MOC) application, let’s consider a change in an in-process inspection procedure. This example highlights two scenarios:

  1. Scenario 1: Increase in Inspection Frequency (10% to 20%) In this case, the frequency of in-process inspection is increased from 10% to 20%.
    • This positive change increases the likelihood of detecting out-of-specification parts during inspection.
    • Since this change enhances the quality assurance process, it does not introduce a risk to product quality.
    • As a result, the application of MOC is not required in this scenario.
  2. Scenario 2: Decrease in Inspection Frequency (20% to 10%) Here, the frequency of in-process inspection is reduced from 20% to 10%.
    • This change has introduced a risk, decreasing the probability of detecting out-of-specification parts during inspection.
    • Consequently, the risk of delivering non-conforming parts to customers increases, leading to a risk state for product quality.
    • Because this change has a potential negative impact on product quality, the application of MOC is required in this scenario.

This example illustrates the importance of evaluating changes for their potential impact on product quality. By doing so, organizations can determine whether MOC is necessary to address risks and maintain the integrity of the Quality Management System (QMS).

Disclaimer: This interpretation is provided solely for guidance and is based exclusively on the author’s learning experience within the API ecosystem. Before forming any judgments, readers are encouraged to rely on their own understanding in light of their organization’s requirements.

Note: API does not endorse this interpretation, either in part or as a whole.