Connect981 – Content Dev

RSC Cluster: Audit and Compliance Readiness (AS9100, LPAs and Process Audits)

The Audit and Compliance Readiness Cluster focuses on turning audit preparation into continuous evidence rather than episodic panic. It explains what auditors actually expect to see across training, revision control, traceability, and execution records. The content covers internal audits, layered process audits, and AS9100 expectations using real operational examples. This cluster helps organizations stay audit-ready by design, not by scramble.

  • Boundaries and Applicability

    Boundaries and Applicability commonly refers to the explicit definition of what a system, process, requirement, or assessment covers, where it applies, and what is out of scope. In industrial and regulated manufacturing environments, it is used to avoid ambiguity about responsibilities, system coverage, and regulatory obligations.

    Core meaning

    When organizations describe boundaries and applicability, they are usually addressing two related questions:

    • Boundaries: The scope limits of something, such as a production process, OT/IT system, quality procedure, or risk assessment. This often includes which sites, lines, products, data flows, or functions are included or excluded.
    • Applicability: The situations, conditions, or entities to which a requirement, standard, control, or procedure applies. This may reference product families, process steps, regulatory classifications, or system configurations.

    Together, boundaries and applicability clarify the domain in which certain rules, controls, or behaviors are expected, and where they are not.

    Operational context in manufacturing

    In industrial and regulated settings, boundaries and applicability are typically documented in:

    • Quality and compliance procedures: Defining which plants, product ranges, or process variants a SOP covers, and which are explicitly excluded.
    • MES/ERP and OT/IT system descriptions: Stating which production areas, equipment, data types, and interfaces are within the scope of a system implementation or change, and which remain out of scope.
    • Risk, safety, and cybersecurity assessments: Describing the physical and logical boundaries of the system or process being analyzed, and the assets, networks, and users to which controls apply.
    • Regulatory and standards alignment: Explaining when specific regulatory requirements or industry standards apply to a product, process, or site based on criteria such as market, classification, or customer requirements.

    Clear boundaries and applicability help avoid overlap or gaps between systems and procedures, reduce conflicting instructions, and support consistent application of controls and records across sites and lines.

    What it typically includes

    Well defined boundaries and applicability statements often specify:

    • Physical scope: Sites, buildings, areas, production lines, equipment, or utilities.
    • Organizational scope: Departments, roles, or functions responsible or affected.
    • Process and product scope: Process steps, product families, variants, or batches covered.
    • System and data scope: Applications, interfaces, data types, and environments (e.g., test vs production).
    • Temporal scope: When the definition applies, such as effective dates or lifecycle phases.
    • Explicit exclusions: Items or situations that are intentionally left outside the scope.

    Common confusion

    • Scope vs. boundaries and applicability: “Scope” is often used as a single word for what is covered. “Boundaries and applicability” is a more explicit way to describe scope limits (boundaries) and the conditions or entities to which something applies (applicability).
    • Requirements vs. applicability: A requirement describes what must be done; applicability describes when, where, or to whom that requirement is relevant.

    Use in documentation and audits

    In procedures, system descriptions, validation packages, and risk assessments, a dedicated section on boundaries and applicability is often used to:

    • Clarify which operations and systems are covered by the document or activity.
    • Support consistent interpretation during internal reviews and external audits.
    • Provide a reference when evaluating change impact, nonconformances, or deviations.

    This term is descriptive and does not imply any specific standard or regulatory framework, but it is commonly used in quality systems, safety management, and OT/IT governance documentation.

  • How can predictive insights change our inspection and audit plans?

    Predictive insights can change inspection and audit plans by helping you prioritize where to look first, how often to inspect, and which signals justify deeper review. In practice, that usually means shifting from mostly calendar-based or uniform sampling toward a more risk-informed approach.

    What they generally do well is identify patterns such as recurring defects by machine, operator, tool, material lot, supplier, route step, shift, or environmental condition. That can support tighter incoming inspection on specific suppliers, more frequent in-process checks on unstable operations, or targeted internal audits in areas showing documentation drift, repeated deviations, or rising rework.

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

    What they generally should not do is eliminate required inspections, mandatory records, or scheduled audits simply because a model says the risk is low. In regulated operations, those obligations often come from internal procedures, customer requirements, validation commitments, or quality system rules that analytics alone do not override.

    Where predictive insights are most useful

    • Reprioritizing inspection effort toward high-risk parts, characteristics, or process steps.

    • Adjusting audit focus toward locations or workflows with recurring nonconformance, weak closure discipline, or evidence gaps.

    • Flagging combinations of conditions that correlate with escapes, scrap, rework, or delayed CAPA effectiveness.

    • Identifying when a stable process may justify review of sampling strategy, subject to quality approval and documented change control.

    Limits and dependencies

    The usefulness of predictive insights depends heavily on data readiness. If your NCR, CAPA, MES, ERP, maintenance, calibration, training, and supplier data are inconsistent, delayed, or weakly linked, the output may be directionally interesting but not strong enough to drive plan changes.

    False positives and false negatives matter. A model that over-flags risk can waste inspection capacity and create audit churn. A model that misses emerging issues can create unjustified confidence. That is why predictive outputs are usually better treated as decision support, not autonomous control.

    You also need traceability for why plans changed. If inspection frequency, sampling, or audit emphasis is adjusted, the rationale should be documented, reviewable, and subject to change control. In many plants, that means linking the recommendation to risk review, quality approval, and revision-controlled procedures.

    Brownfield reality

    Most sites will not replace their QMS, MES, ERP, or audit management stack just to enable predictive planning, and they usually should not. Full replacement often fails in long lifecycle regulated environments because qualification burden, validation cost, downtime risk, integration complexity, and legacy asset constraints are too high.

    A more realistic approach is to layer analytics on top of existing systems and use existing records as the system of record. That can work, but only if master data, event timestamps, genealogy, and defect coding are reliable enough to support consistent risk signals. If integration is weak, predictive insights may remain advisory and manual rather than fully embedded in inspection and audit workflows.

    Practical tradeoffs

    • More targeted inspection can improve efficiency, but only if your risk logic is explainable and accepted by quality leadership.

    • Dynamic audit plans can focus attention on emerging issues, but too much volatility can make governance harder and evidence trails weaker.

    • Advanced models may detect subtle patterns, but simpler rule-based scoring is often easier to validate, explain, and sustain.

    • Plant-specific tuning can improve relevance, but it increases maintenance and can reduce consistency across sites.

    The short answer is yes: predictive insights can materially improve inspection and audit planning. But in regulated manufacturing, the safe and practical use case is usually to augment human risk review, not replace prescribed controls. The gains depend on data quality, model governance, validation discipline, and how well the analytics coexist with existing quality and execution systems.

  • What are the 10 clauses of ISO 9001?

    ISO 9001:2015 is organized into 10 high-level clauses. In regulated and industrial environments, it is important to distinguish between the introductory clauses and the auditable requirements.

    The 10 clauses of ISO 9001:2015

    The standard is structured as follows:

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

    1. Scope
      Defines what the standard covers and its intended application. This clause itself is not an auditable requirement for your organization, but it frames how the rest of the standard should be interpreted.
    2. Normative references
      Lists other documents that are indispensable for applying the standard. In ISO 9001:2015, the main normative reference is ISO 9000 for fundamentals and vocabulary.
    3. Terms and definitions
      Points to the formal definitions used in the standard, primarily via ISO 9000. These definitions affect how requirements are interpreted during implementation and audits.
    4. Context of the organization
      Requires you to understand internal and external issues, identify interested parties and their needs, define the scope of your quality management system (QMS), and establish the QMS and its processes. In a brownfield manufacturing environment, this often means mapping existing processes, systems, and regulatory obligations into a coherent scope statement and process model.
    5. Leadership
      Requires top management commitment, assignment of roles and responsibilities, and promotion of a quality policy and quality objectives. Evidence typically includes documented policies, organizational structures, and leadership involvement in reviews and resource decisions.
    6. Planning
      Covers actions to address risks and opportunities, quality objectives and planning to achieve them, and planning changes to the QMS. In regulated operations, this frequently connects to formal risk management, change control, and documented planning for system and process modifications.
    7. Support
      Addresses resources, competence, awareness, communication, and documented information (creation, control, and retention). This clause touches directly on document control, training records, system access, and how you manage controlled procedures and work instructions across existing MES/ERP/QMS and local tools.
    8. Operation
      Covers operational planning and control, requirements for products and services, design and development (where applicable), control of externally provided products and services, production and service provision, release of products and services, and control of nonconforming outputs. In industrial plants, this is where most process controls, records from production systems, supplier controls, and nonconformance management are evaluated.
    9. Performance evaluation
      Requires monitoring, measurement, analysis, and evaluation; internal audits; and management review. Compliance in practice relies on accessible, reliable data from existing systems, plus a functioning internal audit program and structured management review with documented outputs and follow-up.
    10. Improvement
      Addresses nonconformity and corrective action, and continual improvement of the QMS. This typically relies on CAPA processes, structured root cause analysis, and evidence that improvements are planned, implemented under change control, and evaluated for effectiveness.

    Auditable requirements vs. introductory clauses

    Only clauses 4 through 10 contain requirements your organization must meet and demonstrate through objective evidence. Clauses 1 through 3 define context for the standard itself. In audits, nonconformities are typically raised against specific subclauses within 4 to 10.

    Implications for industrial and regulated environments

    In complex, long-lifecycle manufacturing environments, each of the auditable clauses interacts with existing systems and processes:

    • Context, leadership, and planning (4, 5, 6) require aligning existing corporate policies, plant-level practices, and regulatory obligations. Misalignment between sites or between quality and operations is a common failure mode.
    • Support (7) depends heavily on how you manage training, documents, and records across legacy and modern systems. Fragmented document control and unclear master-data ownership are frequent audit findings.
    • Operation (8) is constrained by installed equipment, validated processes, and integration debt between MES, ERP, PLM, and QMS. Full system replacement strategies here often fail due to validation burden, downtime risk, and the need to preserve historical records and traceability.
    • Performance evaluation and improvement (9, 10) require trustworthy data and disciplined CAPA execution. Gaps in data integrity, traceability, or follow-through on corrective actions often show up as systemic nonconformities rather than isolated issues.

    The clauses define what must be addressed, but how you implement them is constrained by plant realities, regulatory expectations, and the coexistence of multiple systems and processes. Each implementation choice involves tradeoffs in cost, disruption, and evidentiary strength during audits.

  • What are common AS9100 mistakes?

    Common AS9100 mistakes tend to come from treating the standard as a documentation project instead of a way to run the operation. The details vary by plant and supply chain tier, but the same failure modes show up repeatedly.

    1. Treating AS9100 as a paperwork exercise

    Typical issues:

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

    • Writing procedures to match the standard clause-by-clause, rather than how work is actually done.
    • Creating forms and logs that no one uses, or that are filled out after the fact for audits.
    • Separating the “AS9100 system” from the real production, planning, and engineering processes.

    Risk: Audits may pass on paper, but the QMS will not prevent escapes, recurring nonconformities, or customer findings. In regulated environments this creates traceability gaps and weak objective evidence.

    2. Weak process ownership and unclear accountability

    Typical issues:

    • No clearly defined process owners with authority to change and improve the process.
    • RACI ambiguity across quality, engineering, production, and supply chain for key controls like FAI, concessions, and nonconforming product.
    • Quality expected to “own” AS9100 alone instead of shared ownership across functions.

    Risk: Processes drift, changes are made informally, and no one feels responsible for systemic issues surfaced in audits, MRB, or CAPA.

    3. Risk-based thinking done superficially

    Typical issues:

    • Risk registers created once for certification, then not updated when product mix, suppliers, or systems change.
    • FMEAs written to satisfy customers but not referenced during design changes, routing changes, or capacity shifts.
    • Operational risks (IT outages, data integrity, legacy equipment failures, supplier instability) not linked to controls in everyday planning.

    Risk: The organization claims to use risk-based thinking, but production scheduling, engineering changes, and supplier decisions ignore known high-risk areas.

    4. Poor integration of design, manufacturing, and quality

    Typical issues:

    • Design and manufacturing using different bills of material or configuration rules, causing mismatches on the floor.
    • Engineering changes not fully propagated into routings, NC programs, work instructions, inspection plans, and gauge programs.
    • Quality planning (control plans, inspection plans, sampling) not updated when design or process changes occur.

    Risk: Nonconformities emerge because the shop is effectively building an obsolete or ambiguous configuration, while documentation suggests control exists.

    5. Inadequate configuration and document control

    Typical issues:

    • Multiple, unsynchronized sources of truth for drawings, models, work instructions, and inspection criteria (PLM, shared drives, paper, operator copies).
    • Uncontrolled local edits to work instructions or setup sheets created to “get parts out” without formal change control.
    • Obsolete documents still available on the floor or in test areas.

    Risk: Traceability and configuration management are undermined. When a defect is found, it is hard to know which revision was actually built or inspected, particularly in long-lifecycle programs.

    6. Nonconforming product and MRB handled informally

    Typical issues:

    • Scrap, rework, and concessions logged inconsistently or only when costly, leading to underreported nonconformities.
    • Material Review Board decisions not clearly documented, with incomplete data on defect type, cause, and disposition.
    • Use-as-is decisions taken under schedule pressure without full technical risk assessment or customer approval where required.

    Risk: Incomplete history of nonconformities makes it difficult to demonstrate control, perform effective root cause analysis, or defend decisions to customers or regulators.

    7. CAPA used as a form, not a problem-solving process

    Typical issues:

    • Corrective actions focusing on retraining or updating a procedure without addressing underlying design, process, or system issues.
    • Root cause analysis done superficially, with no data verification or validation of the identified root cause.
    • Effectiveness checks either not done, or done as a simple statement rather than using objective performance data.

    Risk: Recurring issues persist, customers see the same nonconformities, and external auditors identify repeated findings over multiple cycles.

    8. Supplier control focused on approval, not ongoing performance

    Typical issues:

    • Initial supplier approvals are thorough, but ongoing surveillance is minimal or based only on on-time delivery and overall PPM.
    • Special processes, outside processing, and lower-tier suppliers not fully visible or controlled.
    • Changes at the supplier (equipment, personnel, process, sub-tier sources) not detected until quality issues appear at incoming inspection or in the field.

    Risk: AS9100 requirements for supplier control are met on paper, but real control is weak, especially for high-risk processes and critical characteristics.

    9. Underestimating evidence expectations for audits

    Typical issues:

    • Relying on tribal knowledge instead of maintained records that show planning, execution, review, and improvement.
    • Data dispersed across MES, ERP, QMS, spreadsheets, and email without clear linkage to orders, serial numbers, and configurations.
    • Inability to quickly retrieve objective evidence for samples selected by the auditor, especially in older programs or legacy systems.

    Risk: Auditors question the effectiveness of the QMS because the organization struggles to demonstrate what actually happened, even if the work was done correctly.

    10. Neglecting legacy systems and brownfield realities

    Typical issues:

    • AS9100 procedures that assume clean, integrated systems when actual operations run on a mix of legacy MES/ERP, manual workarounds, and local spreadsheets.
    • Interfaces between systems (e.g., ERP to MES, PLM to shop floor, QMS to calibration) not documented or validated.
    • Attempts to “fix” gaps with a full system replacement that stalls due to validation burden, downtime risk, and integration complexity.

    Risk: The documented QMS diverges from real information flows. Traceability, data integrity, and change control suffer, particularly during system changes or partial deployments.

    11. Inadequate change management and validation for system changes

    Typical issues:

    • Changes to ERP, MES, QMS, PLM, or inspection software implemented without impact assessment on AS9100 processes.
    • Insufficient validation or parallel runs before switching off old systems or tools.
    • Poor communication of changes to operators, inspectors, planners, and engineers.

    Risk: Unintended side effects produce silent failures in planning, traceability, or inspection records that appear months later as customer or regulator findings.

    12. Training and competence treated as one-time events

    Typical issues:

    • Initial AS9100 training provided during implementation, then rarely refreshed or tailored to roles (e.g., operators vs planners vs buyers).
    • Competence requirements defined generically and not aligned with actual process risks or special processes.
    • On-the-job training not documented, making it difficult to prove competence for key tasks during audits.

    Risk: Skill gaps persist in critical areas like configuration management, data entry, special processes, and problem solving, even though everyone has a training record.

    13. Management review focused on slides, not decisions

    Typical issues:

    • Management review seen as an annual obligation, not a working mechanism to steer quality and risks.
    • Metrics presented without clear actions, owners, and due dates.
    • Inputs such as audit results, customer feedback, risks, and resource needs discussed, but not used to drive specific changes.

    Risk: Top management appears committed formally, but there is little evidence that the QMS drives resource allocation, priorities, or systemic improvements.

    Practical ways to avoid these mistakes

    To reduce the likelihood of these common pitfalls:

    • Map real processes first, then align them to AS9100 requirements, not the other way around.
    • Assign clear process owners and make them accountable for performance, risk, and improvement.
    • Integrate risk, configuration control, CAPA, and supplier oversight into existing planning and engineering workflows.
    • Document and validate system interfaces and changes, recognizing legacy constraints and long equipment lifecycles.
    • Use internal audits and customer feedback to test whether the QMS works in practice, not just on paper.

    The specific controls and evidence needed will depend on your product mix, customer requirements, system landscape, and process maturity; the goal is not perfection against a template, but a QMS that reliably reflects and controls how you actually operate.

  • 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.

  • How often should aerospace organizations review their risk register?

    There is no single mandated review frequency that fits every aerospace organization, but in regulated, complex environments a multi-layered cadence is usually expected.

    Typical baseline cadences

    For most aerospace manufacturers, MROs, and system integrators, a practical pattern looks like:

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

    • Quarterly formal review of the enterprise or site-level risk register, tied to management review, internal audits, or steering committee meetings.
    • Monthly operational review of high and emerging risks in production, MRO, supply chain, and IT/OT security, often embedded in existing performance or safety meetings.
    • Event-driven updates any time a significant change or incident occurs, such as configuration changes, process transfers, major quality escapes, supply disruptions, or cybersecurity events.
    • Annual deep-dive reassessment of the overall risk framework, criteria, and assumptions, often aligned with QMS, SMS, or ISMS review and strategic planning.

    The register should be treated as a living artifact. If risks and mitigations remain unchanged between reviews, that should be explicitly confirmed and documented, not assumed.

    Factors that should drive review frequency

    The appropriate cadence depends on your specific context. Common drivers include:

    • Program phase and lifecycle: Development, industrialization, and ramp-up typically justify more frequent reviews than stable, mature production, because design, suppliers, and processes are still changing.
    • Regulatory and customer expectations: Commitments under AS9100, internal process audits, OEM/customer contracts, and aviation authority expectations can implicitly set minimum review expectations, especially where safety or continued airworthiness is involved.
    • Risk profile and tolerance: Safety-critical systems, complex assemblies, and software-heavy products often require tighter monitoring than lower criticality parts or services.
    • Change volume: High rates of engineering change, supplier churn, site transfers, or digital transformation justify more frequent reviews because underlying assumptions age quickly.
    • Incident history: Repeated escapes, audit findings, cyber incidents, or recurring supply issues are strong signals that the risk register is stale or incomplete and needs more frequent attention.
    • System maturity: Organizations with integrated QMS/MES/ERP and strong metrics can review efficiently and more often. Fragmented, manual environments may be forced into less frequent but more intensive reviews, with higher risk of blind spots.

    Brownfield and system coexistence considerations

    In brownfield aerospace environments, risk data is typically scattered across QMS, MES, ERP, PLM, safety management systems, and spreadsheets. Review cadence and quality are constrained by:

    • Integration gaps: If nonconformances, CAPA, maintenance data, and supplier performance are not linked to the risk register, reviews rely on manual compilation and expert memory, which slows frequency and can miss systemic risks.
    • Legacy tools: Older QMS or risk tools might not support easy re-prioritization or trending, so organizations gravitate to quarterly or annual reviews simply because it is operationally manageable.
    • Validation and change control: Introducing or modifying digital risk tooling in aerospace often requires validation, qualification, and formal change control. This is one reason why full replacement of legacy risk tools is rare; incremental integration and overlay approaches are more realistic.
    • Downtime and data availability: MES or ERP downtime, data quality issues, or delayed batch uploads can impact when risk analyses are credible. Some sites time reviews around known data availability windows.

    Because full system replacement is difficult in long-lifecycle aerospace environments, many organizations end up with a hybrid model: the “official” risk register in a QMS or governance tool, supplemented by operational risk views derived from MES, maintenance, or supplier data. Review cadence must acknowledge this split and ensure both views are reconciled.

    Minimum practical expectations

    Given typical aerospace risk, traceability, and compliance obligations, it is difficult to justify reviewing an enterprise or site-level risk register less frequently than:

    • Quarterly for formal, documented review of significant operational, quality, safety, and cybersecurity risks, with evidence of updated status and actions.
    • Immediately after major events, such as significant escapes, accidents or serious incidents, large-scale rework or scrap, critical supplier failure, or material OT/IT security events.

    Some organizations choose monthly formal reviews during high-risk periods (e.g., industrialization, certification, first article for new programs, major facility moves), then relax to quarterly once the risk profile stabilizes.

    Practical ways to operationalize the cadence

    For leadership teams in manufacturing, quality, and IT/OT, a workable approach is to:

    • Define clear triggers that force an out-of-cycle update, such as yield drops beyond a threshold, repeated NCRs on a key characteristic, or changes to critical software or OT assets.
    • Align reviews with existing forums such as management review, internal process audits, safety boards, and cyber risk committees, so risk register updates leverage work already being done.
    • Use stratified views: keep one master risk register but maintain filtered views for production, MRO, supply chain, and IT/OT, so each function can review at an appropriate cadence without fragmenting the source of truth.
    • Link to data where possible: even partial integration with MES, QMS, and supplier data helps focus reviews on risks that are actually moving.
    • Document rationale: when the cadence or scope of review is adjusted (e.g., from monthly to quarterly), record the justification and supporting evidence, since this is often probed in audits and customer reviews.

    Ultimately, the right frequency is the least intensive cadence that still gives leadership early warning of deteriorating conditions, within the constraints of existing systems, validation requirements, and resource limits.

  • 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.

  • certificate of conformity

    A certificate of conformity is a formal document issued by a manufacturer, distributor, or authorized supplier stating that a specific product, batch, or lot complies with defined requirements. In industrial and regulated manufacturing, it typically attests that the delivered material or part meets applicable specifications, drawings, standards, and purchase order conditions.

    What a certificate of conformity usually includes

    While formats vary by organization and industry, a certificate of conformity commonly includes:

    • Identification of the supplier issuing the certificate
    • Customer name and purchase order reference
    • Part number, description, and revision level
    • Lot, batch, or serial numbers for traceability
    • List or reference to applicable specifications, standards, or drawings
    • A statement that the product conforms to these specified requirements
    • Date of issue and an authorized signature or electronic approval

    In aerospace and other highly regulated sectors, certificates of conformity are often required for every shipment, and may be tied to quality system requirements such as AS9100 or ISO 9001.

    How it is used in operations

    Operationally, a certificate of conformity is part of the incoming quality and traceability record set. It is used to:

    • Support receiving inspection and acceptance decisions
    • Document that purchased items are claimed to meet contractual and regulatory requirements
    • Link materials to work orders, build records, and device history or as-built records
    • Provide traceability evidence for audits, investigations, and nonconformance reviews

    A certificate of conformity is evidence of the supplier’s declaration, not a substitute for risk-based verification activities. In areas such as counterfeit parts prevention, it is commonly used in combination with supplier approval, test/inspection, and traceability controls.

    What it is not

    A certificate of conformity:

    • Does not by itself prove the product meets requirements; it documents the supplier’s attestation
    • Is not the same as detailed test reports or inspection records, which show actual measured results
    • Is not an official regulatory approval or certification from a government or standards body

    Common confusion

    • Certificate of conformity vs. certificate of analysis (CoA): A certificate of analysis typically includes actual measured data (for example, chemical composition, mechanical properties). A certificate of conformity usually states compliance to requirements without listing full test data.
    • Certificate of conformity vs. compliance certificate from authorities: Some jurisdictions use the term for regulatory approvals. In manufacturing supply chains, it most commonly refers to a supplier-generated quality declaration for specific parts or lots.

  • Does AS9100 mandate specific NCR response or closure timelines?

    No. AS9100 does not mandate specific, universal timelines (for example, “respond to all NCRs within 24 hours” or “close within 30 days”). Instead, it requires that nonconformities are controlled, investigated, and corrected in a timely and effective manner, but leaves the exact time expectations to be defined by the organization and, in many cases, by customer-specific requirements.

    What AS9100 actually requires for NCRs

    AS9100 (aligned with ISO 9001) includes requirements related to nonconformity and corrective action such as:

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

    • Identifying and controlling nonconforming outputs to prevent unintended use or delivery.
    • Documenting nonconformities, actions taken, and concessions or deviations where applicable.
    • Investigating significant or recurring nonconformities to determine causes.
    • Implementing corrective actions and reviewing their effectiveness.
    • Retaining records to demonstrate what was done and when.

    The standard consistently uses language like “timely,” “without delay,” and “as appropriate,” but it does not assign numeric due dates. Auditors will look for whether your defined process times are being met and whether they are appropriate to the risks, not for a specific calendar threshold from the standard itself.

    Where specific NCR timelines usually come from

    Specific response and closure expectations typically come from:

    • Customer requirements and contracts: Many primes and OEMs explicitly require supplier NCR or SCAR responses within fixed windows (for example, 24–72 hours for containment, 10–30 days for root cause and corrective action). These then become mandatory for you, even though they are not in AS9100.
    • Internal procedures and QMS documentation: Your own QMS may define targets such as initial response, disposition, MRB decision, and closure timelines. Once documented, these become auditable commitments under AS9100.
    • Regulatory or airworthiness expectations (indirectly): For safety-critical or airworthiness-related findings, authorities, DERs, or delegated organizations may expect very rapid control and investigation, even if not framed as a formal “NCR closure SLA.”

    In practice, AS9100 auditors will challenge NCRs or corrective actions that remain open for very long periods without justified rationale, evidence of progress, or risk controls, even though there is no explicit maximum time in the standard.

    How auditors typically judge “timeliness”

    Because the standard does not give fixed timelines, auditors generally assess your NCR timeliness against:

    • Your own procedures and targets: Are you consistently meeting the response and closure times you defined? If not, do you track and address misses?
    • Risk to product quality and safety: High-risk or safety-critical nonconformities are expected to be contained and evaluated very quickly. Long delays here are a red flag, regardless of written targets.
    • Customer expectations and flowdowns: If customer requirements specify response windows, auditors will check adherence and evidence that you manage those obligations.
    • Evidence of active management: Is there visibility of aging NCRs, documented escalation, and prioritization, or do records show NCRs simply sitting open?

    A common nonconformity in audits is not that an NCR exceeded a specific number of days, but that the organization cannot demonstrate effective control, prioritization, and follow-through aligned with its own defined expectations and customer requirements.

    Implications for processes and systems

    In realistic aerospace and defense environments, NCR and corrective action workflows are spread across QMS, MES, ERP, and sometimes separate supplier portals. To stay compliant without overcommitting:

    • Define realistic targets: Set response and closure expectations that reflect your actual investigation capacity, MRB cadence, and engineering availability, then document them in your procedures.
    • Differentiate by risk: Use different expectations for safety-critical, conformity-critical, and lower-risk NCRs, so that urgent issues are clearly prioritized.
    • Align with customer SLAs: Where primes or OEMs stipulate NCR or SCAR response times, integrate those into your internal tracking and escalation, ideally with automated reminders and status visibility.
    • Account for brownfield reality: If NCRs originate in MES but are analyzed and approved in a separate QMS or supplier portal, make sure aging metrics and due dates are visible across systems. Integration gaps are a common cause of missed customer timelines and audit findings.
    • Monitor NCR aging: Track aging and backlog by risk level and ownership, and show that you review this routinely (for example, in MRB or quality review meetings). This is often more persuasive to auditors than a nominal “30-day closure” rule that is routinely missed.

    Full replacement of legacy QMS/MES systems purely to enforce NCR timelines is rarely justified in aerospace contexts given qualification, validation, and downtime risks. Incremental improvements like better workflow configuration, alerts, dashboards, and limited integrations usually give more practical control over timeliness with less disruption.

    Bottom line

    AS9100 does not mandate specific NCR response or closure timelines in days or hours. It requires that nonconformities and corrective actions be controlled, investigated, and closed in a timely, risk-appropriate manner, with clear procedures and records. The concrete time expectations come from your own QMS, customer contracts, and effective operational controls, all of which must be demonstrably followed in your audited processes and systems.

  • When should an organization adopt AS9110 or AS9120 instead of AS9100?

    AS9110 and AS9120 are sector-specific aerospace quality management standards that build on ISO 9001, similar to AS9100 but for different roles in the value chain. You typically choose AS9110 or AS9120 instead of AS9100 when your organization is primarily a maintenance organization (AS9110) or a stockist/distributor (AS9120), and you do not perform aerospace design and production activities covered by AS9100.

    When AS9100 is usually the right fit

    AS9100 is generally appropriate when you:

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

    • Design aerospace products (airframes, engines, avionics, systems, components).
    • Manufacture or assemble parts, structures, or systems for OEMs, primes, or Tier 1–3 suppliers.
    • Control production processes (machining, fabrication, special processes, integration, testing).
    • Have responsibilities for product realization that go beyond distribution or maintenance.

    In regulated and defense contexts, primes frequently specify AS9100 for design and production suppliers. If you are cutting metal, molding composites, doing special processes, integrating systems, or holding design authority, AS9100 is usually the baseline expectation.

    When AS9110 is a better fit

    AS9110 focuses on aerospace maintenance organizations, including MRO providers for aircraft, engines, components, and line maintenance. It is more suitable than AS9100 when you:

    • Provide maintenance, repair, and overhaul services on in-service aircraft, engines, or components.
    • Operate in environments governed by continuing airworthiness, OEM maintenance manuals, and regulatory approvals (for example, under civil aviation authorities or defense equivalents).
    • Do not design new products or run serial production of new hardware, but instead service existing configurations and part numbers.
    • Manage return-to-service decisions, maintenance records, service bulletins, AD compliance, and configuration status of in-service assets.

    AS9110 includes controls specific to MRO risk profiles, such as release to service, maintenance documentation control, human factors in maintenance, and configuration management of in-service equipment. If your primary value is maintaining airworthiness of existing assets rather than producing new ones, AS9110 is usually more aligned with your operations.

    When AS9120 is a better fit

    AS9120 targets organizations that buy, store, and distribute aerospace parts but do not perform transformation processes on those parts. It is generally a better choice than AS9100 when you:

    • Act as a stockist/distributor or broker of aerospace hardware or materials.
    • Do not perform design, significant manufacturing, or overhaul work on the products.
    • Focus on traceability, storage, preservation, and release of approved parts and materials.
    • Rely heavily on upstream OEMs and approved sources for conformity and documentation.

    AS9120 emphasizes controls around counterfeit risk, product traceability, shelf-life management, storage conditions, and documentation flow through the supply chain. If your risk profile is about ensuring the right certified part reaches the right customer with correct documentation and no degradation or counterfeit risk, AS9120 is typically more appropriate.

    Organizations that may need more than one standard

    Many aerospace businesses, especially in brownfield environments, operate multiple business models under one roof. You may need to consider more than one standard when you:

    • Design and manufacture parts (AS9100) and also perform MRO activities on similar equipment (AS9110).
    • Manufacture parts (AS9100) and also operate a distribution business unit selling third-party parts (AS9120).
    • Provide integrated services such as engineering, production, spares distribution, and in-service support.

    In these cases, some organizations:

    • Maintain one integrated QMS and scope statement that references multiple standards, with clear boundaries by site, process, or business unit.
    • Run separate certifications for different legal entities or operating locations.

    This quickly interacts with traceability, IT, and MES/ERP/QMS integration. Mixing MRO, distribution, and production workflows in the same systems often exposes gaps in routing, revision control, and record retention if the QMS scope and digital workflows are not clearly separated and validated.

    How to determine which standard is appropriate

    The choice is driven less by preference and more by your actual activities, risks, and customer/regulatory expectations. Practical steps:

    1. Map your value streams
      List each major value stream: design & development, new production, MRO, distribution/stockist activities, and any combination of these.
    2. Align activities to standard intent
      For each value stream, decide whether its primary risks and responsibilities align more with AS9100, AS9110, or AS9120.
    3. Review customer and contract requirements
      Many primes and regulators specify which standard is expected for which activity. In some cases, AS9100 is required even where AS9110 or AS9120 could technically fit.
    4. Consider your long-term strategy
      If you plan to add design or manufacturing capabilities, AS9100 may be the more future-proof base, with AS9110/AS9120 added later as appropriate.
    5. Evaluate integration and validation impact
      Introducing or expanding standards in a brownfield stack (MES, ERP, PLM, QMS) affects procedures, records, and evidence trails. Plan for validation, change control, and limited downtime windows.

    Tradeoffs and constraints

    Key tradeoffs to acknowledge:

    • Complexity vs. specificity: Adopting AS9100 for everyone can simplify the story but may add controls that are not well-matched to MRO or distribution activities. Using AS9110 or AS9120 where appropriate provides better alignment but increases certification complexity if multiple standards are in play.
    • Certification scope management: In mixed operations, defining which locations, processes, and systems fall under which standard is non-trivial. Poor scoping leads to audit findings and operational confusion.
    • IT and system coexistence: Legacy ERP, MES, and QMS platforms are often not structured to distinguish clearly between production, MRO, and distribution flows. Trying to implement multiple standards without rethinking routing, status control, and record structures can create traceability gaps.
    • Long equipment and system lifecycles: Plants and MRO shops often run equipment and software for decades. Replacing or heavily modifying systems purely to align with a standard is rarely feasible due to validation cost, downtime risk, and integration debt.

    In practice, many organizations layer the chosen standard(s) onto existing systems through procedures, work instructions, and incremental configuration changes rather than full platform replacement.

    Why not just upgrade everything to AS9100?

    Some organizations consider making all operations AS9100-certified to simplify messaging. This can work, but there are limitations:

    • AS9100 is optimized for design and production; it may not address some MRO-specific or distribution-specific risks covered more explicitly in AS9110/AS9120.
    • Regulators, airworthiness authorities, or primes may explicitly ask for AS9110 for MROs or AS9120 for distributors.
    • Maintaining AS9100 controls where they are not value-adding can increase bureaucracy without improving risk control.

    In heavily regulated or defense environments, certification strategy should follow the actual risk profile and regulatory expectations of each line of business, not just brand considerations.

    Connecting to digital systems and brownfield environments

    Whatever standard you choose, auditors will look for consistent evidence in your digital and paper records. For example:

    • AS9100: design records, production travelers, inspection data, FAI records, nonconformance and CAPA workflows.
    • AS9110: maintenance work cards, configuration status of individual assets, return-to-service records, and line maintenance traceability.
    • AS9120: lot/batch traceability, storage conditions, shelf-life tracking, release documentation, and supplier documentation control.

    In brownfield shops with multiple legacy systems, you rarely replace everything to “be compliant”. Instead, you typically:

    • Clarify which processes and systems support each certified scope.
    • Strengthen document control, revision control, and data integrity practices around existing tools.
    • Use incremental digitization (for example, digital travelers, improved QMS workflows) where gaps threaten traceability or auditability.

    This approach respects constrained downtime, avoids unnecessary requalification of equipment and software, and better fits long lifecycle aerospace environments.