Non-Conformance Management and CAPA: Corrective and Preventive Action in ISO 9001 and IATF 16949

Non-conformance identification and recording

A non-conformance (NC) is any condition in which a product, process, material, or service does not fulfill a specified requirement. Requirements may come from customer specifications, engineering drawings, internal standards, regulatory requirements, or contractual obligations. Non-conformances can be detected at any stage: incoming inspection, in-process inspection, final inspection, or in the field after delivery.

Every identified non-conformance must be recorded in a non-conformance report (NCR) or its equivalent in the organization’s quality management system. The NCR captures the identification of the non-conforming item (part number, lot number, serial number, quantity), the location and date of detection, a description of the discrepancy against the applicable requirement, and the name of the person who identified the non-conformance. Recording is not optional even for minor non-conformances: the data accumulated in NCRs feeds trend analysis that identifies systemic problems that would otherwise remain invisible as a series of individually insignificant events.

Segregation and identification

Non-conforming product must be physically segregated from conforming product to prevent inadvertent use or shipment. Segregation is achieved through a combination of physical separation (a dedicated hold area, quarantine cage, or red-tagged location) and clear visual identification (red tags, labels, or markings). The hold area must be defined, controlled, and accessible only to authorized personnel. The requirement to prevent inadvertent use of non-conforming product is explicit in ISO 9001 clause 8.7 and IATF 16949 clause 8.7.1.

In high-volume production environments where physical segregation of individual non-conforming units is impractical, the hold can be applied at the container, pallet, or lot level. In software and service contexts, the equivalent of segregation is preventing non-conforming deliverables from being released to the customer or to downstream processes until disposition is completed.

Disposition and the material review board

Disposition is the decision about what to do with a non-conforming item. The standard disposition options are:

Use as-is: the item does not conform to the requirement as written, but engineering review concludes that the non-conformance does not affect fit, form, function, safety, or regulatory compliance and the item may be used without rework. Use-as-is dispositions require documented engineering justification and, in many industries, customer approval before use.

Rework: the item is brought into conformance by reprocessing, repair, or adjustment. Reworked items must be re-inspected to the original acceptance criteria before release.

Return to supplier: non-conforming incoming material is returned to the supplier with a documented supplier corrective action request (SCAR).

Scrap: the item is permanently removed from the production stream and destroyed or otherwise rendered unusable. Scrap must be controlled to prevent inadvertent use of scrapped material.

Downgrade / use in alternate application: the item does not meet the requirements of its original application but meets the requirements of a less demanding application. Downgrading requires the same documented engineering justification as use-as-is.

In organizations with a formal material review board (MRB) process, disposition decisions are made by a cross-functional team that includes quality engineering, design engineering, manufacturing engineering, and (for use-as-is and downgrade decisions) the customer. The MRB process is mandatory in aerospace (AS9100) and common in automotive and defense.

CAPA initiation criteria

Not every non-conformance requires a full CAPA. CAPA is a resource-intensive process, and organizations that require formal CAPA for every trivial non-conformance quickly find themselves overwhelmed with open CAPAs that cannot receive adequate attention. Effective CAPA programs define clear initiation criteria that distinguish between non-conformances that require immediate correction (rework and scrap) and those that require a systemic CAPA investigation.

Common CAPA initiation criteria include: customer complaints or warranty returns; repeat non-conformances of the same type (for example, three occurrences within 90 days); non-conformances above a defined severity threshold (for example, any non-conformance that required customer notification or field action); non-conformances that escaped to the customer (escapes); audit findings classified as major non-conformances or repeat minor non-conformances; and supplier-caused non-conformances that meet the above criteria.

The initiation criteria should be documented in the CAPA procedure and consistently applied. Inconsistent application, whether through over-triggering (issuing CAPA for every trivial event) or under-triggering (avoiding CAPA to keep metrics clean), undermines the effectiveness of the program and is a common finding in quality system audits.

Root cause analysis methods in CAPA

The quality of a CAPA is determined primarily by the quality of the root cause analysis. A CAPA based on an incorrect or superficial root cause will not prevent recurrence, regardless of how thoroughly the corrective actions are implemented.

The most commonly used root cause analysis methods in CAPA are:

5 Whys: iterative questioning that asks why a problem occurred and then asks why the answer to the previous question is true, repeating the process until the fundamental systemic cause is identified. The 5 Whys is appropriate for relatively simple problems with a single causal chain. It can fail for complex problems with multiple interacting causes, or when the team stops at a symptom rather than continuing to the underlying system failure.

Fishbone (Ishikawa) diagram: a graphical tool that organizes potential causes into categories (typically the 6M categories: man, machine, method, material, measurement, mother nature/environment) to ensure that no category of potential cause is overlooked. The fishbone diagram is useful for structured brainstorming but does not itself identify the root cause; it generates hypotheses that must be verified through data collection and analysis.

Fault tree analysis (FTA): a top-down deductive method that starts with the failure event and maps the combinations of sub-failures that could lead to it, using AND and OR logic gates. FTA is particularly appropriate for safety-critical systems and complex failures where multiple simultaneous conditions are required to produce the failure.

Is/Is Not analysis: a structured comparison that defines the problem by specifying what it is and what it is not along multiple dimensions (what, where, when, how much). The distinctions between the “is” and “is not” conditions generate hypotheses about the cause. Is/Is Not analysis is the structured problem definition component of the 8D methodology and of Kepner-Tregoe problem analysis.

Regardless of the method used, the root cause analysis must address both the direct cause (the immediate technical reason the non-conformance occurred) and the systemic cause (the reason the quality system failed to prevent or detect the non-conformance). A CAPA that addresses only the direct cause, without addressing the systemic cause, will prevent this specific failure mode but leave the system vulnerable to the next non-conformance that the same systemic gap allows.

Corrective action planning and implementation

Corrective actions address the verified root causes identified in the root cause analysis. Each corrective action must be specific, assigned to a responsible person, and given a target completion date. Corrective actions may be technical (process parameter changes, tooling modifications, engineering design changes), procedural (procedure or work instruction revisions, inspection frequency changes), or systemic (training program updates, supplier qualification changes, quality system procedure revisions).

In IATF 16949, corrective actions for customer-reported non-conformances must also address the escape cause: why the non-conformance passed through all detection opportunities in the production and shipping process and reached the customer. The escape cause analysis often reveals gaps in detection controls that are separate from the production root cause, and the corresponding escape corrective actions typically involve inspection and process control improvements.

Preventive action and its link to FMEA

Preventive action addresses potential non-conformances before they occur, based on risk analysis rather than on actual failures. The primary input to preventive action in manufacturing is the failure mode and effects analysis (FMEA): actions taken to reduce the occurrence rating or improve the detection rating of a high-risk failure mode are preventive actions. Other inputs include lessons learned from similar products or processes, results of process audits, trends in process capability data (for example, a capable process whose Cpk is drifting toward the specification limit), and industry experience with known failure modes.

ISO 9001:2015 integrates preventive action into the broader risk management framework of clause 6.1, treating it as a proactive element of risk-based thinking rather than a separate reactive process. IATF 16949 further requires that the PFMEA be linked to the control plan and that FMEA action items be tracked to completion and their effect on RPN verified after implementation.

Effectiveness verification

A CAPA is not complete when the corrective actions have been implemented: it is complete when the effectiveness of the actions has been verified. Effectiveness verification confirms that the root cause no longer exists in the process and that the non-conformance has not recurred. Verification methods include: re-inspection of product from the corrected process, monitoring of the relevant quality metric for a defined period after implementation (for example, 90 days of production with zero recurrence), process audit of the corrected work instruction or process, and analysis of non-conformance data to confirm the trend has changed.

The verification period and the acceptance criterion for closure must be defined before the CAPA is closed. Closing a CAPA on the basis of completed implementation, without evidence that the actions were effective, is a common audit finding and represents a fundamental misunderstanding of what CAPA is intended to accomplish.

Common errors in non-conformance management and CAPA

• Addressing containment as if it were corrective action. Containment (100% inspection of existing stock, recall of shipped product, temporary process controls) is a short-term protective measure, not a corrective action. CAPA must address root causes, not containment measures. Many CAPA systems are closed after containment is implemented, which means the root cause is never addressed and the non-conformance recurs.
• Stopping the root cause analysis at the symptom level. “The operator installed the wrong part” is a symptom, not a root cause. The root cause analysis must continue: why was the wrong part available at that station, why was the installation not prevented by mistake-proofing, why was the error not detected before the next operation? Only by answering these questions does the CAPA reach the systemic failure that, when corrected, prevents recurrence.
• Assigning corrective actions without target dates and responsible owners. A corrective action without a named responsible person and a specific target completion date is a wish, not a plan. It will not be implemented on schedule and will accumulate in an aging CAPA backlog that eventually requires a management review to clean up.
• Closing CAPAs without effectiveness verification. Implementing the corrective action is not the same as verifying that the corrective action worked. Closure before verification is the most common reason that the same non-conformance recurs after CAPA closure.

Frequently asked questions

What is the difference between a corrective action and a preventive action?

A corrective action addresses a non-conformance that has already occurred: it investigates the root cause of the failure and implements changes to prevent recurrence. The trigger for a corrective action is an actual non-conformance, customer complaint, audit finding, or other evidence that a requirement was not met. A preventive action addresses a potential non-conformance that has not yet occurred: it identifies a risk of future failure and implements changes to prevent occurrence. The trigger for a preventive action is a risk analysis, trend analysis, FMEA review, or other evidence that a failure could occur even though it has not yet happened. In ISO 9001:2015, preventive action is embedded within the risk-based thinking framework (clause 6.1) rather than specified as a separate procedure, which is a change from the 2008 version of the standard where preventive action had its own explicit clause (8.5.3). In practice, the most common source of preventive actions is the FMEA: high-RPN items are addressed through preventive actions before the process goes to production, rather than waiting for the failure mode to occur and then writing a corrective action.

What does “use as-is” mean in non-conformance disposition and when is it acceptable?

A “use as-is” disposition means that a non-conforming item is accepted and used without any rework or repair, despite not meeting the specified requirement as written. A use-as-is disposition is acceptable when an engineering review concludes that the specific non-conformance has no adverse effect on the item’s fitness for its intended purpose: it does not affect the item’s function, fit, form, safety, regulatory compliance, or reliability. The engineering justification must be documented, specifying which requirement was not met, what the actual condition is, and why that condition does not affect the item’s fitness for use. In most industry quality systems, use-as-is dispositions above a defined severity level require customer notification and approval before the non-conforming item is used or shipped. In aerospace (AS9100 and AS9102) and automotive (IATF 16949), customer approval is typically required for any use-as-is disposition on items shipped to the customer, and the approval must be documented. A use-as-is disposition does not relieve the organization of the obligation to investigate whether the non-conformance represents a systemic problem that requires CAPA.

How does CAPA differ from the 8D problem-solving process?

CAPA (corrective and preventive action) is a quality management system process framework: it defines the overall structure of how the organization identifies, investigates, corrects, and prevents non-conformances, and it is a documented procedure within the QMS that satisfies the requirements of ISO 9001 clause 10.2. The 8D (eight disciplines) process is a specific problem-solving methodology: it provides a structured sequence of steps (D1 through D8) for investigating and resolving a quality problem, including team formation, interim containment, root cause verification, permanent corrective action, and prevention. The 8D process can be used as the problem-solving methodology within a CAPA: when a CAPA is opened, the investigation and corrective action planning may be conducted using the 8D structured approach. The CAPA record documents the overall process including initiation, investigation, action planning, implementation, and effectiveness verification, while the 8D report documents the detailed problem-solving work within the investigation and action planning phases. In the automotive industry, customer-facing CAPAs are frequently documented in 8D format because major automotive customers (Ford, GM, Stellantis) require the 8D report as the standard corrective action response format.

What is the systemic cause in root cause analysis and why does it matter?

The systemic cause is the failure in the quality system or management system that allowed the direct cause of a non-conformance to exist and go undetected. Every non-conformance has at least two levels of cause: the direct cause (the immediate technical reason the failure occurred) and the systemic cause (the reason the system failed to prevent or detect the direct cause before the non-conformance was created). For example, if a non-conformance was caused by an operator using an incorrect process parameter, the direct cause is the incorrect parameter setting. The systemic causes might include: no documented work instruction specifying the correct parameter; a work instruction that was not updated after the last engineering change; no training verification that the operator knew the correct parameter; or no process control that would have prevented the incorrect parameter from being set. A CAPA that addresses only the direct cause will eliminate this specific failure mode but leave the same systemic gaps available to produce the next non-conformance from a different direct cause. A CAPA that also addresses the systemic causes — by improving the work instruction system, the change management process, the training verification process, or the process control — strengthens the quality system in ways that prevent a broad class of future non-conformances, not just the one that occurred. Systemic cause analysis is what separates a truly effective CAPA program from one that recycles the same categories of problems indefinitely.

What does IATF 16949 require for CAPA beyond ISO 9001?

IATF 16949 (the automotive quality management system standard) adds several requirements beyond the baseline ISO 9001 CAPA framework. Key additions include: (1) Problem-solving methodology: IATF 16949 clause 10.2.3 requires that the organization use a structured, multidisciplinary problem-solving methodology — the 8D process is the most common automotive choice. (2) Error-proofing in corrective actions: IATF 16949 clause 10.2.4 requires that corrective actions include error-proofing (poka-yoke) methods where appropriate, rather than relying on increased inspection as the primary corrective action. (3) Escape cause analysis: IATF 16949 requires investigation of not only the production root cause (why the non-conformance was created) but also the escape cause (why the non-conformance was not detected before reaching the customer). Separate corrective actions must address the escape cause. (4) Customer-specific requirements: major automotive customers (Ford, GM, Stellantis, BMW, etc.) have their own specific CAPA response format and timing requirements (typically 24-hour initial response, 30-day final response for 8D completion) that are imposed on suppliers through customer-specific requirements (CSRs) and must be followed in addition to the standard IATF 16949 requirements. (5) Warranty management: IATF 16949 requires that warranty data be analyzed to identify failure modes that require CAPA, and that the no-trouble-found (NTF) rate for warranty returns be tracked and reduced.

How should CAPA effectiveness be verified and when can a CAPA be closed?

CAPA effectiveness verification confirms that the implemented corrective actions have eliminated the root cause and that the non-conformance has not recurred. Before a CAPA can be closed, the effectiveness verification must be completed and the results must meet the acceptance criteria defined in the CAPA plan. Common verification methods include: monitoring the relevant quality metric (defect rate, customer complaint rate, process capability index) for a defined period after implementation and confirming that the metric has improved to the target level; re-auditing the process or area where the corrective action was implemented to verify that the changes are sustained; sampling and inspecting product produced under the corrected process to confirm that the non-conformance no longer occurs; and reviewing non-conformance data for the same failure mode over the defined monitoring period to confirm zero recurrence. The monitoring period should be defined based on production volume and process frequency: a low-volume process that produces one lot per month needs a longer monitoring period in calendar time than a high-volume process that produces hundreds of lots per week. A CAPA should not be closed on the basis of completed action implementation alone. The question is not “did we implement the actions?” but “did the actions work?” If the effectiveness verification shows that the actions did not fully eliminate the root cause, the CAPA must be reopened or supplemented with additional actions, and the verification cycle must repeat.