Connect981 – Content Dev

RSC Cluster: AS9100 Aerospace Quality Management Standard

  • How much detail should be captured in an RCA for AS9100 auditors?

    You should capture enough detail in a root cause analysis to let an AS9100 auditor follow the logic, verify the evidence, and see how the result drove correction, corrective action, and effectiveness checks. More detail is not automatically better. If the RCA is vague, unsupported, or disconnected from the actions taken, it will usually fail scrutiny. If it is long but still does not show evidence, ownership, and traceability, it is still weak.

    The practical standard is this: an experienced auditor should be able to answer four questions from the record without interviewing three people to reconstruct it.

    • What exactly happened, and how was the issue bounded?
    • What evidence was used to determine the likely root cause, not just the symptom?
    • What was done immediately versus what was changed systemically?
    • How will you know the problem will not recur in the same way?

    What usually needs to be in the RCA

    In most aerospace and other regulated manufacturing environments, a credible RCA record includes the following:

    • Problem statement: specific nonconformance, affected part, process, lot, serial, program, date range, and where it was detected.
    • Containment or correction: what was done to protect the customer and segregate or control affected product.
    • Scope or impact assessment: whether similar product, prior lots, sister lines, suppliers, tooling, or work instructions were checked.
    • Root cause method used: 5 Whys, Ishikawa, fault tree, 8D, or another method used consistently enough to be defensible.
    • Objective evidence: records, inspection results, training records, machine history, revision history, maintenance data, ERP or MES transaction evidence, supplier records, or document changes that support the conclusion.
    • Root cause statement: stated at the process or system level where possible, not just operator error unless the evidence truly stops there.
    • Corrective action: the change made to prevent recurrence, with owner, due date, and affected documents or systems.
    • Verification of implementation: proof that the action actually occurred.
    • Effectiveness review: defined criteria, timing, and result.

    That is usually what auditors want to see. They are typically not asking for a long essay. They are asking whether the record is controlled, specific, and supported.

    What auditors usually challenge

    AS9100 auditors often focus less on the formatting of the RCA and more on whether the organization is solving problems in a controlled way. Common weak points are predictable:

    • Root cause equals blame: “operator missed step” with no review of training, work instruction quality, revision control, poka-yoke, inspection design, workload, or tooling condition.
    • No evidence trail: conclusions are asserted but not tied to records.
    • Correction confused with corrective action: scrap, rework, or retraining is logged, but no systemic prevention step is defined.
    • No scope review: one defect is treated as isolated without checking whether the same failure mode exists elsewhere.
    • No effectiveness criteria: action is marked complete because a form was closed, not because recurrence risk was actually tested or monitored.
    • Change control gap: process changes were made, but document approvals, training updates, validation, or system revision history do not support the change.

    If your RCA avoids those failures, the level of detail is usually in the right range.

    How much is enough in practice

    For a routine internal issue with low scope, a concise but complete RCA may fit on one well-structured record with attachments. For a customer escape, repeat nonconformance, special process issue, supplier problem, or issue tied to airworthiness, configuration, or traceability, the supporting evidence usually needs to be deeper and more formal.

    So the right level of detail depends on factors such as:

    • severity and recurrence
    • whether nonconforming product escaped downstream or to the customer
    • product criticality and contract requirements
    • whether the issue affects qualified or validated processes
    • whether multiple systems or organizations are involved
    • customer-specific corrective action response requirements

    That dependency matters. AS9100 sets expectations for controlled corrective action, but customer requirements, internal procedures, and product risk often determine how much documentation is actually needed.

    Brownfield system reality

    In many plants, RCA evidence is spread across QMS, MES, ERP, PLM, maintenance systems, spreadsheets, and email. Auditors will not excuse a weak RCA just because the evidence lives in five systems. If the record depends on fragmented data, someone still has to assemble a traceable package.

    That usually means the RCA should reference controlled records rather than copy everything into one form. Revision history, nonconformance records, work instruction versions, training completion, machine maintenance history, and lot or serial traceability should be linkable or attachable. If those links are manual, say so internally and control the process. In brownfield environments, full system replacement is usually unrealistic for this problem alone because of validation cost, downtime risk, integration complexity, and qualification burden.

    A simple test

    Your RCA probably has enough detail for an AS9100 auditor if:

    • another qualified person can understand the issue and reproduce the reasoning
    • the stated cause is supported by evidence, not assumption
    • the corrective action clearly addresses that cause
    • implementation and effectiveness are both visible in controlled records
    • related document, training, and system changes are under change control

    If those points are not true, adding more words will not fix the problem.

    Bottom line

    Capture enough detail to make the RCA auditable, evidence-based, and traceable from problem statement through effectiveness review. Do not optimize for length. Optimize for clarity, evidence, and control. The exact depth depends on risk, scope, customer expectations, and how much of the story sits across legacy systems rather than in one governed record.

  • Do organizations have transition periods between AS9100 revisions?

    Yes. When AS9100 is revised, there is normally a defined transition period, but it is not open-ended and it is controlled by IAQG and the accredited certification bodies, not by individual organizations.

    How AS9100 transition periods work

    For each new revision of AS9100 (e.g., from Rev C to Rev D), IAQG and accreditation bodies publish:

    • A date when the new revision is released and becomes auditable.
    • A start date when certification bodies may begin issuing certificates to the new revision.
    • A deadline after which certificates to the previous revision are no longer valid.

    Within this window, organizations are expected to:

    • Perform a gap assessment against the new revision.
    • Update their QMS processes, documented information, and quality manual.
    • Implement required changes on the shop floor and in supporting functions.
    • Train relevant personnel and be able to demonstrate competence.
    • Accumulate enough operational evidence to show effective implementation during an audit.

    What is and is not flexible

    Some aspects are fixed at the scheme level:

    • Deadlines: The transition deadline is set by IAQG and accreditation bodies. After that date, your old-revision certificate cannot be maintained.
    • Audit expectations: Certification bodies must audit against the new revision after defined cutover points.

    Some aspects can vary:

    • Audit scheduling: Your specific transition audit may be aligned with a surveillance or recertification audit, subject to your certification body’s rules and capacity.
    • Transition approach: How you phase changes across plants, product lines, or business units is up to you, as long as you can show effective implementation by the audit.

    Organizations should not assume that a long informal grace period exists beyond the published transition dates. Missing the formal deadline can result in suspension or lapse of certification.

    Implications for brownfield and regulated environments

    For aerospace and defense manufacturers with established MES, ERP, PLM, and legacy QMS tools, transitioning between AS9100 revisions usually means:

    • Updating document control rules, records retention, and evidence trails across multiple systems.
    • Adjusting audit trails, logs, and approvals to align with new or clarified requirements.
    • Revising procedures and work instructions in parallel with ongoing production to avoid downtime.
    • Coordinating changes with customer and regulatory requirements where they reference specific AS9100 clauses.

    Because these environments are highly validated and integrated, a full, big-bang replacement of systems during a revision transition is rarely practical. Most organizations layer incremental changes on top of existing infrastructure, with strong change control and impact assessment, to avoid re-qualification of entire stacks.

    Practical steps during a transition period

    Typical activities during an AS9100 transition window include:

    • Formal gap analysis against the new revision, with documented actions and owners.
    • Change-controlled updates to QMS documentation and linked procedures/work instructions.
    • Training plans and records to show personnel understand the revised requirements.
    • Internal audits targeted at new/changed clauses to generate objective evidence.
    • Risk assessment of any system or process changes introduced to meet the new revision.

    The level of effort and risk will depend heavily on existing process maturity, configuration management discipline, and how tightly your shop-floor and back-office systems are integrated.

  • Is AS9100 a QMS?

    AS9100 is not a quality management system (QMS) by itself. It is a standardized set of requirements for a QMS in the aerospace and defense supply chain.

    Your QMS is the combination of:

    • Processes and procedures (e.g., design control, production, inspection, nonconformance, CAPA)
    • Systems (e.g., ERP, MES, PLM, QMS software, document control tools)
    • Records and evidence (e.g., travelers, inspection results, calibration logs, training records)
    • Organizational roles, responsibilities, and governance

    AS9100 defines how those elements must be structured and controlled to meet aerospace expectations. A company can have:

    • A QMS that does not conform to AS9100 (e.g., ISO 9001 only, or a homegrown system).
    • A QMS that is designed and operated to conform to AS9100 requirements.

    What AS9100 provides (and what it does not)

    AS9100 provides:

    • Requirements and expectations for an aerospace QMS (e.g., configuration management, risk, special processes, product safety, counterfeit prevention).
    • A structure for audits and conformity assessments.
    • Common language for customers, suppliers, and certification bodies.

    AS9100 does not provide:

    • Actual processes or workflows tailored to your plant.
    • Software or tools to run those processes.
    • Any guarantee of audit outcomes or compliance in your facility.

    How AS9100 relates to your existing systems

    In a typical brownfield environment, your QMS spans multiple legacy and modern systems: ERP, MES, PLM, QMS, homegrown databases, and paper. Implementing an “AS9100 QMS” usually means:

    • Gap-assessing existing processes and systems against AS9100 clauses.
    • Defining or updating procedures, work instructions, and controls to close gaps.
    • Configuring existing tools (workflows, forms, fields, reports) to support AS9100 evidence and traceability.
    • Putting change control, validation (where required), and document control around those changes.

    Full “rip and replace” of QMS-related systems just to “get AS9100” is rarely practical in regulated, long-lifecycle operations due to:

    • Qualification and validation burden for new systems.
    • Downtime risk and constrained outage windows.
    • Integration complexity with existing MES/ERP/PLM stacks.
    • Traceability and configuration management impacts across historical data.

    Most organizations instead layer AS9100-aligned controls onto existing infrastructure and incrementally improve weak points, rather than assuming a new software platform will “be the QMS.”

    Practical takeaway

    • AS9100 = aerospace QMS requirements standard.
    • Your QMS = how your organization actually manages quality across people, processes, and systems.
    • Conforming to AS9100 requires designing, implementing, and maintaining your QMS so that it meets AS9100 requirements, with appropriate evidence, traceability, and change control.

  • AS9100 / 9100

    Core meaning

    AS9100 is a widely used quality management system (QMS) standard for organizations that design, develop, or produce aviation, space, and defense products and services. It builds on ISO 9001 by adding aerospace-specific requirements related to safety, reliability, and regulatory control across the supply chain.

    The term **9100** is often used informally to refer to AS9100 and its family of documents within the aerospace quality standard series.

    Scope and what it covers

    AS9100 commonly refers to requirements for a documented and auditable QMS in aerospace-related organizations, including:

    – Governance of quality planning, documentation, and change control
    – Design and development controls for aerospace products and systems
    – Configuration management and traceability of parts and materials
    – Production and service provision controls, including special processes
    – Risk-based thinking, including product safety and operational risk
    – Control of external providers (suppliers, subcontractors)
    – Nonconformance control, corrective action, and continual improvement
    – Management of key data and records needed to demonstrate conformity

    In regulated manufacturing environments, AS9100 requirements interact with IT/OT systems, MES, ERP, and quality systems because those systems often hold the records and controls needed to evidence QMS activities.

    Relationship to other standards

    – **ISO 9001**: AS9100 is based on ISO 9001 and incorporates all of its QMS requirements, then adds aerospace-specific clauses. An organization conforming to AS9100 is generally expected to meet ISO 9001 requirements, but AS9100 is not identical to ISO 9001.
    – **IAQG 9100 series**: AS9100 is part of the broader 9100-series standards overseen by the International Aerospace Quality Group (IAQG). Related documents include standards for aerospace distributors, maintenance organizations, and auditing practices.

    Use in industrial and manufacturing workflows

    In aerospace and defense manufacturing, AS9100 is commonly used to structure and govern:

    – QMS processes that span engineering, production, and supply chain
    – How MES records work-in-process, inspections, and process parameters
    – How ERP manages approved suppliers and controlled materials
    – How electronic batch records, device history records, or route cards are retained and linked to specific serial numbers or lots
    – How deviation, concession, and nonconformance workflows are documented and closed

    Digital systems are often configured so that key AS9100-required records (such as inspection data, calibration records, or configuration baselines) are captured, stored, and retrievable for review by internal functions or external parties.

    Boundaries and exclusions

    AS9100:

    – **Is** a set of requirements for a quality management system in the aerospace, space, and defense sectors.
    – **Is not** a product standard and does not define technical performance or design specifications for aircraft, spacecraft, or components.
    – **Is not** limited to final manufacturers; it can apply to suppliers of parts, materials, software, and related services in the aerospace supply chain.
    – **Does not** in itself confirm regulatory approval, airworthiness, or legal compliance, although it is often aligned with such obligations.

    Common confusion and misuse

    – **AS9100 vs ISO 9001**: ISO 9001 is a generic QMS standard for any industry. AS9100 adds industry-specific requirements for aviation, space, and defense, so they are related but not interchangeable.
    – **AS9100 vs AS9110 / AS9120**: AS9110 focuses on maintenance and repair organizations, while AS9120 focuses on aerospace distributors. AS9100 is more oriented to design and production organizations.
    – **”9100″ used generically**: In some organizations, people casually say “9100” when they mean the aerospace QMS requirements as a whole. This usually implies AS9100 but can informally include the broader 9100-series; usage should be clarified in formal documents.

    Application in this site’s context

    In industrial and regulated manufacturing environments, AS9100 is relevant where:

    – Aerospace or defense products are produced using integrated OT/IT architectures
    – MES, ERP, and QMS tools are configured to satisfy document control, traceability, and nonconformance management expectations found in AS9100
    – Data integrity, controlled records, and clear process ownership are needed to support audits and customer oversight under aerospace contracts

    Discussions of AS9100 in this context typically focus on how operational systems support required controls and evidence, rather than on the detailed wording of the standard itself.

  • AS9100D

    AS9100D is the 2016 revision of the AS9100 aerospace quality management system (QMS) standard. It builds on ISO 9001:2015 and adds sector-specific requirements for organizations involved in aviation, space, and defense products and services.

    AS9100D commonly refers to the requirements published in revision D of the standard. The formal name of the standard remains “AS9100”; the letter suffix (B, C, D, etc.) designates the revision level, not a different standard.

    Scope and usage in industrial operations

    In manufacturing and regulated industrial environments, AS9100D is used to structure and document quality management practices across the value chain, including:

    • Design and development of aerospace components and systems
    • Production, assembly, and integration on the shop floor
    • Special processes, testing, and inspection activities
    • Configuration management and document control
    • Supplier management and purchasing controls
    • Nonconformance management, corrective action, and risk-based thinking

    Operationally, organizations may align MES, ERP, PLM, and quality systems (such as eQMS or LIMS) with AS9100D requirements to help ensure consistent process execution, traceability, and documented evidence. This often includes controlled work instructions, device and process qualification records, change control history, and product genealogy.

    Relationship to ISO 9001

    AS9100D is structurally based on ISO 9001:2015 and incorporates all ISO 9001:2015 clauses, then adds or modifies requirements specific to aviation, space, and defense. In practice:

    • An organization conforming to AS9100D is generally understood to address ISO 9001:2015 requirements plus additional aerospace-specific controls.
    • References in procedures or quality manuals may appear as “AS9100 (rev D)” or “AS9100D aligned with ISO 9001:2015.”

    Document control and revision identification

    Within quality manuals, procedures, and technical documentation, it is common to reference the standard as “AS9100” together with the current revision, for example:

    • “AS9100 rev D”
    • “AS9100D (based on ISO 9001:2015)”

    From a document and version governance perspective, maintaining clarity on which revision is being used is important. Organizations typically:

    • Specify the applicable revision of AS9100 in their quality manual or top-level procedures.
    • Review customer, regulatory, and contractual requirements to confirm which revision must be applied.
    • Update references as standards are revised, while preserving historical records that show which revision was in force at the time.

    Common confusion

    • AS9100 vs. AS9100D: The standard is still called “AS9100”; “D” is the revision. AS9100D is not a separate standard with a new name, but the current revision of AS9100 (superseding earlier revisions such as AS9100C).
    • AS9100D vs. certification status: AS9100D describes requirements for a quality management system. Whether a specific site or organization is certified or audited against AS9100D is a separate question and depends on external assessment activities, not on the definition of the term.
    • AS9100D vs. ISO 9001:2015: ISO 9001:2015 is a generic QMS standard for many sectors. AS9100D includes ISO 9001:2015 but adds aerospace-specific expectations such as additional risk, product safety, and configuration management controls.

    Tie to the provided context

    In the referenced context about “the new name for AS9100,” AS9100D is the current revision identifier of the AS9100 standard, not a replacement name. When updating documentation, organizations typically verify the latest valid revision and any customer or contract requirements before changing references from earlier revisions (such as AS9100C) to AS9100D.

  • Which clauses in AS9100 Rev D focus on product safety?

    AS9100 Rev D treats product safety as a cross-cutting requirement. There is one dedicated clause plus several closely related clauses that most auditors will expect you to connect in your quality management system.

    Primary clause explicitly focused on product safety

    The main clause is:

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

    • 8.1.3 Product safety – Requires the organization to plan, implement, and control processes needed to assure product safety during the entire life cycle, as appropriate to the organization and the product. This includes defining responsibilities, managing safety-related events, and maintaining safety-related information.

    Key supporting clauses that impact product safety

    While 8.1.3 is the explicit product safety clause, several other clauses are directly relevant and usually need to be aligned in procedures, training, and records:

    • 4.1 & 4.2 (Context of the organization and interested parties) – Safety expectations from customers, regulators, and end users should be reflected in your QMS scope and risk priorities.
    • 5.1.1 & 5.1.2 (Leadership and customer focus) – Top management is expected to demonstrate commitment to product safety as part of customer and regulatory focus.
    • 6.1 (Actions to address risks and opportunities) – Product-safety-related risks should be identified, evaluated, and mitigated. In practice, this often links to FMEA, hazard analyses, and special characteristics.
    • 6.2 (Quality objectives and planning) – Safety-critical performance (e.g., escape defects, special processes, escapes on critical items) can be reflected in objectives and KPIs.
    • 7.2 (Competence) – Requires you to ensure competence for personnel whose work affects product safety, including training and authorization for safety-critical tasks.
    • 7.5 (Documented information) – Controls safety-relevant documents and records, including work instructions, inspection plans, and configuration baselines for safety-critical items.
    • 8.1.1 (Operational risk management) – Aerospace-specific requirement to manage operational risks, including those that influence product safety (e.g., process changes, capacity constraints, special process risks).
    • 8.1.2 (Configuration management) – Ensures that safety-critical configurations are defined, controlled, and traceable. Mismanaged configuration is a common safety failure mode in complex, long-life aerospace products.
    • 8.2 (Requirements for products and services) – Ensures that safety-related requirements from contracts, drawings, specifications, and regulations are identified, reviewed, and flowed down to operations and suppliers.
    • 8.3 (Design and development of products and services) – Where design is in scope, this clause drives systematic identification and control of safety requirements, verification, and validation, including management of changes affecting safety.
    • 8.4 (Control of externally provided processes, products, and services) – Requires safety-related requirements and controls to be flowed down to and monitored at suppliers and special process providers.
    • 8.5.1 (Control of production and service provision) – Includes the use of suitable equipment, controlled conditions, and documented instructions, especially for safety-critical operations and special processes.
    • 8.5.2 (Identification and traceability) – Enables tracking of safety-critical parts, materials, and configurations to support investigation and containment when safety concerns arise.
    • 8.5.6 (Control of changes) – Requires evaluation and control of process and product changes, including assessment of impact on product safety and re-approval where needed.
    • 8.6 (Release of products and services) – Ensures that all planned inspections, tests, and approvals related to safety requirements are complete and acceptable prior to release.
    • 8.7 (Control of nonconforming outputs) – Addresses identification, segregation, disposition, and risk assessment of nonconformances that could affect product safety, including customer and regulatory notification where applicable.
    • 9.1.1 & 9.1.3 (Monitoring, measurement, analysis and evaluation) – Data on safety-related defects, escapes, and events should be monitored and used for decision-making.
    • 10.2 (Nonconformity and corrective action) – Requires structured investigation of nonconformities that affect or could affect product safety, and verification that corrective actions are effective.
    • 10.3 (Continual improvement) – Supports ongoing reduction of safety-related risks through process and system improvements.

    Clauses linked to human factors and reporting culture

    AS9100 Rev D also ties product safety to human factors and reporting behavior:

    • 7.3 (Awareness) – Requires personnel to be aware of their contribution to product safety, including the impact of nonconformity and the importance of ethical behavior.
    • 7.4 (Communication) – Includes internal and external communication of safety-related information, including how safety issues are escalated.
    • 10.2 (Nonconformity and corrective action) – Often used to formalize safety reporting, trend analysis, and escalation of systemic safety concerns.

    Implementation notes for regulated, long-lifecycle environments

    The specific clauses are fixed, but how they apply in your environment depends on scope (design vs build-to-print), legacy QMS structure, and system integration. In brownfield operations with older ERP/MES/QMS stacks, product safety controls usually span several systems and paper-based workflows. Trying to implement product safety as an isolated “module” in a single new system often fails because:

    • Configuration management, nonconformance, and change control are already distributed across multiple validated tools and paper forms.
    • Revalidating or replacing core systems to centralize product safety can trigger significant downtime, requalification, and retraining risk.
    • Auditability and traceability expectations typically require incremental changes with strong change control, not wholesale system swaps.

    Most organizations address AS9100 Rev D product safety expectations by tightening procedures, clarifying responsibilities, improving cross-system traceability, and adding targeted digital controls on top of existing infrastructure, rather than attempting a full replacement of legacy platforms.

  • Which AS9100 clauses specifically address control of non-conforming products?

    The primary clause is AS9100 clause 8.7, Control of nonconforming outputs. That is the clause that directly addresses how an organization identifies, contains, evaluates, disposes of, and records nonconforming product or process output.

    That said, if you are asking what clauses auditors and quality teams usually look at in connection with nonconforming product, the answer is broader than 8.7 alone.

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

    Core clause

    • 8.7 Control of nonconforming outputs: This is the specific requirement for preventing unintended use or delivery of nonconforming product, defining disposition, obtaining required approvals where applicable, and retaining evidence of the nonconformity and resulting actions.

    Closely related clauses

    • 8.5.2 Identification and traceability: Relevant when affected parts, lots, serial numbers, or assemblies must be identified, segregated, and traced through rework, scrap, return, or concession workflows.
    • 8.5.1 Control of production and service provision: Relevant because nonconformance control depends on controlled execution methods, hold points, status visibility, and prevention of unintended processing.
    • 8.6 Release of products and services: Important because nonconforming product must not be released without the required review, authorization, and records.
    • 9.1.1 Monitoring, measurement, analysis and evaluation: Inspection and test results often trigger the nonconformance process, so weak measurement controls can undermine clause 8.7 execution.
    • 10.2 Nonconformity and corrective action: This is related but not identical. Clause 8.7 is about controlling the specific nonconforming output. Clause 10.2 is about investigating causes and preventing recurrence when corrective action is warranted.
    • 7.5 Documented information: Required records, disposition evidence, approvals, and revision-controlled procedures sit here.
    • 8.4 Control of externally provided processes, products and services: Relevant when the nonconformance originates at a supplier or outside processor and must be contained across organizational boundaries.

    Important distinction

    If your question is whether AS9100 has one clause that fully covers NCR, MRB, rework, scrap, deviation, concession, and corrective action end to end, the practical answer is no. Clause 8.7 is the anchor, but an effective nonconformance process usually spans multiple clauses and multiple systems.

    In brownfield operations, that often means the nonconformance record may begin in MES or inspection software, disposition may involve QMS or MRB workflows, traceability may depend on ERP or genealogy records, and release controls may sit elsewhere again. If those handoffs are weak, you can meet the wording of a procedure on paper while still having real execution gaps on the floor.

    What organizations usually need to show

    • Clear identification of nonconforming product or output
    • Containment to prevent unintended use or shipment
    • Defined disposition paths such as rework, repair if allowed, scrap, return, or acceptance under authorized concession or deviation where applicable
    • Appropriate approval authority for disposition
    • Records of the nonconformity, actions taken, and resulting decisions
    • Traceability to affected part numbers, lots, serial numbers, work orders, or assemblies as needed
    • Reverification after rework or correction before release

    How much of this is manual versus system-enforced depends heavily on process maturity, integration quality, and validation discipline. In regulated aerospace environments, full rip-and-replace strategies often fail because nonconformance handling is entangled with legacy ERP, MES, PLM, QMS, supplier portals, and customer-specific requirements. Replacing everything at once can increase validation effort, downtime risk, and traceability gaps rather than reduce them.

    So the short answer is: 8.7 is the specific clause, but in practice you should also review 8.5.1, 8.5.2, 8.6, 8.4, 9.1.1, 10.2, and 7.5 to understand how nonconforming product is actually controlled in an operating system.

  • Who actually owns and maintains the AS9100 standard?

    AS9100 is owned and maintained by the International Aerospace Quality Group (IAQG), not by individual certification bodies or software vendors.

    Who develops and controls AS9100?

    The core ownership and maintenance of AS9100 sit with:

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

    • IAQG (International Aerospace Quality Group): An industry group made up of major aerospace OEMs and suppliers. IAQG develops the aerospace quality management system requirements that become AS9100.
    • Sector organizations under IAQG: For example, AAQG (Americas), EAQG (Europe), and APAQG (Asia-Pacific) contribute to the content and balloting.

    IAQG controls the technical content, revisions, and official guidance documents (such as clarifications and deployment support materials).

    Who actually publishes AS9100?

    Although IAQG owns the content, the standard is formally published by accredited standards bodies under license from IAQG, most prominently:

    • SAE International (often designated as AS9100, e.g., AS9100D)
    • ASD-STAN in Europe (EN 9100)
    • Other national bodies that adopt the EN 9100 text as a national standard (e.g., BS EN 9100, DIN EN 9100).

    The content is aligned with ISO 9001 plus additional aviation, space, and defense requirements, but ISO itself does not own AS9100.

    What is the role of certification bodies?

    Accredited certification bodies (CBs):

    • Use the current AS9100 text owned by IAQG and published by SAE/ASD-STAN.
    • Are overseen by accreditation bodies that participate in the ICOP (Industry Controlled Other Party) scheme under IAQG.
    • Have no authority to change AS9100 requirements; they interpret and apply them within IAQG and accreditation rules.

    In regulated, long-lifecycle environments, relying on a single CB or software vendor for interpretation without checking IAQG and sector guidance can create divergence from the actual standard over time.

    What does this mean for manufacturers and MROs?

    For plants operating in brownfield, mixed-system environments:

    • Source of truth: The authoritative technical content is the current AS9100 edition as published by SAE/ASD-STAN, driven by IAQG. Local procedures, MES/QMS configurations, and training should trace back to this source.
    • Change impact: When IAQG issues a new revision or clarification, you are responsible for assessing the impact across legacy systems (QMS, MES, ERP, PLM) and processes. There is no automatic grandfathering of old interpretations.
    • Traceability: For audit readiness, be explicit about which AS9100 revision you are aligned to and keep controlled copies of the official text and any IAQG sector guidance used in your interpretations.

    Owning these links yourself is important because standards revisions occur on timelines that rarely match major system upgrade cycles, and full system replacement simply to track an AS9100 update is usually not practical or economical in aerospace-grade environments.

  • How often does AS9100 typically get revised?

    AS9100 does not follow a fixed, predictable revision schedule. Historically, major revisions have been driven by updates to ISO 9001 plus additional aerospace-sector needs.

    Historical revision pattern

    Looking at past versions gives a rough sense of cadence:

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

    • AS9100 (original): 1999
    • AS9100A: 2001
    • AS9100B: 2004
    • AS9100C: 2009
    • AS9100D: 2016

    From this history you can infer:

    • Early on, revisions were relatively close together as the standard matured.
    • More recently, major revisions have been on the order of 7–10 years apart, aligned with ISO 9001:2008 and ISO 9001:2015 changes.

    No guaranteed timetable

    There is no official, fixed interval (for example, “every 5 years”) for AS9100 revisions. Timing depends on:

    • Revisions to ISO 9001, which AS9100 builds on.
    • IAQG decisions about sector-specific needs, risks, and lessons learned.
    • Feedback from certification bodies, OEMs, and regulators.

    Because of this, you cannot reliably plan capital projects or system overhauls around a predicted next revision date. In regulated, long-lifecycle environments, most organizations instead treat AS9100 as a slowly evolving baseline and adjust incrementally as new guidance or customer requirements appear.

    What changes between major revisions

    Major revisions (like AS9100C to D) typically introduce:

    • New or restructured clauses to maintain alignment with ISO 9001.
    • Updated expectations around risk, special processes, and configuration management.
    • Clarifications around product safety, counterfeit parts, and external provider control.

    In brownfield environments with established QMS, MES, and ERP systems, these changes usually translate into:

    • Revisions to documented processes and procedures under formal change control.
    • Updates to digital forms, workflows, and records (e.g., NCR, CAPA, FAI, audit checklists).
    • Targeted training and competence updates for key roles.

    Full system replacement purely to “chase” a new AS9100 revision is rare and often impractical because of validation burden, integration complexity, and downtime risk. Most organizations adapt existing systems through configuration and supplemental controls.

    Between revisions: what actually moves

    Even when the core AS9100 standard is stable for years, requirements still evolve through:

    • Sector-specific guidance and clarifications from IAQG and certification bodies.
    • OEM and prime contractor flow-downs that tighten expectations beyond baseline AS9100.
    • Customer-specific audit findings that drive new or more detailed controls.

    Operationally, this means you should treat AS9100 as a minimum, and expect to maintain:

    • Ongoing document control and revision management for procedures and work instructions.
    • Traceable updates to digital systems, forms, and data models under change control.
    • Evidence that changes have been trained, implemented, and are effective.

    Planning implications for aerospace manufacturers

    For operations, engineering, quality, and IT leaders, the practical approach is:

    • Monitor IAQG, certification body, and OEM communications rather than assuming a fixed update cycle.
    • Design QMS and supporting systems to absorb requirement changes through configuration (fields, workflows, reports) rather than large-scale replacement.
    • Maintain clean traceability from AS9100 clauses to your internal procedures, forms, and records so impact assessment is efficient when a revision does occur.
    • Budget for periodic QMS refresh projects (process, training, and system configuration) roughly in line with the historical 7–10 year major revision pattern, recognizing timing may shift.

    In short, AS9100 is typically revised on a multi-year cycle tied to ISO 9001 updates, but the exact timing is uncertain. For most aerospace and defense manufacturers, resilience comes from robust document control, change management, and flexible systems rather than trying to predict the exact year of the next revision.