AS9100D requires an organization to identify and control nonconforming outputs so they are not unintentionally used, released, or delivered. In practical terms, that means documented controls for containment, review, disposition, approval authority, customer notification where required, verification after correction, and retained records showing what was found and what was done. It does not mandate a specific software tool, NCR form, or workflow design.
The requirement applies broadly. Nonconforming outputs can include internally produced product, externally provided product or service, work in process, delivered product, or a nonconformance identified by the customer. The exact handling depends on the product, contract, design authority, customer flowdowns, and the organization’s quality management system.
Core controls AS9100D expects
At FAQ depth, the main expectations are:
- Identification and control: Nonconforming outputs must be clearly identified and controlled to prevent unintended use or delivery.
- Containment: The organization must take action appropriate to the nature and effect of the nonconformity, including impact on related parts, processes, lots, or services.
- Disposition: The output must be handled through an approved disposition path, such as correction, segregation, containment, return, suspension of service, scrap, rework, repair, or request for concession.
- Approval authority: Responsibility and authority for review and disposition must be defined. In aerospace, use-as-is and repair dispositions are especially sensitive because they may require approval by the design authority or delegated authority.
- Customer involvement: The customer must be informed or authorization obtained when required by contract, regulation, customer-specific requirement, or the nature of the nonconformity.
- Verification after correction: Corrected outputs must be verified to confirm they now meet requirements.
- Records: The organization must retain documented information describing the nonconformity, actions taken, concessions obtained, and the authority that decided the disposition.
Correction is not always corrective action
AS9100D control of nonconforming outputs is not the same as requiring a full corrective action for every defect. A one-time nonconformance may be corrected and recorded without a formal CAPA, depending on risk and local procedure. Repeated defects, escaped defects, customer-impacting issues, or systemic failures commonly trigger root cause and corrective action under the broader QMS.
Where brownfield systems usually matter
In a mature aerospace or regulated manufacturing environment, nonconformance control often spans MES, ERP, PLM, QMS, inspection systems, and sometimes maintenance or supplier portals. The NCR may live in the QMS, the inventory hold in ERP, the routing block in MES, the drawing authority in PLM, and the customer communication in a separate portal.
This is where failures often occur. A part can be dispositioned in one system while still appearing available in another. A rework instruction can be released without the right design approval. A concession can be granted but not linked to the affected serial numbers, lots, or shipment records. AS9100D does not require system replacement, and full replacement is often unrealistic in brownfield aerospace environments because of qualification burden, validation cost, downtime risk, integration complexity, traceability obligations, and long asset lifecycles. The practical requirement is controlled, validated, traceable execution across the systems that remain in use.
Common audit evidence
Auditors typically look for evidence that the process is defined and followed, not just that a procedure exists. Useful evidence usually includes NCR records, hold or segregation records, disposition approvals, rework or repair instructions, concession records, customer notifications where applicable, verification results after correction, and links to affected lots, serial numbers, orders, suppliers, or shipments.
No system or procedure guarantees an audit outcome. The weakness is usually not the wording of the procedure; it is inconsistent execution, unclear authority, poor integration between systems, missing records, or dispositions that exceed the authority granted by the customer, contract, or design organization.