Connect981 – Content Dev

RSC Content Type: FAQ

Direct answers to common technical or compliance questions.

  • What is the relationship between ISO 9001 and MRO quality requirements?

    ISO 9001 and MRO quality requirements are related but not interchangeable. ISO 9001 provides the generic quality management framework, while MRO quality requirements define the sector- and customer-specific rules that sit on top of that framework.

    What ISO 9001 provides

    ISO 9001 sets out high-level requirements for a quality management system (QMS) that are applicable to many industries, including MRO. At a practical level, it expects you to have:

    In practice, this connects to part genealogy and traceability when teams need to turn the answer into repeatable execution habits.

    • Documented and controlled processes for maintenance, inspection, and support activities.
    • Defined responsibilities and authorities for planning, performing, and releasing work.
    • Risk-based thinking for planning changes, outsourcing, and new work scopes.
    • Controls for nonconforming work, corrective actions, and prevention of recurrence.
    • Management review, internal audits, and evidence-based decision-making.

    For an MRO organization, this means ISO 9001 gives the structure to manage procedures, records, training, calibration, document control, and continual improvement across maintenance operations.

    What MRO quality requirements add

    MRO quality requirements are more specific and usually stricter than generic ISO 9001 expectations. They typically come from:

    • Sector standards such as AS9110 or other aerospace maintenance standards.
    • Regulatory bodies (for example aviation authorities or defense agencies).
    • OEM repair manuals, component maintenance manuals, and service bulletins.
    • Customer contracts, quality clauses, and delegated inspection arrangements.

    These MRO requirements cover topics that ISO 9001 only touches at a high level, such as:

    • Configuration control of serialized assets, including life-limited parts and modifications.
    • Mandatory work scope adherence to approved data and maintenance manuals.
    • Detailed repair traceability, including part lineage, removal/installation, and sign-off.
    • Release documentation, certificates of conformity, and maintenance releases.
    • Special process controls, NDT requirements, and technician certifications.
    • Record retention periods dictated by regulators or OEMs.

    ISO 9001 expects you to manage these topics via defined processes, but does not specify the technical content of the MRO rules themselves.

    How they work together in practice

    The practical relationship can be summarized as:

    • ISO 9001 = QMS framework: how you control documents, risk, training, audits, and NC/CAPA.
    • MRO requirements = domain content: what you must do to inspect, repair, and release an aircraft or asset correctly.

    In a brownfield environment with legacy ERP, paper travelers, and multiple point systems, ISO 9001 pushes you toward consistent, controlled processes, while MRO quality requirements determine the specific data, signatures, and approvals those processes must capture. The relationship is typically:

    • ISO 9001 clauses translated into maintenance procedures, job cards, and work instructions.
    • MRO-specific requirements embedded into routing steps, inspection points, and required fields.
    • Evidence (sign-offs, measurements, NCRs, repair dispositions) stored in MES/MRO systems, QMS, or hybrid paper/digital records.

    How effectively this works depends heavily on process maturity, integration quality, and whether systems (ERP, MRO, MES, QMS) are aligned and validated to support both ISO 9001 and sector-specific requirements.

    Limitations and common misconceptions

    Some important clarifications:

    • ISO 9001 does not guarantee MRO regulatory compliance. Certification to ISO 9001 does not by itself satisfy aviation or defense maintenance regulations, nor does it guarantee acceptable audit outcomes.
    • ISO 9001 does not define technical repair standards. It will not tell you which inspection method to use, how to apply a repair scheme, or how to configure an aircraft record; those come from OEM, regulatory, or customer requirements.
    • ISO 9001 is system-focused, not asset-specific. It evaluates how consistent and controlled your processes are, not whether a specific engine or component was maintained correctly in a technical sense.

    In many aerospace and defense contexts, ISO 9001 is treated as a baseline. Sector-specific standards and regulatory approvals (for example dedicated aerospace MRO standards and aviation authority approvals) add the extra layers needed for operational acceptance.

    Implications for systems and change in MRO environments

    For MRO organizations operating with legacy systems and constrained downtime, the relationship between ISO 9001 and MRO quality requirements has several implications:

    • System coexistence is normal. ISO 9001 controls can be implemented using a mix of QMS software, MRO or MES systems, ERP, and paper records. Full replacement of legacy systems purely to “be ISO 9001 compliant” is rarely justified, especially where regulatory approvals are tied to existing systems.
    • Change control and validation are critical. Any change to how maintenance data is captured (for example moving job cards from paper to a digital MRO system) usually triggers revalidation, updated procedures, and staff retraining to maintain both ISO 9001 conformity and regulatory acceptance.
    • Traceability requirements drive design. MRO traceability expectations (serial, batch, repair status, and life limits) often exceed the minimum ISO 9001 wording. Systems must be configured accordingly and tested so records remain complete and retrievable over long asset lifecycles.

    Because of the qualification burden, downtime risk, and integration complexity, many MRO providers phase in digital changes under their existing ISO 9001 QMS rather than attempting big-bang replacements of QMS, MRO, and ERP platforms.

    How to think about it when defining your MRO QMS

    When designing or improving an MRO QMS, a practical approach is:

    1. Use ISO 9001 as the backbone for governance, document control, competence, risk, and NC/CAPA.
    2. Map all applicable MRO regulatory, customer, and OEM requirements to that backbone, clarifying where they add more specific or stricter rules.
    3. Define which systems (MRO, MES, ERP, PLM, QMS) hold which records and signatures, and how interfaces preserve traceability and change history.
    4. Implement strong configuration and change management so that updates to manuals, customer contracts, or digital workflows are controlled and auditable.

    This keeps ISO 9001 in its proper role as the management framework, while the detailed MRO requirements define the content of what “good” maintenance, inspection, and release look like in your specific regulated environment.

  • How detailed do operational risk assessments need to be under AS9100 Rev D?

    AS9100 Rev D requires you to identify, assess, and control operational risks that could affect product conformity, on-time delivery, and customer satisfaction. It does not prescribe a single format or a fixed level of detail, but certification bodies will expect your risk assessments to be:

    • Proportionate to risk and complexity: Higher-risk processes (special processes, key characteristics, safety-critical parts, complex assemblies, software-driven operations) need more detailed analysis than low-risk, low-complexity tasks.
    • Structured and repeatable: You need a consistent method (e.g. FMEA-style, risk matrix, hazard list) with defined criteria for likelihood, severity, and priority, even if the template is simple.
    • Documented and traceable: It must be clear what was considered, what the risks are, how they were scored, and what controls or actions you chose. Auditors typically sample this to see that decisions are evidence-based, not ad hoc.
    • Integrated with operational controls: The output of risk assessments must connect to real controls in your QMS and operations: work instructions, inspection plans, special process controls, supplier requirements, training, maintenance, etc.
    • Maintained over time: Risks and controls must be reviewed and updated when you change processes, tooling, software, suppliers, or when nonconformances, escapes, or delivery issues reveal new risks.

    What “sufficient detail” usually looks like

    The level of detail is judged against your own context and the standard’s intent, not a page count. In practice, assessments are usually considered adequate when they:

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

    • Identify concrete failure modes or scenarios, not just generic labels (e.g. “incorrect heat treat cycle for landing gear components,” not just “process risk”).
    • Explicitly evaluate likelihood and consequence using your defined scale (qualitative or quantitative) so risk ranking is reproducible.
    • Link each high or medium risk to specific controls: process parameters, inspection points, digital traveler checks, interlocks, training, supplier controls, or monitoring plans.
    • Show residual risk after controls and explain why it is acceptable per your criteria.
    • Reference the affected processes and documents: routing steps, work instructions, control plans, software versions, or programs/part families.

    If an assessor cannot trace from a high-level risk (e.g. late delivery of critical parts) down to specific operational controls and records, the risk assessment is usually seen as too superficial.

    Minimum expectations under AS9100 Rev D

    For most aerospace manufacturers and MROs, operational risk assessments should at least cover:

    • Scope definition: Which product line, process family, or value stream is being assessed.
    • Risk identification: Key operational risks that can affect conformity and on-time delivery (process stability, capacity and bottlenecks, special processes, key characteristics, configuration control, software revisions, rework pathways, supplier failures, logistics, etc.).
    • Risk evaluation: A defined method to rate risks (e.g. 3×3 or 5×5 matrix) with documented criteria, not just intuition.
    • Risk treatment: Actions and controls proportionate to risk, assigned owners, and due dates where improvement is needed.
    • Link to QMS processes: How risks and actions link into production planning, configuration management, change control, NCR/CAPA, and management review.
    • Evidence of review: Dates, participants, and triggers for revisiting the assessment (e.g. after major changes or significant nonconformances).

    Very high-level lists like “risk: machine failure, mitigation: maintenance” with no prioritization, no traceability to specific assets, and no link to maintenance plans are usually inadequate for AS9100 Rev D expectations.

    Aligning depth of analysis with process risk

    AS9100 Rev D allows you to scale the level of detail to your context, but you need to be able to justify your choices. A common pattern is:

    • Tier 1 (high risk): Safety-critical parts, special processes, complex assemblies, or new technologies. Use detailed risk tools (e.g. FMEA-like analysis) with characteristic-level or step-level detail and explicit links to inspection and process controls.
    • Tier 2 (medium risk): Significant contributors to delivery or quality that are not directly safety-critical. Use a structured risk register or matrix with enough detail to drive actions and monitoring, but not necessarily down to every feature.
    • Tier 3 (low risk): Standard, low-complexity processes with stable history. A lighter-weight checklist or high-level risk review may be sufficient, provided performance data supports the reduced depth.

    Auditors usually look less at whether you used a specific method and more at whether your method is applied consistently, is scaled rationally to risk, and is linked to measurable outcomes (nonconformances, delivery performance, escapes, etc.).

    Brownfield and system coexistence considerations

    In most regulated aerospace environments, risk assessments have to coexist with legacy MES, ERP, PLM, and QMS systems. Typical constraints and tradeoffs include:

    • Distributed data: Risk controls often live across multiple systems (QMS, MES, ERP, maintenance, training). Overly granular risk models that cannot be traced into those systems become difficult to maintain and defend.
    • Change control burden: Very detailed risk assessments that reference specific work instruction steps, machine IDs, or software versions can create heavy change-control workload whenever something shifts. Depth must be balanced against your ability to keep it current under formal change management.
    • Long equipment lifecycles: You will often have to assess risk across new and very old assets, with variable data quality. Expect to rely less on theoretical scoring and more on actual performance data and NCR/CAPA history for older equipment.
    • Integration limitations: Trying to fully replace legacy risk-related modules (e.g. in an existing QMS) can introduce significant validation and downtime risk. Many organizations instead layer a structured risk assessment process on top of existing tools and link via document references and shared IDs rather than deep technical integration at first.

    In this context, risk assessments that are too detailed can be as problematic as those that are too shallow. The key is to choose a level of detail you can maintain reliably within your existing change control, validation, and IT constraints.

    Evidence auditors typically look for

    To assess whether your operational risk assessments are detailed enough, auditors will usually:

    • Sample a high-risk value stream and ask to see the corresponding risk assessment.
    • Trace a few top risks to actual controls in routings, work instructions, inspection plans, and training.
    • Check that recent significant nonconformances, escapes, or chronic delivery issues are reflected in updated risk assessments and actions.
    • Verify that risk-based thinking appears in management review, planning, and change control decisions.

    If you can clearly show how your assessments informed concrete controls and improvements, and you can justify why the level of detail matches the risk, you are typically operating at the right level of detail for AS9100 Rev D expectations.

  • What are the 4 main components of a QMS?

    There is no single universally accepted list of exactly four components of a Quality Management System (QMS). Different standards and vendors slice the system differently. In regulated industrial environments, a practical way many organizations describe the QMS is in four interacting components:

    1. Quality planning

    Quality planning defines what “good” means and how it will be achieved and measured. It typically includes:

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

    • Quality policy and objectives aligned to business and regulatory requirements
    • Quality plans at product, process, and site level (including control strategies)
    • Risk assessment and mitigation approaches (e.g., FMEA integration)
    • Defined metrics and acceptance criteria (e.g., CTQs, defect rates, COPQ targets)
    • Planning how quality will be managed across the lifecycle: design, industrialization, production, service, and change

    In brownfield environments, quality planning must account for existing constraints: legacy equipment capability, current MES/ERP/QMS data structures, and realistic change control timelines. A plan that assumes a clean-slate system usually fails when it hits validation and downtime limits.

    2. Quality control

    Quality control focuses on detecting and containing defects during operations. It covers:

    • Incoming, in-process, and final inspection and test
    • Sampling plans, measurement methods, and gauge management
    • SPC, alarms, and reaction plans on the shop floor
    • Nonconformance identification, segregation, and disposition workflows
    • Use of digital work instructions and checklists to execute and record checks

    Effectiveness here depends heavily on integration and data quality: how well inspection plans are linked to BOMs, routings, and work orders in existing MES/ERP, and whether measurement data is reliable, time-aligned, and traceable to specific lots, serials, and operators.

    3. Quality assurance

    Quality assurance provides confidence that processes, systems, and controls are capable and consistently applied. This usually includes:

    • Document control and version governance for SOPs, work instructions, and forms
    • Training, qualification, and competency management for personnel
    • Internal audits and self-inspections
    • Supplier quality assurance, including approvals and monitoring
    • Configuration management, change control, and validation of computerized systems

    In regulated, long-lifecycle environments, assurance activities must coexist with long-lived assets and software. Replacing core systems (MES, QMS, PLM) just to “simplify” assurance often backfires due to qualification burden, revalidation cost, and the need to recertify interfaces and reports used as audit evidence.

    4. Quality improvement

    Quality improvement drives reduction of defects, waste, and risk over time. Typical elements are:

    • Corrective and preventive action (CAPA) processes with documented root cause analysis
    • Continuous improvement programs (e.g., Lean, Six Sigma, Kaizen)
    • Trend analysis of nonconformances, complaints, and process performance
    • Cross-functional problem solving and lessons-learned capture
    • Structured prioritization of improvements based on risk and impact

    Improvement depends on having accessible, trustworthy, and traceable data from existing systems, and on disciplined change control. In aerospace and similar environments, even beneficial improvements can be slowed by qualification and certification requirements, so organizations often favor incremental changes that can be validated and rolled out with minimal disruption.

    Key constraints and tradeoffs

    • No automatic compliance: Having these four components defined does not guarantee compliance or audit outcomes. Effectiveness depends on execution, evidence quality, and how the QMS is embedded in day-to-day operations.
    • Brownfield reality: Each component usually spans multiple tools: legacy QMS, MES, ERP, PLM, LIMS, and homegrown systems. Trying to re-platform everything at once to “unify the QMS” typically runs into downtime limits, validation burden, and integration complexity.
    • Traceability and validation: For regulated plants, the QMS must support traceable decisions and reproducible records. Any change to workflows or systems that support these four components usually requires risk assessment, documented testing, and controlled rollout.

    In practice, many organizations use this four-component view as a communication and design tool, then decompose each component into more detailed processes aligned with their specific standards, product risks, and existing system landscape.

  • What are the 7 principles of ISO 9001?

    ISO 9001 is based on seven Quality Management Principles (QMPs). They are not requirements themselves, but they underpin how the standard is structured and how a quality management system (QMS) is expected to operate, especially in regulated manufacturing environments.

    1. Customer focus

    The organization should understand current and future customer needs, meet applicable requirements, and aim to enhance customer satisfaction. In industrial and regulated contexts this typically includes not only direct customers but also regulatory and certification stakeholders. How well this works in practice depends on clear requirements flowdown into specifications, drawings, work instructions, and ERP/MES/QMS data.

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

    2. Leadership

    Top management should establish a unified direction and create conditions where people are engaged in achieving quality objectives. In long-lifecycle plants, this usually shows up as consistent priorities across production, quality, engineering, and IT, with management backing for traceability, validation, and robust change control instead of short-term throughput only.

    3. Engagement of people

    People at all levels are considered essential to the organization, and their competent, empowered participation is needed for value creation. On a shop floor with mixed legacy systems, this often means practical training on procedures and systems, clear role definitions, and giving operators and technicians safe channels to flag nonconformities without fear of blame.

    4. Process approach

    Activities and resources should be managed as interrelated processes that function as a coherent system. For manufacturing, this means viewing product realization as an end-to-end process chain that spans design, planning, production, inspection, logistics, and service, not isolated departments. In brownfield environments, achieving a true process approach usually requires incremental integration across MES, ERP, PLM, and QMS rather than a full system replacement.

    5. Improvement

    The organization should maintain an ongoing focus on improvement. In regulated environments, this typically means structured corrective and preventive action (CAPA), data-driven problem solving, and controlled changes to processes and documentation. The effectiveness of this principle depends on the quality and accessibility of data, as well as realistic change control that does not encourage workarounds.

    6. Evidence-based decision making

    Decisions should be based on analysis and evaluation of data and information. In practice, this hinges on data integrity, traceability, and the ability to correlate information across systems such as QMS, MES, ERP, and LIMS. Plants with fragmented or manual records can still follow this principle, but analysis will be slower and more error-prone until integrations and data governance are improved.

    7. Relationship management

    The organization should manage relationships with interested parties such as customers, suppliers, partners, and regulatory bodies to sustain success. For industrial operations, this includes clear technical and quality agreements, supplier performance monitoring, and controlled communication of changes. Long equipment lifecycles often mean you will work with the same key suppliers and service providers for decades, so structured relationship management and documented interfaces become critical.

    These seven principles are stable across industries, but how they are realized in a specific plant depends heavily on existing systems, process maturity, integration quality, and the regulatory framework. ISO 9001 itself does not guarantee compliance outcomes; it provides a framework that must be implemented, maintained, and continually improved within those constraints.

  • What are early warning signs that an organization is not ready for AS9100?

    Early warning signs that an organization is not ready for AS9100 usually show up long before anyone calls a registrar. They tend to fall into six areas: culture and leadership, process discipline, documentation and records, nonconformance and risk management, data and systems, and change control.

    1. AS9100 is treated as a “badge,” not a way of working

    Clear warning signs:

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

    • Talk about “getting the certificate fast” with little discussion of sustaining the system over the equipment lifecycle.
    • No executive sponsor who understands what AS9100 will require from operations, engineering, and IT.
    • Management delegates everything to a single “quality person” with no cross-functional ownership.
    • Quality is treated as a department deliverable instead of an operations responsibility.

    Consequence: you may be able to write a manual and pass one audit, but surveillance audits, customer audits, and real operational issues will quickly expose gaps.

    2. Processes exist only as tribal knowledge or outdated documents

    AS9100 expects defined, repeatable, and controlled processes. Warning signs:

    • Operators “know how we really build it,” but work instructions, routers, or travelers are frequently ignored or outdated.
    • Multiple versions of the “same” work instruction exist in email, shared drives, and paper binders, with no clear master.
    • New employees learn almost entirely by shadowing, with minimal documented standard work or training records.
    • Engineering changes are communicated informally (verbal, chat, text) and take weeks or months to show up in controlled documents or routings.

    Consequence: auditors will quickly find inconsistencies between procedures, actual practice, and records. More importantly, product risk increases whenever key people are absent.

    3. Document control and records management are weak

    In regulated aerospace environments, poor document and record control is one of the strongest indicators of AS9100 unpreparedness.

    • There is no clear method to identify the current revision of procedures, work instructions, drawings, or specifications at the point of use.
    • Legacy paper and PDF systems coexist informally with MES/ERP/QMS, without a defined master source of truth.
    • Retention, retrieval, and backup rules for records (inspection results, certificates of conformity, travelers, FAI packages) are undefined or inconsistently applied.
    • Audit trails are incomplete; you cannot reliably say who changed what, when, and why.

    Consequence: even if product quality is acceptable, the inability to prove control and traceability will create major audit findings and customer concern.

    4. Nonconformance and CAPA are ad hoc and reactive

    AS9100 assumes you already have a functioning system to identify, control, and correct problems. Warning signs:

    • Scrap, rework, or concessions are tracked only in spreadsheets or not at all, and the numbers do not match finance or production data.
    • MRB decisions are not consistently documented; rationales and risk assessments are often missing or informal.
    • Repeated issues are handled with quick fixes (more inspection, retraining) instead of documented root cause analysis and corrective actions.
    • CAPA exists as a form, but there is no systematic follow-up to verify effectiveness.

    Consequence: an auditor will see repeated issues with weak or recycled corrective actions and will question your ability to sustain conformity as you scale or change product mix.

    5. Traceability and configuration control are fragile

    Many aerospace plants operate in brownfield environments with mixed systems and partial digitization. Early warning signs that traceability is not ready for AS9100 expectations:

    • Genealogy (which lot, which serial, which supplier) is reconstructable only by a few experts using a mix of ERP, spreadsheets, and paper search.
    • There is no reliable method to link work orders to purchase orders, test data, and as-built configurations across multiple systems.
    • Configuration baselines for complex assemblies are unclear; different departments use different BOMs or revision levels.
    • Rework, repair, and deviations are not consistently pushed back into configuration records and travelers.

    Consequence: any field issue, escape, or customer complaint will be difficult to contain and investigate, and your ability to perform effective recall or impact analysis will be questioned.

    6. Internal audits are superficial or non-existent

    Internal process audits are central to AS9100. Warning signs:

    • No established internal audit program, or it exists only as a checkbox activity driven by a template.
    • Auditors are untrained, or they are the same people who own the processes they are “auditing.”
    • Findings focus on documentation format rather than whether processes are effective and followed.
    • Corrective actions from internal audits are weak or remain open for long periods without escalation.

    Consequence: if your internal audits do not surface real issues, the first certification or customer audit will, often at greater cost and with more disruption.

    7. Change control and validation are not scaled for aerospace

    AS9100 expects disciplined change management that respects product risk and long equipment lifecycles. Warning signs:

    • System changes (ERP, MES, QMS, PLM) are made without documented impact assessment on quality records, traceability, and data integrity.
    • No clear process to validate software changes that affect production records or compliance-critical data.
    • Process changes are implemented on-the-fly by supervisors or programmers without formal review, risk assessment, or customer notification where required.
    • Legacy equipment and software are modified without configuration records or rollback plans.

    Consequence: in a regulated aerospace context, this undermines confidence in your data, genealogy, and evidence trail, and it can create major nonconformities in an AS9100 audit.

    8. Data and systems cannot reliably support evidence needs

    Brownfield plants often struggle here. Warning signs that your systems will not support AS9100 evidence requirements:

    • Key data is scattered across ERP, MES, spreadsheets, shared drives, and email with no clear ownership or integration strategy.
    • Basic questions (scrap by part, complaints by customer, process capability by feature) require manual data pulls and reconciliation.
    • Electronic records and signatures (if used) are not governed by clear access control, audit trail, and backup practices.
    • Attempts to “fix everything” by replacing core systems all at once have stalled due to downtime risk, integration complexity, or validation burden.

    Consequence: even if you write compliant procedures, you may not be able to produce timely, reliable evidence of conformity or effective control during audits or customer investigations.

    9. Resource constraints and competing priorities are ignored

    Early signs that the AS9100 initiative will stall:

    • No dedicated time or resources for process owners to help design and document the system; they are expected to do it “on the side.”
    • Significant open issues on capacity, late orders, or major ERP/MES projects with no realistic integration plan into the AS9100 timeline.
    • No plan to train operators, engineers, and supervisors on their practical roles in the quality management system.
    • Supplier quality and purchasing are not involved, even though external providers are a major AS9100 focus.

    Consequence: documentation may be created, but it will not reflect how work is actually done, and adoption on the shop floor will be poor.

    10. How to use these warning signs constructively

    Seeing several of these signs does not mean AS9100 is impossible. It means the sequence and scope need to be realistic:

    • Stabilize key operational processes and basic quality controls before pursuing certification timelines.
    • Start with a focused gap assessment against AS9100 that includes operations, engineering, IT, and supply chain, not just quality.
    • Prioritize issues that affect traceability, document control, nonconformance management, and change control ahead of cosmetic fixes.
    • Be cautious about large-scale system replacements as the primary path to compliance; in long-lifecycle aerospace environments, these efforts often fail under validation, integration, and downtime constraints.

    Used early, these warning signs can help leadership decide when to slow down, sequence work, or invest in foundational capabilities before committing to an AS9100 certification date.

  • What does non-conformance mean?

    In regulated manufacturing environments, a non-conformance is a documented instance where a product, material, component, process, or record does not meet an approved requirement. The requirement may come from a specification, drawing, work instruction, validated procedure, standard, or customer/contract requirement.

    What a non-conformance is

    A non-conformance typically means all of the following are true:

    • A clear requirement exists (for example, tolerance limits, process parameters, cleanliness criteria, document format, or timing).
    • Objective evidence shows the actual condition or result does not meet that requirement.
    • The gap has been recorded in an approved system (for example, QMS, MES, CAPA or deviation module) according to local procedures.

    Non-conformance is a status of non-fulfillment, not an explanation of why it occurred or what will be done to fix it.

    What a non-conformance is not

    • Not the root cause: The non-conformance describes what is wrong (for example, diameter out of tolerance). Root cause analysis is a separate activity.
    • Not automatically a defect recall or compliance failure: Many non-conformances can be reworked, repaired, or accepted under deviation depending on risk, requirements, and approvals.
    • Not the same as a CAPA: Corrective and preventive actions may be triggered by significant or repeated non-conformances, but the CAPA record is distinct from the initial non-conformance record.

    Types of non-conformance you will see

    Terminology varies by company and regulator, but common categories include:

    • Product non-conformance: Physical product does not meet specification (for example, dimension out of tolerance, surface finish, missing feature, contamination).
    • Process non-conformance: A step was not performed as required (for example, skipped inspection, uncalibrated gage, wrong torque sequence, unapproved software version).
    • Documentation or data non-conformance: Records are incomplete, incorrect, missing, or not created under the approved procedure (for example, missing signatures, wrong revision of work instruction used, incorrect lot traceability linkage).
    • Supplier non-conformance: Incoming material or documentation from a supplier does not meet purchase order or specification requirements.

    How non-conformances are typically handled

    In mature operations and quality systems, a non-conformance usually triggers a defined workflow:

    1. Detection and recording: The issue is identified (for example, by operator, inspector, automated check, or system rule) and logged in the designated system with traceable details.
    2. Containment: Affected parts, lots, or records are identified and controlled to prevent unintended use or shipment.
    3. Evaluation: Technical and quality review determines severity, risk, regulatory or customer impact, and whether product can be reworked, repaired, used-as-is under concession, or must be scrapped.
    4. Disposition: An approved disposition (for example, rework, repair, scrap, use-as-is with deviation) is documented and executed under change control.
    5. Escalation to CAPA (when warranted): Significant, systemic, or repeat non-conformances may feed into a CAPA process for deeper root cause analysis and longer-term corrective or preventive actions.

    System and integration considerations

    In brownfield plants with mixed MES, ERP, PLM, and QMS systems, the exact meaning and handling of non-conformance is often shaped by integration boundaries and validation constraints:

    • Some plants record non-conformances primarily in the QMS, with limited visibility in MES or ERP, which can create gaps in traceability and containment.
    • Others use MES for in-process non-conformance and QMS for formal investigation and CAPA, requiring reliable data integration and clear ownership between systems.
    • Legacy systems and long-qualified equipment may restrict changes to how non-conformances are captured or categorized without revalidation and change control.

    Because of these realities, the operational impact of a non-conformance depends not only on the technical issue but also on how well your systems, procedures, and roles are aligned around detection, documentation, and resolution.

  • How detailed must an AS9100-compliant corrective action record be?

    AS9100 does not specify a page count, template, or software for corrective action records. Instead, it requires that your records provide objective evidence that you followed your documented corrective action process and met the standard’s requirements. In practice, a compliant record must contain enough detail that a technically competent third party can reconstruct what happened, why it happened, what you changed, and how you know the issue is controlled.

    Minimum elements AS9100 expects to see in a corrective action record

    At a minimum, an AS9100-compliant corrective action record should clearly document:

    • Problem statement: A concrete description of the nonconformity, including what failed, where, when, and how it was detected. Reference relevant part numbers, processes, documents, lots, and dates.
    • Containment / immediate actions: Actions taken to protect the customer and prevent further nonconforming output (e.g., segregation, holds, rework, recalls, additional inspection).
    • Evidence of evaluation of impact: How you assessed risk and impact on delivered product, safety, regulatory requirements, and customers. Include decisions on fielded product review or notification, where applicable.
    • Root cause analysis: The method used (for example 5 Whys, fishbone, fault tree) and the actual reasoning path that led to the identified root cause(s). This must go beyond “operator error” or “training issue” unless those are supported by analysis.
    • Identified root cause(s): Clear statement of the underlying cause(s) for the nonconformity and, where required by your procedure, contributing and systemic causes (e.g., process, design, documentation, or management system weaknesses).
    • Corrective actions: Specific, actionable changes implemented to remove the root cause(s). Include what changed (process, method, tooling, software, documentation, training, supplier controls, etc.), how, and when.
    • Verification / validation of corrective action effectiveness: Description of how you confirmed the action works over time (e.g., trend monitoring, capability data, audit results, sampling plans) and the criteria for success or closure.
    • Responsibilities and approvals: Who performed the investigation, who approved the actions, and who approved closure, aligned with your documented authority and responsibilities.
    • Dates and traceability: Dates for each major step (initiation, containment, analysis, implementation, effectiveness check, closure) and links to related records (nonconformance reports, customer complaints, concessions, deviations, change requests, risk assessments).

    Without these elements, you will struggle to demonstrate conformity to AS9100 requirements on nonconformity and corrective action, and you increase the risk of repeat findings or customer escalations.

    How much detail is “enough”?

    The required level of detail is risk-based. AS9100 expects you to scale the depth of analysis and documentation with the potential impact on safety, regulatory requirements, and customer performance.

    • Low-risk / low-impact issues (e.g., easily detected cosmetic nonconformities, internal housekeeping issues): Shorter records may be acceptable if the risk evaluation is explicit and the root cause and actions are still clearly stated.
    • Moderate to high-risk issues (e.g., product performance, safety, airworthiness, critical process deviations, repeated escapes): Expect to provide detailed problem definition, thorough root cause analysis, documented consideration of systemic impacts, and more robust effectiveness verification.
    • Customer-mandated or regulatory-driven CAPAs: Often require greater detail than your internal minimums, including supporting data, trend analysis, and alignment with customer-specific forms or portals.

    A practical test is: could a qualified auditor or customer engineer, with only this record and linked evidence, understand what actually happened, why it happened, what changed in the system, and whether the risk of recurrence is genuinely controlled? If not, the record is probably too thin.

    Common failure modes in corrective action records

    Even when forms look complete, records often fail AS9100 expectations in these ways:

    • Vague or incomplete problem statements: Descriptions like “part out of tolerance” without specifying which feature, by how much, under what conditions, and with what impact.
    • Superficial root cause: Stopping at “operator error” or “did not follow procedure” without asking why the error was possible, frequent, or undetected (e.g., poor ergonomics, unclear work instructions, unrealistic takt times, inadequate mistake-proofing).
    • Actions that do not address the root cause: Corrective actions limited to retraining, memos, or reminders, with no change in the process, controls, or system that allowed the failure.
    • No real effectiveness check: Closure with only a statement such as “no further issues observed” and no defined monitoring period, metrics, or data supporting that claim.
    • Missing linkage to risk and configuration controls: No update to risk assessments, FMEAs, control plans, work instructions, drawings, or software configuration where those were part of the failure path.
    • Poor traceability across systems: CAPA record refers to nonconformances, deviations, or change records that are not consistently referenced in MES, ERP, PLM, or QMS systems, making end-to-end traceability difficult to demonstrate.

    Coexistence with legacy QMS, MES, ERP, and PLM systems

    In brownfield environments, corrective action records are often spread across multiple systems: QMS for the CAPA, MES for nonconforming product tags, ERP for returns and credits, and PLM or document control for drawing and specification changes. AS9100 does not require you to replace these systems, but it expects:

    • Consistent identifiers (e.g., CAPA number, NCR number, deviation/waiver number) used across systems so an auditor can follow the chain.
    • Configuration and change control so that any design, process, or software changes made as part of the corrective action are properly reviewed, approved, released, and version-controlled.
    • Validated and controlled tools where your procedures claim reliance on them (for example, electronic signatures, workflow enforcement).
    • Accessible evidence within downtime and IT constraints, so you can retrieve data, logs, and related records during audits and investigations.

    Attempting a full system replacement just to “clean up” CAPA records often fails in aerospace-grade environments due to qualification and validation burden, integration complexity with existing traceability, and downtime risk to production. Enhancing the discipline and completeness of records within the current toolset, while gradually improving interfaces and traceability, is typically more achievable.

    Practical guidelines for defining your internal level of detail

    To operationalize AS9100 expectations, organizations typically:

    • Define a standard CAPA template (paper or electronic) that explicitly prompts for the elements listed above and references your nonconformity and corrective action procedures.
    • Use a risk-based tiering for investigations, where higher-risk issues require more data, formal tools (like fishbone diagrams or 5 Whys), and more rigorous verification plans.
    • Specify minimum evidence types for each CAPA stage (e.g., photos, inspection reports, process data, meeting minutes, training records, updated work instructions).
    • Define what “acceptable root cause” looks like in work instructions or training, with examples of insufficient vs sufficient analysis.
    • Embed cross-functional review (quality, engineering, operations, sometimes supply chain and IT) for medium- and high-risk CAPAs to make sure systemic issues are captured.
    • Periodically audit closed CAPAs to check whether the documented level of detail matches internal expectations and AS9100 requirements.

    The goal is not maximum text, but sufficient clarity, traceability, and objective evidence to withstand internal, customer, and certification body scrutiny.

    Key takeaway

    An AS9100-compliant corrective action record must be as detailed as necessary to:

    • Show a clear, factual description of the nonconformity and its impact.
    • Demonstrate a logical, documented root cause analysis.
    • Link specific corrective actions to the identified causes.
    • Provide evidence that those actions are implemented, controlled, and effective over time.
    • Maintain traceability across the existing QMS, MES, ERP, and PLM ecosystem.

    Where your current records do not achieve this level of clarity and traceability, increasing the detail and structure of the records is necessary to align with AS9100 expectations, even if the standard does not dictate an exact format.

  • How does IEC 62443-4-1 differ from generic secure SDLC practices?

    IEC 62443-4-1 is a formal, auditable secure development lifecycle standard for industrial automation and control systems (IACS). Generic secure SDLC practices are usually guidance or internal policies. The main differences are in scope, prescriptiveness, evidence expectations, and how they align with regulated OT environments.

    1. Scope and intent

    Generic secure SDLC:

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    • Usually a mix of industry good practices (e.g., threat modeling, secure coding, code review, security testing).
    • Often oriented toward IT/web/software products and typical enterprise risk models.
    • Driven by internal policy, OWASP, NIST SSDF, or vendor-specific frameworks.

    IEC 62443-4-1:

    • Part of the IEC 62443 series, focused specifically on IACS product security development.
    • Defines required processes and work products for developing and maintaining secure IACS components and systems.
    • Intended to support independent assessment and supplier/customer assurance in OT and regulated industrial contexts.

    2. Prescriptiveness and auditable requirements

    Generic secure SDLC:

    • Typically principle-based: “do threat modeling,” “perform security testing,” “train developers.”
    • Level of rigor, documentation, and traceability is highly variable across organizations.
    • Not usually written to support formal conformity assessment of a supplier.

    IEC 62443-4-1:

    • Defines concrete process requirements grouped into practices such as:
      • Security management
      • Specification of security requirements
      • Secure by design
      • Secure implementation
      • Security verification and validation testing
      • Management of security-related issues
      • Security update management
      • Security guidelines and documentation
    • Each practice has specific objectives and expected work products that can be examined during an assessment.
    • Designed to be used by certifying bodies or customers to judge whether a supplier follows a defined secure development process.

    3. OT-specific context and constraints

    Generic secure SDLC:

    • Generally assumes IT-style environments with comparatively frequent update cycles, shorter asset lifetimes, and easier patch deployment.
    • Rarely addresses safety interlocks, hard real-time constraints, or interaction with physical processes in detail.

    IEC 62443-4-1:

    • Assumes long-lived industrial assets, constrained downtime, and co-existence with legacy PLCs, DCS, SCADA, and field devices.
    • Emphasizes secure development in environments where safety, process continuity, and regulatory validation are critical.
    • Places more weight on backwards compatibility, controlled change, and predictable update mechanisms suitable for OT and regulated plants.

    4. Traceability, documentation, and evidence

    Generic secure SDLC:

    • Documentation depth is highly variable and often optimized for speed-to-market rather than external scrutiny.
    • Traceability from security requirements through design, implementation, test, and release may be partial or informal.

    IEC 62443-4-1:

    • Requires clear traceability from security requirements to implementation and test results.
    • Expects defined work products, such as security requirement specifications, threat/risk analyses, test plans and reports, and vulnerability handling records.
    • Aims to make the secure development process transparent enough for customer due diligence, qualification, and audits in regulated sectors.

    In practice, this means adopting IEC 62443-4-1 often requires tightening configuration management, change control, and evidence capture around the SDLC, not just adding more testing.

    5. Lifecycle and update obligations

    Generic secure SDLC:

    • Usually focuses on development up to initial release and routine patches.
    • End-of-life, long-term support, and customer notification processes may be ad hoc or commercial decisions rather than process requirements.

    IEC 62443-4-1:

    • Includes explicit practices for managing security issues and security updates over the product lifecycle.
    • Addresses vulnerability handling, coordinated disclosure, patch creation, and guidance to asset owners on deployment constraints.
    • Recognizes that plants cannot simply “auto-update” control system components without risk analysis, validation, and planned downtime.

    For regulated environments, this lifecycle orientation aligns better with qualification, revalidation, and change control processes that extend for many years after initial commissioning.

    6. Fit with brownfield and mixed-vendor environments

    Generic secure SDLC:

    • Often developed with greenfield or single-vendor software stacks in mind.
    • Does not inherently address how products will be integrated into legacy OT networks and multi-vendor control architectures.

    IEC 62443-4-1:

    • Aims to make component security characteristics and assumptions explicit so integrators and asset owners can factor them into a defense-in-depth architecture.
    • Supports coexistence: the intention is not to force wholesale replacement of existing systems, but to raise the baseline security of new or updated components in a realistic OT ecosystem.
    • Still depends heavily on how well integrators and asset owners apply other 62443 parts; 4-1 alone does not guarantee secure system behavior.

    7. Relationship to your existing secure SDLC

    IEC 62443-4-1 does not replace generic secure SDLC practices; it constrains and structures them. A mature product team will typically:

    • Map existing secure SDLC activities to 4-1 requirements to identify gaps.
    • Strengthen documentation, traceability, and evidence around activities they already perform.
    • Introduce missing OT-relevant elements such as formal security update processes, clear security guidance for operators, and more rigorous treatment of long-term support.

    Whether 4-1 is a good fit for you depends on your role:

    • Component/system suppliers: 4-1 can provide a recognized framework for demonstrating structured secure development to industrial and regulated customers. Achieving conformity usually requires organizational commitment, not just technical changes.
    • Asset owners/integrators: 4-1 is mainly a supplier-side standard. You can use it as a selection and due diligence criterion but still need your own ICS security program, change control, and validation processes.

    In all cases, the benefits depend on how rigorously processes are implemented, integrated into existing quality and development workflows, and supported by management. The standard does not guarantee specific audit outcomes or regulatory compliance by itself.