Connect981 – Content Dev

RSC Content Type: FAQ

Direct answers to common technical or compliance questions.

  • What is AS9100 used for?

    AS9100 is used as the aerospace and defense sector’s quality management system (QMS) framework. It specifies how organizations plan, control, document, and continually improve the processes that affect product quality, safety, and reliability. It builds on ISO 9001 with added requirements specific to aviation, space, and defense.

    Primary uses of AS9100 in operations

    In industrial and manufacturing environments, AS9100 is typically used to:

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    • Define and structure the quality management system by setting expectations for documented procedures, process ownership, metrics, and management review.
    • Control product realization from contract review through design, planning, production, inspection, and delivery, including first article inspection and configuration control.
    • Manage risk by requiring formal approaches to risk assessment, nonconformance handling, and corrective and preventive action.
    • Strengthen supplier management through requirements for supplier evaluation, flowdown of requirements, and control of externally provided processes, products, and services.
    • Ensure traceability of parts, materials, processes, and records at a level appropriate to aerospace and defense products.
    • Standardize documentation and records so that work instructions, forms, test results, and inspection data are controlled, current, and retrievable.
    • Support internal and external audits by giving a common structure and language for assessing process effectiveness across sites and suppliers.

    Where AS9100 shows up in day-to-day work

    AS9100 requirements are typically embedded into existing systems and processes rather than implemented in isolation. Examples include:

    • Quality management and QMS tools: Document control workflows, change approval, and record retention rules are aligned to AS9100 clauses.
    • Manufacturing operations: Routing approvals, in-process inspections, and production sign-offs are structured to provide the traceable evidence AS9100 expects.
    • IT and data systems: ERP, MES, PLM, and QMS integrations are configured to maintain configuration control, revision consistency, and audit trails.
    • Problem solving: Corrective action processes, root cause analysis, and effectiveness checks are designed to meet AS9100 expectations for nonconformity and CAPA management.

    Limitations and dependencies

    AS9100 is a standard, not a tool or a guarantee. Its effectiveness depends heavily on:

    • Process maturity: Weak or undocumented processes will not become robust simply by referencing AS9100. They need redesign, resourcing, and discipline.
    • System integration quality: In brownfield environments, disconnected ERP, MES, PLM, and QMS systems make it hard to achieve the traceability and configuration control AS9100 expects without additional integration or manual controls.
    • Change control: Frequent, poorly controlled system or process changes undermine the stability that AS9100 auditors look for, even if procedures exist on paper.
    • Validation and evidence: For regulated aerospace and defense work, you must be able to show objective evidence that your processes are implemented as described, not just that you have AS9100-aligned documents.

    Using AS9100 as a framework does not by itself provide certification, guarantee audit outcomes, or ensure regulatory compliance. Certification requires a separate accredited audit, and regulatory approvals depend on specific program and authority requirements.

    Coexistence with existing systems and long-lifecycle assets

    In most aerospace and defense plants, AS9100 is layered onto existing, mixed-vendor systems rather than driving wholesale replacement. Full replacement of core systems (ERP, MES, PLM, QMS) purely for AS9100 alignment often fails or stalls because of:

    • Qualification and validation burden for flight-critical or defense-related programs.
    • Downtime risk to production lines and test assets that operate on long cycles and cannot be easily stopped and requalified.
    • Integration complexity across legacy and new systems that both feed required AS9100 evidence.
    • Traceability and change control requirements that make large, rapid changes difficult to justify.

    As a result, organizations usually map AS9100 requirements onto the current landscape, closing gaps through targeted process changes, added controls, or incremental system enhancements instead of trying to rebuild everything at once.

  • Is ISO 13485 based on ISO 9001:2015 or an earlier version?

    ISO 13485:2016 is based on ISO 9001:2008, not ISO 9001:2015.

    When ISO 13485 was last revised (2016), the technical committee intentionally aligned it with the 2008 version of ISO 9001 to maintain stability for regulated medical device quality management systems and regulators. As a result:

    In practice, this connects to qms integration and evidence trails when teams need to turn the answer into repeatable execution habits.

    • ISO 13485:2016 keeps the ISO 9001:2008-style clause structure (not the Annex SL high-level structure used in ISO 9001:2015).
    • It does not fully adopt ISO 9001:2015 concepts such as organization-wide risk-based thinking in the same form, although it has extensive, more specific risk management requirements for medical devices.
    • Some terminology and clause references differ from ISO 9001:2015, which complicates direct one-to-one mappings in integrated QMS deployments.

    In brownfield environments where a site already uses ISO 9001:2015 for general operations and ISO 13485 for medical device lines or business units, this misalignment means:

    • You cannot assume a common clause structure across both standards; mappings must be explicit and documented.
    • Electronic QMS, MES, and document control systems need carefully configured workflows and metadata so records support both standards without implying full equivalence.
    • Change control and validation for shared processes (e.g., CAPA, document control, training) must show how each requirement from ISO 13485 and ISO 9001:2015 is individually addressed.

    Future revisions of ISO 13485 may move closer to ISO 9001:2015, but any such change would require careful impact assessment, revalidation of computerized systems, and updated mappings in regulated manufacturing environments.

  • What are the types of non-conformance?

    There is no single universal classification of non-conformance that applies to every regulated manufacturer. The exact types and definitions should be set in your QMS, procedures, and electronic systems (QMS/MES/ERP) and then validated and trained against. That said, most organizations use a consistent set of dimensions to categorize non-conformances.

    1. Product vs. system non-conformance

    Product non-conformance typically covers issues where a specific part, batch, lot, or unit does not meet a defined requirement, such as:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • Dimensional or functional out-of-tolerance
    • Wrong material, component, or revision used
    • Contamination, cosmetic defects, or damage
    • Labeling, traceability marks, or documentation missing for a given lot

    System or process non-conformance usually refers to failures of the management system or process rather than one specific unit:

    • Procedure not followed or unclear work instructions
    • Calibration system lapse, expired tooling, or unqualified equipment usage
    • Training gaps or personnel working without required qualification
    • Breakdown in document control, change control, or record retention

    In practice, product and system non-conformances often coexist: a product issue frequently exposes an underlying process weakness that should be addressed via CAPA.

    2. Critical, major, and minor non-conformance

    Many regulated plants use a severity scale. The exact criteria must be defined locally, but a common pattern is:

    • Critical non-conformance: Could reasonably lead to unsafe product, regulatory breach, or major customer impact if not detected (e.g., wrong material in a safety-critical component, missing required inspection on serialized aircraft parts).
    • Major non-conformance: A significant requirement is not met, but immediate safety impact is controlled (e.g., incomplete batch records, wrong revision of a non-safety drawing, repeated minor defects indicating process drift).
    • Minor non-conformance: Low risk, localized, often cosmetic or administrative (e.g., isolated labeling error with easy recovery, minor cosmetic defect within customer-accepted ranges).

    Severity levels affect required actions, approvals, documentation detail, and sometimes customer notification. In a brownfield environment, these categories often need to be mapped consistently across multiple legacy systems (QMS, MES, LIMS, ERP) to avoid conflicting severity logic.

    3. Internal vs. external non-conformance

    Another common dimension is where the issue is detected or originates:

    • Internal non-conformance: Found within your own operations (in-process checks, final inspection, in-house audits, lab testing, maintenance). These usually allow more controlled handling and rework options.
    • External non-conformance: Involves parties outside your direct control, such as:
      • Supplier non-conformance: Incoming material or components that fail specification.
      • Customer-returned non-conformance: Complaints, returns, or field failures.
      • Regulatory or third-party audit non-conformance: Observations against standards or licenses.

    External non-conformances typically trigger additional requirements such as supplier corrective action requests, customer communication, or formal CAPA, and they must be carefully linked to contracts, specifications, and regulatory submissions.

    4. Conforming vs. nonconforming material disposition types

    While not strictly “types of non-conformance,” many plants classify nonconforming material by its disposition category, because this drives risk, cost, and system configuration:

    • Use as is: Deviation/waiver is granted to accept the nonconformance without change. In regulated environments, this generally needs strong justification, risk assessment, and traceable approval.
    • Rework: Material can be brought into full conformance using an approved, validated process.
    • Repair: Material is made fit for use but may not fully meet original specifications; may require engineering justification and, in some industries, customer or regulatory approval.
    • Scrap: Material is not recoverable or not acceptable to rework/repair.
    • Return to supplier: Nonconforming items are sent back with appropriate records.

    In brownfield environments, you often have to align these disposition types across MES, ERP inventory statuses, and QMS workflows. Misalignment here is a frequent source of traceability gaps and audit findings.

    5. Process, equipment, and documentation non-conformance

    Many QMS frameworks further distinguish by the element of the system that failed:

    • Process non-conformance: Process parameter outside limits, uncontrolled change in sequence, or missing required verification. Example: heat treatment cycle not meeting specified time/temperature profile.
    • Equipment non-conformance: Equipment out of calibration, operating outside validated range, or maintained late. Example: CNC machine with overdue calibration producing unknown number of parts.
    • Documentation non-conformance: Incomplete, inaccurate, or obsolete records, drawings, procedures, or work instructions. Example: operator used a superseded work instruction revision.

    These categories are useful for trend analysis and for linking non-conformances to CAPA, maintenance, and change control records.

    6. Regulatory or standard-specific non-conformance types

    Some standards and regulators define additional or specific non-conformance categories that you may need to mirror or map in your systems. Examples include:

    • Audit findings categorized as critical/major/minor or similar wording.
    • Labeling and traceability non-conformances treated separately due to regulatory exposure.
    • Data integrity or record-keeping non-conformances called out explicitly.

    Where this is the case, your internal types usually need to be traceably mapped to the external categories for reporting and audit readiness. This mapping is a common integration challenge when you have multiple legacy QMS or point solutions still in use.

    7. How to define types in a brownfield, regulated environment

    In practice, your “types of non-conformance” should be defined and maintained through controlled documents and validated systems, not ad hoc lists. When updating or harmonizing types across plants or systems, consider:

    • Alignment with existing procedures and records: Changing types affects trending, historical metrics, and audit trails. You may need a transition plan and clear mapping.
    • System constraints: Legacy MES/QMS/ERP tools may limit field types, dropdown values, or workflows. Full replacement just to change categories is rarely justified given validation and downtime burdens.
    • Risk-based clarity: Types should support risk assessment and decision-making, not just reporting. If users cannot reliably distinguish between categories, the scheme is too complex or poorly defined.
    • Traceability: Ensure that non-conformance types can be linked to batches, serial numbers, equipment, documents, and changes. Incomplete linkage is a common failure mode in audits.

    For most sites, the practical solution is to standardize a small, well-defined set of non-conformance types across systems, then map historical and site-specific variants into that model through controlled change.

  • Can small organizations exclude any ISO 9001 clauses from their scope?

    Small organizations cannot exclude ISO 9001:2015 clauses simply because of their size. The current standard does not permit broad clause-by-clause “exclusions” as ISO 9001:2008 did. Instead, it requires that:

    • All requirements that are applicable to the organization’s products and services are implemented, and
    • Any requirement that does not apply to the organization’s activities is treated as “not applicable” and justified in the scope of the QMS.

    What “not applicable” really means in ISO 9001:2015

    Under ISO 9001:2015, you do not remove entire clauses because you are small. You determine, based on your business model and processes, which specific requirements do not apply and why. Typical, defensible “not applicable” cases include:

    In practice, this connects to the ISO 9001 quality baseline when teams need to turn the answer into repeatable execution habits.

    • Design and development requirements if you truly perform no design and build only to fully defined customer or regulatory specifications.
    • Post-delivery activities that are not relevant if you have no warranty, servicing, or field support obligations, and no regulatory or contractual expectations in that area.
    • External provision of processes, products, and services details that do not apply if you do not outsource at all (rare in practice).

    In each case, the justification must be traceable to the nature of your products and services, not to your headcount or revenue.

    Constraints and expectations in regulated, industrial environments

    In aerospace and other regulated manufacturing contexts, the bar for claiming a requirement is “not applicable” is higher:

    • Customer contracts, regulatory requirements, and sector standards (for example, AS9100) may effectively reintroduce requirements you hoped to omit.
    • Prime contractors and OEMs often expect design, configuration control, and post-delivery controls even for small suppliers, because they need traceability and risk control across the supply chain.
    • Auditors will test your justification against what you actually do in your operations, not only what is written in procedures.

    For example, if you say design is not applicable but you regularly interpret incomplete customer drawings, choose materials, or modify configurations, an auditor may determine you are performing design or development activities and expect those requirements to be applied.

    How to approach scope and applicability as a small organization

    For a small manufacturer or MRO provider, a practical approach is:

    1. Map your real activities: Sales, contract review, purchasing, production, inspection, test, delivery, service, and change control across existing MES, ERP, and QMS tools.
    2. Compare to ISO 9001 clauses: Identify which requirements clearly apply and which might be candidates for “not applicable.” Be careful with borderline areas like design, post-delivery support, and control of externally provided processes.
    3. Check against customer and regulatory requirements: A requirement is not truly optional if contracts, flowdown clauses, or regulations demand it, even if ISO 9001 alone might allow you to treat it as not applicable.
    4. Document your justification: In your QMS scope statement and supporting documentation, clearly state any non-applicable requirements and the operational reason for each.
    5. Align with existing systems: In brownfield environments, your MES/ERP/PLM/QMS stack may already implement controls that touch a clause you hoped to omit. In practice, it can be simpler and lower risk to explicitly include such requirements than to argue they do not apply.

    Why “we are small” is not enough

    ISO 9001 is written to be scalable. A 20-person shop and a 2,000-person plant both apply the same clauses but with different levels of formality and tooling. The standard expects that:

    • You may implement simpler controls, fewer records, and leaner documentation if your processes and risks are simpler.
    • You do not discard whole requirement areas (such as risk-based thinking, competence, document control, or internal audits) because you have limited staff.

    Relying on organizational size alone as the rationale for excluding requirements is risky and unlikely to withstand an audit in defense or aerospace supply chains.

    Key takeaway

    Small organizations cannot exclude ISO 9001 clauses just because they are small. You must:

    • Apply all requirements relevant to what you actually do.
    • Justify any “not applicable” requirements in your scope based on your activities, contracts, and regulatory obligations.
    • Expect customers and auditors in regulated sectors to scrutinize these decisions closely, especially for design, outsourcing, and post-delivery controls.

  • When is root cause analysis required under ISO 9001?

    ISO 9001 does not require a formal root cause analysis for every defect, deviation, or complaint. It requires you to determine causes when you take corrective action for nonconformities that are significant enough to warrant preventing recurrence.

    What ISO 9001 actually requires

    The core requirement is in ISO 9001:2015 clause 10.2 (Nonconformity and corrective action). When a nonconformity occurs and you decide that corrective action is necessary, you must:

    In practice, this connects to the ISO 9001 quality baseline when teams need to turn the answer into repeatable execution habits.

    • Review and analyze the nonconformity (including complaints when relevant).
    • Determine the causes of the nonconformity.
    • Determine if similar nonconformities exist, or could potentially occur.

    That determination of causes is where root cause analysis (RCA) comes in. ISO 9001 does not prescribe a specific method (5-Whys, fishbone, 8D, etc.), only that causes are understood well enough to support effective corrective action.

    When root cause analysis is required by ISO 9001

    Under ISO 9001, you are expected to perform cause analysis (and usually a formal RCA) when:

    • A corrective action is raised under your QMS procedures.
    • A nonconformity is recurring or systemic, even if individual events seem minor.
    • Customer complaints or escapes indicate a breakdown in your controls.
    • Internal or external audits identify significant nonconformities that you choose to address via corrective action.
    • Risk-based thinking flags the issue as high risk to product conformity, safety, regulatory expectations, or business continuity.

    In practice, you are required to show that, for each corrective action, you have:

    • Identified the root or contributing causes, not just the symptom.
    • Implemented actions that logically address those causes.
    • Verified the effectiveness of those actions over time.

    When root cause analysis is not strictly required

    ISO 9001 allows you to treat some issues with corrections only (fix the problem) without full corrective action. In those cases, a formal RCA is not mandated by the standard, as long as:

    • The issue is isolated and low risk.
    • There is no evidence of recurrence or systemic failure.
    • Your own procedures do not require a corrective action and RCA for that class of issue.

    Examples might include a one-off documentation error caught before release, or an operator mistake with no product impact and clear, immediate containment. However, in regulated or aerospace environments, many organizations voluntarily apply stricter triggers than ISO 9001 alone because of safety, contractual, or customer expectations.

    Internal triggers usually go beyond ISO 9001

    Most mature, regulated manufacturers define internal criteria that effectively require formal RCA in more situations than the standard minimally demands. Common triggers include:

    • Repeated nonconformances of the same defect mode or on the same asset, line, or cell.
    • Nonconformances affecting critical characteristics, safety, airworthiness, or regulatory compliance.
    • Customer returns, escapes, or formal complaints.
    • Significant COPQ (scrap, rework, warranty cost, delays).
    • Major or repeated audit findings (internal, customer, or certification).

    These criteria are usually documented in QMS procedures or CAPA / NCR work instructions. Under audit, you are measured against both the ISO 9001 requirements and your own defined process. If your procedure says a given trigger requires RCA and corrective action, failure to apply RCA in that scenario is a nonconformity even if ISO 9001 itself would have allowed a lighter response.

    Brownfield reality: systems, traceability, and evidence

    In mixed legacy environments (ERP, MES, QMS, PLM from multiple vendors), the main challenge is not the method of RCA but the evidence trail that links:

    • The nonconformance or complaint.
    • The investigation and root cause analysis.
    • The selected corrective actions and changes to processes, documentation, or equipment.
    • The verification of effectiveness over time.

    If your RCA and CAPA records sit in a separate point solution, you must ensure:

    • Clear linkage to NCRs, work orders, and relevant configuration or routing revisions.
    • Controlled, versioned changes to work instructions, travelers, and inspection plans remain traceable to the root cause and corrective action.
    • Evidence of ongoing monitoring (e.g., defect trend charts, sampling results) can be shown during audits to demonstrate effectiveness.

    Organizations that try to “rip and replace” QMS or MES to improve RCA visibility often run into major hurdles: validation burden, long equipment lifecycles, production downtime risk, and complex integrations with existing NCR, MRB, and CAPA workflows. A more realistic path is usually to:

    • Standardize RCA methods and triggers first (process), then
    • Incrementally improve system connections and evidence capture across existing tools.

    Key takeaways

    • ISO 9001 requires cause determination whenever you implement corrective action for a nonconformity.
    • It does not require formal RCA for every defect or minor issue handled by correction only.
    • Your internal procedures and risk criteria usually define stricter, practical triggers in regulated manufacturing.
    • In brownfield plants, the main risk is not lack of RCA tools, but weak linkage between RCA, NCR/CAPA records, process changes, and effectiveness evidence.

  • Do all aerospace suppliers have to comply with AS9102 Rev C?

    No. Aerospace suppliers are not automatically required to comply with AS9102 Rev C. Compliance depends on what is contractually required by your customer and what your own quality system and procedures specify.

    When AS9102 Rev C typically applies

    AS9102 is a standard for First Article Inspection (FAI). In practice, you are expected to comply with AS9102 Rev C when one or more of the following are true:

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    • The customer (prime or Tier 1) explicitly invokes AS9102 on the purchase order, statement of work, or quality clauses.
    • Your customer’s quality requirements reference AS9102 and specifically call out Rev C.
    • Your organization’s QMS procedures state that FAIs will be performed to AS9102 (and those procedures are the basis for your internal or external audits).
    • You participate in a customer portal or digital FAI workflow (for example Net-Inspect) that has been updated to require Rev C forms and rules.

    If none of these apply, you are not automatically required to use AS9102, and you are not forced to move from Rev B to Rev C unless your customer or internal procedures say so.

    Contract and flowdown determine the obligation

    In regulated aerospace supply chains, the controlling documents are contracts, POs, and associated quality clauses. These define:

    • Whether FAI is required at all for a given part or assembly.
    • Which standard applies (AS9102 vs. customer-specific FAI formats).
    • Which revision (e.g., AS9102 Rev B vs. Rev C) and any customer-specific interpretations.
    • Scope and exceptions such as standard parts, commercial off-the-shelf items, or lower-risk hardware.

    Two similar parts for two different primes may have very different FAI expectations. You cannot safely generalize “all aerospace work must be AS9102 Rev C.” You need to treat this as a configuration-controlled requirement per customer, program, and sometimes per part family.

    AS9100 vs. AS9102: related but not identical requirements

    AS9100 (the aerospace QMS standard) expects that you control first article inspections in a structured way, but it does not itself force you to use AS9102 or a particular revision. Many primes use AS9102 as the default and flow it down, but that is a customer and industry practice, not a universal legal obligation.

    If you are AS9100-certified, your auditor will look for:

    • Evidence that you perform and control FAIs where required.
    • Alignment between your documented procedures and your actual practice.
    • Proper use of the standard you claim in your procedures (AS9102 Rev C if you say you follow Rev C).

    They do not automatically require AS9102 Rev C unless it is part of your documented system or customer flowdown.

    Common exceptions and edge cases

    Even when AS9102 Rev C is invoked, it often does not apply to every item you ship:

    • Standard parts / COTS: Many customers exempt standard hardware and catalog items. Check their quality clauses and the AS9102 exemption criteria.
    • Simple build-to-print machining and sheet metal: Some customers accept reduced-scope FAI packages or their own forms instead of full AS9102, especially for low-risk parts. Others do not. It is customer-specific.
    • Distributors and brokers: These organizations may not perform AS9102 FAIs themselves, but they may be required to collect and maintain FAI packages from upstream manufacturers.
    • Repair and MRO work: First article expectations can be different for repair/overhaul vs. new production. AS9102 may not be the controlling standard for MRO unless specifically invoked.

    Rev B vs. Rev C migration considerations

    Many suppliers operate in brownfield environments with a mix of AS9102 Rev B and Rev C requirements depending on customer and program. Some realities to account for:

    • Customer-by-customer transition: Some primes mandate Rev C on all new or changed parts; others are slower to transition and still accept Rev B FAIs. You may need to support both simultaneously.
    • Legacy FAI packages: Existing, accepted FAIs built under Rev B are rarely reworked just to meet Rev C, unless a significant design or process change triggers a new or partial FAI and the customer explicitly requires Rev C going forward.
    • System coexistence: Older PLM, MES, or QMS tools may embed Rev B assumptions (fields, forms, ballooning conventions). Updating to Rev C often requires careful configuration, validation, and controlled rollout to avoid mismatched forms and data loss.
    • Validation burden: In regulated, long-lifecycle programs, changing FAI processes or software (e.g., adopting digital AS9102 Rev C in Net-Inspect or another system) can trigger validation, retraining, and documentation updates. Many plants delay migration until a customer or major program forces the change.

    Practical steps for suppliers

    To avoid incorrect assumptions and rework, suppliers should:

    • Map requirements per customer and program: Maintain a controlled matrix that clearly lists which customers require AS9102, which revision, and any exceptions.
    • Lock this into your QMS: Ensure your FAI procedure references how you determine when to use AS9102 and which revision, rather than assuming a single rule fits all work.
    • Align systems and forms: Configure your FAI templates, digital FAI tools, or MES/QMS forms so they match the required revision and customer-specific rules. In mixed environments, provide clear operator guidance on which template to use when.
    • Control changes: Treat migration to Rev C as a formal change: update procedures, train staff, and preserve traceability between old and new formats. Avoid ad hoc switchovers that create confusion during audits.
    • Clarify ambiguous cases with customers: When requirements are silent or contradictory (e.g., AS9100 referenced but not AS9102; or Rev not specified), seek written clarification rather than guessing.

    Summary

    AS9102 Rev C is widely adopted but not universally or automatically mandatory for every aerospace supplier. Its applicability is defined by customer flowdown and your own QMS. Many suppliers must support both legacy and current revisions in a brownfield stack of systems and programs, which makes configuration control, change management, and traceability essential.

  • How do you decide whether a change requires partial or delta FAI?

    There is no universal rule that fits every program or customer. The decision between a partial FAI and a delta FAI is driven by three things: the governing standard (AS9102 or equivalent), customer / contractual requirements, and your internal FAI and change-control procedures. Within those boundaries, the basic logic is to trace what changed and reverify only the characteristics and process elements affected by that change.

    Start from the governing requirements

    Before deciding scope, confirm:

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    • Which revision of AS9102 (or other standard) applies.
    • Customer-specific FAI or PPAP-like requirements, including any mandated triggers for full vs partial FAI.
    • Contract or PO language that may override your internal practice (for example, requiring full FAI when drawing revisions change, regardless of impact).
    • Your internal FAI procedure and how it defines initial, partial, and delta FAI, including required approvals.

    If there is a conflict, customer and contractual requirements typically take precedence over internal practice, as long as they do not contradict the base standard.

    When a partial FAI is typically required

    A partial FAI is generally used when the form, fit, or function could be affected, but not all characteristics or operations are impacted. Typical triggers (subject to customer rules) include:

    • Drawing, model, or specification revision that changes some, but not all, features.
    • Process flow or work instruction changes that impact a subset of characteristics, operations, or setups.
    • Significant NC/CAPA-driven changes where corrective actions modify methods, tooling, or parameters relevant to specific features.
    • Tooling, fixture, or program changes that could influence dimensions, orientation, or repeatability for targeted features.
    • Material or source changes that may affect mechanical, thermal, or surface performance for certain characteristics only.

    In a partial FAI you:

    • Use the current FAI format (e.g., AS9102 forms) for the part.
    • Identify only the characteristics and records impacted by the change.
    • Reverify and document those items, referencing the baseline (initial) FAI for unchanged characteristics.

    Unchanged characteristics are typically not re-measured but must still be traceable back to a previously accepted FAI package.

    When a delta FAI is typically sufficient

    In practice, many organizations use the term “delta FAI” for an even narrower scope than a formal partial FAI. This is usually appropriate when:

    • The change is extremely localized (e.g., a single dimension, tolerance, or note clarified without impacting related features).
    • A previously nonconforming characteristic has been corrected with no changes to the rest of the design or process.
    • A minor CNC program tweak, offset change, or fixture adjustment affects one or a few dimensions only.
    • Minor gage or method change affects how one characteristic is measured, not its underlying process capability.

    In a delta FAI you typically:

    • Document only the specific characteristics that changed or were corrected.
    • Reference the last accepted (initial or partial) FAI package as the baseline.
    • Show clear traceability from the change record (ECO, deviation close-out, CAPA) to the updated characteristic results.

    Some customers do not formally distinguish between “partial” and “delta” and expect any reduced-scope activity to follow their partial FAI rules. In those cases, treat delta FAI as a subcategory of partial FAI and align with their terminology to avoid audit issues.

    Risk- and impact-based decision process

    Most robust procedures use a structured impact assessment to decide whether you need full, partial, or delta FAI. A practical approach is:

    1. Identify the change driver
      Examples: drawing revision, model update, new material, process change, machine move, NC/CAPA, new supplier, or significant lapse in production.
    2. Map the change to affected items
      Using ECN/ECR, PLM, or configuration management, determine which of the following are touched:
      • Design characteristics (dimensions, GD&T, material specs, surface requirements).
      • Manufacturing operations, routings, or setups.
      • Tooling, fixtures, programs, or inspection methods.
      • Suppliers or special processes (heat treat, plating, NDT).
    3. Assess potential impact to form, fit, function, or safety
      If there is any plausible impact, err toward at least a partial FAI unless the customer has explicitly waived it.
    4. Define the FAI scope
      Based on the mapping:
      • Full FAI: major design change, new part number, new manufacturing site, or fundamentally different process path.
      • Partial FAI: multiple affected features, operations, or materials, but the part number and core design intent remain the same.
      • Delta FAI: tightly localized change or correction affecting one or a very small number of characteristics.
    5. Document the rationale
      Record why you chose partial vs delta (risk, impact analysis, customer requirements) and get appropriate approvals. This is often what auditors ask to see.

    Brownfield and system coexistence considerations

    In mixed PLM/MES/QMS environments, the main risk is missing impacted characteristics because design, routing, and inspection data are spread across systems. To make reliable partial/delta FAI decisions, you need:

    • Good configuration control so that the FAI is clearly tied to a specific drawing/model revision, routing, and work instruction set.
    • Traceable ballooning and characteristic lists that link drawing items to operations, tools, and inspection plans, even if those live in different systems.
    • Clear integration or at least stable reference IDs so that when an ECO hits the PLM, affected characteristics in MES or inspection software can be reliably identified.
    • Robust change control so process or tooling changes outside PLM (for example, on the shop floor or at suppliers) still trigger a formal FAI impact review.

    Trying to replace all core systems at once to “fix” FAI is usually impractical in aerospace-grade or similarly regulated environments due to validation, downtime, and integration risk. A more realistic approach is to tighten FAI and change-control linkages between existing PLM, QMS, and MES systems and then selectively digitize FAI forms and ballooning.

    Common pitfalls in deciding partial vs delta FAI

    Typical failure modes to watch for include:

    • Treating all changes as paperwork-only and skipping the impact analysis, which can lead to missed FAIs and audit findings.
    • Informal “delta” checks done on the shop floor without documentation or linkage back to the formal FAI package.
    • Under-scoping partial FAI, for example updating one dimension but ignoring related datums, patterns, or GD&T that are indirectly affected.
    • Over-reliance on tribal knowledge where a single engineer decides scope without a documented method or peer review.
    • Ignoring supplier changes (special processes, raw material mills, outside machining) that should trigger partial FAI at the supplier or at incoming inspection.

    Practical guideline to distinguish partial vs delta FAI

    Within the constraints of your customer and internal procedures, a practical rule-of-thumb is:

    • If the change affects multiple features, operations, or process steps, treat it as a partial FAI.
    • If the change is constrained to one or a very small number of characteristics, with no ripple effects, a delta FAI is usually sufficient.
    • If you are unsure about impact, or the part is safety-critical, default to the more conservative scope or obtain written customer concurrence on the chosen approach.

    Ultimately, the decision must be backed by a documented impact assessment, consistent with AS9102 and customer-specific expectations, and traceable in your QMS.

  • What features should ISO 9001-focused QMS software include?

    ISO 9001 does not require any specific software, but in complex industrial and regulated environments most organizations use QMS software to make the system workable and auditable. An ISO 9001-focused QMS should support the full Plan-Do-Check-Act cycle, integrate with existing systems, and produce reliable evidence for audits without claiming compliance guarantees.

    Core document & record control

    At minimum, ISO 9001-focused QMS software should support:

    In practice, this connects to the ISO 9001 quality baseline when teams need to turn the answer into repeatable execution habits.

    • Document control for QMS documents (procedures, work instructions, quality plans), including:
      • Version control with full revision history and change rationale
      • Approval workflows with role-based signoff and timestamps
      • Controlled release and effective dates
      • Obsolescence handling and access to prior revisions for traceability
    • Record management for quality records (inspection results, training records, audits, NCRs, CAPAs), including:
      • Retention rules and disposition tracking
      • Searchable metadata (part, order, supplier, process, date)
      • Secure storage with backup and disaster recovery controlled by IT

    In brownfield plants, document control often straddles shared drives, PLM, MES, and QMS. The QMS must either integrate with or clearly reference the system of record for each document type to avoid version conflicts.

    Risk-based thinking & context

    ISO 9001 emphasizes risk-based thinking, but not a specific tool. Practical capabilities include:

    • Risk registers for organizational, process, and product risks, with owners and review cycles
    • Configurable risk scoring (likelihood, impact, detectability) with your own scales and criteria
    • Linking risks to controls and actions (procedures, training, process controls, CAPAs)
    • Evidence of risk review during changes, new products, and major process revisions

    Some organizations use separate tools for FMEA, process hazard analysis, and enterprise risk. The QMS should at least reference where these live and provide traceable links so auditors can follow the logic from risk to control to evidence.

    Nonconformance, corrective action, and improvement

    ISO 9001 clauses on nonconforming outputs and improvement are a major driver for QMS software. Useful features:

    • Nonconformance management (NCRs), including:
      • Configurable NCR forms for product, process, and supplier issues
      • Classification by severity, area, customer, part, and process
      • Integration or at least mapping to ERP/MES data (work order, batch, lot, serial)
      • Support for MRB, deviations, and concessions with decision logging
    • Corrective and preventive actions (CAPA) with:
      • Structured workflows for containment, root cause analysis, action planning, effectiveness checks
      • Owner and due date tracking, escalations for overdue items
      • Links between NCRs, complaints, audit findings, and CAPAs
      • Analytics on trends, recurrence, and closure time
    • Continuous improvement tracking (beyond formal CAPA), such as improvement ideas, kaizen events, and problem-solving projects if your culture supports it.

    Many plants already have NCR workflows in MES or ERP. In those cases, the QMS may function as the CAPA and analysis layer, pulling or referencing defect and scrap data instead of replacing the operational system.

    Audit management and evidence trails

    To support internal audits, external audits, and customer visits, the QMS should provide:

    • Internal audit planning with schedules, scopes, and auditor assignments
    • Configurable checklists aligned to ISO 9001 clauses and your own processes
    • Findings and observations tracking linked to NCRs or CAPAs where needed
    • Audit trail and traceability for key QMS changes (who changed what, when, and why)
    • Evidence management so each requirement or process has linked records that can be shown in an audit without file hunting

    For regulated sectors, granular audit trails and immutable logs are especially important. The software must make it easy to demonstrate that the documented system matches the executed system, but it cannot itself guarantee audit outcomes.

    Training, competence, and awareness

    ISO 9001 requires control of competence, not a specific LMS. Helpful software capabilities:

    • Role- and job-based training matrices mapping roles to required competencies and courses
    • Training records with completions, expirations, and recurrent requirements
    • Linkage from document changes to training so procedure revisions trigger training updates and acknowledgments where appropriate
    • Support for multiple training channels (classroom, on-the-job, e-learning) with consistent record capture

    In plants where HR systems or learning platforms are already in place, the QMS may only hold critical quality-related training records or provide references and links, rather than duplicating all HR training data.

    Change management and configuration control

    Robust change control is critical in long-lifecycle and aerospace-grade environments. QMS software should support:

    • QMS change control for policies, procedures, and process descriptions, with impact assessments and approvals
    • Traceability from change requests to risk assessments, training, and updated documents
    • Visibility into upcoming and recently implemented changes for operations, quality, and IT

    Product configuration (BOM, CAD, technical data) usually lives in PLM or ERP. The QMS should integrate with or reference those systems rather than trying to replace them, particularly in aerospace and other regulated sectors where requalifying PLM or ERP is extremely costly.

    Customer focus, complaints, and feedback

    To meet ISO 9001 requirements for customer focus and feedback, the QMS should make it practical to:

    • Log and classify customer complaints and inquiries, with linkage to orders, parts, and lots
    • Initiate NCRs and CAPAs from customer issues and trace them to closure
    • Capture customer satisfaction metrics if you track them (OTD, quality performance, survey results)
    • Generate inputs for management review about customer-related performance and risks

    Where CRM or service systems already exist, the QMS often consumes complaint and return data via integration instead of acting as the front-end for customer interactions.

    Management review, KPIs, and performance data

    ISO 9001 expects structured management review and use of data. QMS software should help by providing:

    • Configurable dashboards and reports for NCs, CAPA status, on-time closure, audit findings, and key quality KPIs
    • Support for management review records: agendas, minutes, decisions, and actions with follow-up tracking
    • Ability to ingest or reference data from ERP/MES for scrap, rework, delivery performance, and returns

    In most plants, quantitative performance data still comes from ERP/MES and data warehouses. The QMS should focus on linking these metrics to actions, risks, and decisions, instead of trying to become the primary data platform.

    Integration in brownfield environments

    In regulated, long-lifecycle operations, QMS software usually has to coexist with an existing stack that is expensive and risky to replace. Realistic integration expectations include:

    • Reference, not replacement, of ERP/MES/PLM as systems of record for orders, parts, and technical data
    • APIs or file-based interfaces to exchange key identifiers (work order, serials, lots, supplier codes) for traceability
    • Configurable master data mappings that can be maintained under change control
    • Clear data ownership definitions to avoid duplicate or conflicting records across systems

    Full replacement strategies for ERP or MES just to deploy new QMS functionality often fail due to qualification burden, downtime risk, validation costs, and the complexity of re-establishing traceability. In most cases, a layered QMS that integrates with existing systems is a lower-risk option.

    Security, access control, and validation

    Especially in aerospace, defense, and other regulated sectors, QMS software should support:

    • Role-based access control with least privilege for viewing, editing, and approving records
    • Configurable electronic signatures for approvals where appropriate, aligned with your regulatory context
    • Comprehensive system logs for configuration changes, permission changes, and data changes
    • Support for validation and change control (test evidence, configuration documentation, and repeatable deployment practices)

    Security baselines, network segregation, and compliance with standards like ISO 27001 or NIST controls are typically governed by your broader IT policies, not the QMS alone. The QMS should fit into that framework rather than defining it.

    Configuration, flexibility, and limitations

    Finally, because every plant and quality system is different, practical ISO 9001-focused QMS software should be:

    • Configurable in workflows, fields, roles, and forms without deep custom code where possible
    • Transparent about what is configuration versus customization, so you can assess validation and lifecycle impact
    • Capable of exporting your data in usable formats, to avoid lock-in and support audits and investigations

    No QMS software can guarantee ISO 9001 certification or audit results. It can only support your processes, evidence, and discipline. The actual outcome depends on process maturity, training, leadership follow-through, and the quality of integrations and data.

  • When should an aerospace nonconformance trigger a formal CAPA?

    A formal CAPA should be triggered when a nonconformance indicates a credible risk of systemic failure, safety or airworthiness impact, regulatory exposure, or recurring quality escapes. In aerospace, this decision must follow documented criteria in your quality system and be supported by objective evidence and risk assessment, not only by the severity of a single defect.

    Typical triggers for a formal CAPA in aerospace

    While specific thresholds belong in your internal procedures, aerospace organizations commonly require a CAPA when one or more of the following apply:

    • Safety or airworthiness impact is credible
      Nonconformances that could affect flight safety, structural integrity, or critical system performance, even if detected before shipment or installation. This includes issues on safety-critical characteristics, key characteristics, or special processes.
    • Regulatory or customer obligations are implicated
      Events that may require notification to aviation authorities or customers (e.g., potential reportable occurrence, significant escape, or field issue), or that are raised through regulatory or customer findings.
    • Evidence of systemic or process-level failure
      Nonconformances that indicate a breakdown of a controlled process, such as repeated similar defects, failures linked to the same operation, program, supplier, or design feature, or issues suggesting your FMEA/control plans are ineffective.
    • Repeat or clustered occurrences
      Same or similar nonconformances recurring within a defined period, lot, or configuration, even if each individual event is classified as minor. Clustering in time, product family, or workstation often indicates underlying systemic causes.
    • Formal findings from audits or inspections
      Major or repeated minor findings from internal audits, customer audits, or regulatory surveillance that point to ineffective controls, documentation, or previous corrective actions.
    • Supplier or sub-tier systemic issues
      Supplier nonconformances that show a pattern (e.g., multiple lots affected, multiple part numbers, repeated failures to meet agreed controls or special process requirements).
    • Field issues, escapes, or service disruptions
      Nonconformances discovered after delivery or installation, especially if they cause rework, AOG events, service disruption, or concessions that require engineering disposition across multiple units.
    • Failures of previous corrective actions
      Recurrence of a problem that was previously addressed by a corrective action, indicating that prior root cause analysis or fixes were incomplete or ineffective.
    • Risks to key business or program objectives
      Nonconformances that materially affect on-time delivery, cost, or contractual obligations (e.g., repeated scrapped high-value hardware, program-level delays tied to the same cause).

    When a nonconformance may stay at the local level

    Not every nonconformance should trigger a formal CAPA. In a mature system, many issues are addressed by contained corrective actions at the point of occurrence. In general, local correction and containment (without a full CAPA) can be appropriate when:

    • The event is clearly isolated and low risk to safety and airworthiness.
    • There is no pattern of recurrence in recent data for the same process, part, or supplier.
    • The cause is obvious, promptly eliminated, and effectively prevented through routine process control (e.g., work instruction clarification, minor fixture adjustment) without needing full root cause analysis.
    • It falls below defined thresholds in your risk and escalation matrix for cost, severity, detectability, or occurrence.

    Even in these cases, the nonconformance and decision not to open a CAPA should be recorded, traceable, and periodically reviewed so that patterns are not missed.

    Defining clear CAPA triggers in your QMS

    Because expectations differ by customer, regulator, and product line, the triggers for CAPA must be explicitly defined in your quality procedures, not handled ad hoc. Common good practices include:

    • Risk-based criteria
      Use a defined risk model (e.g., severity, occurrence, detection rankings) linked to decision rules, so CAPA decisions are consistent and auditable.
    • Data-driven thresholds
      Specify quantitative triggers such as a certain number of similar defects within a time frame, scrap/rework cost thresholds, or statistical signals from SPC or defect trend charts.
    • Category-based rules
      Define nonconformance categories that always require CAPA (e.g., critical characteristic escape, suspected counterfeit part, loss of special process control, unapproved repair on safety-critical hardware).
    • Explicit supplier escalation rules
      Clarify when supplier nonconformances escalate from SCAR or local actions into a formal CAPA within your own QMS.
    • Governance and review
      Have a cross-functional group (e.g., MRB, quality board, safety board) periodically review nonconformance data and confirm that triggers are being applied as intended.

    Brownfield and system coexistence considerations

    In most aerospace environments, nonconformance data, CAPA records, and risk assessments are distributed across multiple systems (MES, ERP, QMS, PLM, supplier portals) and sometimes paper. CAPA triggers will only work reliably if:

    • Nonconformances from all relevant sources are visible in one consolidated view or report.
    • Linkages between events, lots, part numbers, and processes are maintained so systemic issues can be detected.
    • Changes to triggers or escalation rules are managed under documented change control and, where applicable, validated before use.

    Attempts to replace legacy systems purely to improve CAPA triggering often run into qualification burden, downtime risk, and integration complexity. Many organizations instead overlay analytics and reporting on existing systems, and phase in changes under disciplined change control.

    Traceability and documentation expectations

    Regardless of whether a formal CAPA is opened, aerospace regulators and customers typically expect:

    • A clear record of the nonconformance, including classification and risk assessment.
    • Traceability from the event to the decision (why CAPA was or was not initiated).
    • Evidence of containment, disposition, and verification of any local corrective actions.
    • Periodic review of nonconformance data to confirm that CAPA triggers remain effective.

    Defining explicit, risk-based criteria and applying them consistently is usually scrutinized more closely than the absolute number of CAPAs opened.

  • What is an example of a non conformance?

    In a regulated manufacturing environment, a nonconformance is any verified departure from an approved requirement, specification, or procedure. It can relate to product, process, documentation, or data.

    Concrete examples of nonconformance

    • Dimensional out-of-tolerance part: A CNC-machined aerospace bracket is inspected and one critical hole diameter measures 10.12 mm against a drawing requirement of 10.00 mm ± 0.05 mm. The characteristic is clearly out of tolerance, so the part is nonconforming and must be segregated and dispositioned.
    • Wrong material used: A batch of medical device components is produced using stainless steel grade 304, but the approved bill of materials and material specification require 316L for corrosion resistance and biocompatibility. Even if the parts appear functional, they are nonconforming to the specification.
    • Unapproved process route: An operator skips a required in-process inspection step documented in the work instruction because the line is behind schedule. The product may pass later checks, but the process deviation itself is a nonconformance that must be recorded.
    • Using the wrong document revision: A technician builds an assembly using work instructions at Revision B, while the controlled document system shows Revision D as the current approved version. Any product built under the obsolete revision is nonconforming unless formally justified and accepted.
    • Environmental or equipment setpoint out of range: A validated oven used for cure cycles runs at 185 °C for a lot, while the validated and documented setpoint is 200 °C ± 5 °C. Even if later tests look acceptable, the cure process is nonconforming to the qualified parameters.
    • Labeling or traceability error: A pharmaceutical batch is labeled with an incorrect expiry date or missing lot number, breaking traceability requirements. The labeling defect is a nonconformance regardless of product quality.

    Why context and systems matter

    Whether an issue is treated as a nonconformance depends on how requirements are defined and controlled in your own systems: drawings, specifications, work instructions, MES routes, ERP master data, and QMS procedures. In brownfield plants with multiple legacy systems, misalignment between these sources is a common root cause of nonconformances.

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    Because equipment, software, and documentation are often validated and tightly controlled, even seemingly minor deviations (for example, using a not-yet-approved parameter change to reduce scrap) must be logged as nonconformances instead of treated as informal experiments. Replacement of systems just to “eliminate” nonconformances usually fails if requirements and change control are not cleaned up at the same time.

    In all cases, the key is traceability: you need to be able to show which requirements were violated, how the nonconformance was detected, what the disposition was (scrap, rework, use-as-is with justification, concession), and what corrective and preventive actions, if any, were taken.