

This article is part of the How Do YOU CM2? blog series in collaboration with the Institute for Process Excellence (IpX). Although I receive compensation for writing this series, I stand behind its content. I will continue to create and publish high-quality articles that I can fully endorse. Enjoy this new series, and please share your thoughts!
Your change control process is not standard practice. It is the product of your industry’s dominant failure mode, embedded over decades in a regulatory framework you likely inherited rather than designed.
This matters because practitioners in regulated industries rarely look across the fence. An aerospace configuration manager and an automotive quality engineer are addressing the same fundamental problem: how to authorize, document, and verify a change to a controlled configuration? Both arrive at structurally different answers. So does their counterpart, who manages a medical device portfolio. Each assumes their approach is simply how change control works. None of them is wrong. But all three are missing something.
This post puts those three approaches side by side: aerospace under AS9100 Rev D, automotive under IATF 16949:2016, and medical devices under FDA 21 CFR Part 820. The goal is not to declare a winner. It aims to explain why each approach is what it is and what practitioners in each industry systematically miss because they never look across the fence.
The Common Root
All three frameworks draw from the same conceptual well. MIL-STD-973 (Configuration Management, 1992) was the last comprehensive U.S. military CM standard before DoD shifted to commercial equivalents and adopted ANSI/EIA-649. That commercial standard codified the five core CM functions (CM Planning, Configuration Identification, Change Management, Configuration Status Accounting, and Verification & Audit) into industry-agnostic form. ISO 10007, the CM guidance standard referenced by AS9100, adopted the same five functions. The CM2 curriculum explicitly states: “This traditional approach to CM was adopted from MIL-STD-973.”
The three industry standards did not each inherit directly from MIL-STD-973. AS9100 routes through ISO 10007. IATF 16949 routes through ISO 9001. FDA Part 820 derives from GMP requirements and the Safe Medical Devices Act. However, the underlying change control principles are structurally identical across all three because they flow from the same conceptual source: classify the change, authorize it at the appropriate level, trace it through the system, and verify implementation.
Each industry then filtered that logic through its own dominant risk. The divergence that followed was not arbitrary. It was rational, given what each industry feared most.
Three Industries, Three Failure Modes
Aerospace optimizes against catastrophic single-event failure. A single undetected configuration deviation on a flight-critical component can destroy an aircraft and kill 300 people. AS9100 Rev D, therefore, treats change control as an integrity problem: every change must preserve the verifiable relationship between the configuration and the requirements that define it. Section 8.1.2 requires organizations to “plan, implement, and control a process for configuration management as appropriate to the organization and its products and services in order to ensure the identification and control of physical and functional attributes throughout the product lifecycle.” The standard does not mandate a Configuration Control Board by name, but the governance logic it requires is exactly what a CCB does: structured authorization, documented impact analysis, and verification that the change was implemented as approved. Larger aerospace primes operate formal CCBs accordingly.
The primary change verification mechanism in aerospace has traditionally been First Article Inspection (AS9102), which occurs early in the lifecycle after design approval but before production ramp. FAI requires the supplier to produce one article to demonstrate that the design is producible within their process and that the article conforms to the specification. This early-stage verification catches design-to-process gaps before production investment.
In recent years, select aerospace primes have begun adopting AS9145 (Aerospace Series – Advanced Product Quality Planning and Production Part Approval Process), which layers production system validation requirements beyond initial part verification. Where FAI asks, “Can you make this part correctly?” AS9145 adds the automotive PPAP question: “Can your entire production system sustain quality at volume?” According to RGBSI’s industry analysis, organizations such as Lockheed Martin, Harris, L-3, and Rockwell Collins have incorporated AS9145 into their supplier requirements, although adoption remains selective rather than industry-wide. Despite the standard’s publication in 2016, the 2020 AS9145 readiness survey found that widespread adoption in aerospace has been limited by implementation costs, organizational skill gaps, and the need for simultaneous adoption by both customers and suppliers.
Automotive optimization focuses on quality escapes at production scale. A defect that reaches a customer through a single vehicle is a warranty claim. The same defect affecting 200,000 vehicles constitutes a recall, a supplier reputation crisis, and financial ruin. IATF 16949:2016 treats change control primarily as a production-readiness problem. Change control is not structured through a standalone CM clause but through the APQP/PPAP cycle. A PPAP (Production Part Approval Process) is required whenever a new part, process change, or significant production change is introduced. It functions as OEM-gated change authorization: production does not resume after a change until the customer approves the PPAP submission. Tier 1 suppliers cascade this obligation to sub-tiers.
PPAP Level 3, which requires full documentation and the submission of physical samples to the customer, is the default level required by automotive OEMs. Unlike FAI’s early-stage feasibility proof, PPAP occurs late in the timeline: after the production process has been qualified and is ramping up for volume production. PPAP Level 3 requires the supplier to submit 300+ parts from the first production run, along with dimensional reports, process capability studies (Cpk values), and control plans. The customer (OEM) reviews the statistical evidence and physically inspects samples before approving full-rate production. This is volume validation, not feasibility proof. The supplier must demonstrate that their process can sustain the required quality across run-rate quantities. IATF 16949 is strong on supplier integration and production-stage control. It struggles with system-level changes: PPAP is part and process-oriented, not system-oriented.
The medical device industry optimizes for traceability loss during regulatory audits. Design-control deficiencies are consistently identified as one of the top three root causes of FDA device recalls, accounting for 13–29% of recalls depending on device class and study period. The FDA’s change control mechanism under 21 CFR Part 820 is therefore centered on documentation completeness rather than change authorization alone. The Design History File (DHF) is the governing artifact: a compilation of all design records from concept through production transfer that must demonstrate the device was developed in accordance with the approved design plan. Every significant design change must be reflected in the DHF, creating an auditable trail that satisfies regulatory scrutiny.
The classification gate in medical devices is binary and consequential. If a change “significantly impacts safety, effectiveness, or intended use of a previously cleared device,” a new 510(k) submission may be required, effectively resetting regulatory clearance. This forces an explicit decision, unlike the other two industries, which manage this informally: Is this change significant enough to warrant a higher level of scrutiny? The medical device framework is strong on documentation completeness and audit readiness. It struggles with agility: iterative improvement cycles are constrained by lengthy regulatory classification timelines.
What Each Framework Gets Right (And Wrong)
FAI (aerospace) and PPAP (automotive) are complementary rather than equivalent processes. FAI asks: “Can you prove this design works in your process?” It occurs early, with one article, to identify design-to-process misalignment before production investment. PPAP asks: “Can you prove your process will sustain this quality at production volume?” It occurs late, using run-rate quantities and statistical evidence, to identify process capability gaps that emerge only at scale.
Aerospace has historically stopped at FAI, treating early feasibility verification as sufficient. However, AS9145 (released in 2016) provides a two-stage model that combines early verification with production system validation, similar to automotive PPAP. While adoption has been limited to select primes and programs since 2016, organizations implementing AS9145 are moving toward a two-stage approach: FAI for early verification, followed by AS9145 for production system validation. This represents potential convergence toward automotive rigor, though adoption barriers have slowed industry-wide implementation.
Medical device companies operate concurrently in design and manufacturing, building the Design History File throughout development rather than gating production on early verification or late validation checkpoints. This concurrent approach allows for iterative refinement but requires disciplined documentation at each design iteration.
Why This Matters Now
All three industries are simultaneously confronting a challenge that exposes the limits of their frameworks: the continuous software updates to fielded products at rates that their traditional CM processes cannot accommodate.
Automotive is furthest into the challenge. According to the 2024 NHTSA Annual Safety Recalls Report, software-related recalls are on the rise, reaching levels from 0.6 % in 2020 to 2.5% in 2024 of all recalls and from 1.1% to 23 % of all affected vehicles. UNECE Regulation 156 adds OTA-specific requirements (version logging, rollback mechanisms, no updates while in motion) that existing IATF 16949 change control flows were not designed to accommodate. The PPAP framework was built for hardware validation and production readiness. It cannot efficiently handle weekly updates.
Aerospace is earlier in the same transition. Aviation OTA updates for legacy systems remain largely reliant on physical media. DO-178C certification requirements for avionics software changes were designed for release cycles measured in months, not continuous deployment. The aerospace approach, rooted in single-failure criticality, is ill-suited to distributed software updates, where the failure mode is not a single event but degradation across a fleet.
Medical devices face the most acute version of this problem. A 2025 peer-reviewed study (Taylor & Francis) found the current FDA regulatory approach “not fit for purpose” for fast-moving Software as a Medical Device (SaMD) or AI/ML devices. The 510(k) gating process, designed for discrete design changes, becomes a bottleneck when a device is continuously optimized. Predetermined Change Control Plans (PCCPs) are emerging as a solution: pre-authorizing categories of changes so that each software update does not trigger a new 510(k) submission. This is essentially the CM2 fast-track concept applied to regulatory classification, and it represents the most structurally interesting development in change control governance across all three industries right now.
Three Practices Worth Borrowing
From medical devices: Document the rationale, not just the decision. Most aerospace and automotive change records capture what changed and whether it was approved. FDA design controls require documenting the rationale for: why this design approach was chosen, why this change was assessed as non-significant for 510(k) purposes, and why this risk was accepted. The DHF’s evidentiary standard for design decisions has no structural equivalent in AS9100 or IATF 16949. For high-risk changes in any industry, the rationale behind the decision is often more valuable than the decision record itself. It becomes evidence in retrospective failure analysis.
From automotive: Cascade change-control obligations to sub-tiers prior to production.PPAP explicitly requires supplier involvement in the change-approval process before production resumes. Aerospace manages supplier change control primarily through prime-to-sub traceability requirements, which are often identified after the fact. The medical device industry focuses on supplier qualification rather than the cascaded change process. The automotive discipline of requiring supplier sign-off before the customer accepts a changed part is a structural governance mechanism that the other two industries implement more informally, at higher cost and lower effectiveness.
From aerospace: Separate feasibility verification from process validation. FAI’s early-stage approach catches design-to-process gaps before production investment. The AS9145 framework provides a model for combining early verification with later production-system validation, a two-stage approach that other industries could examine. Automotive could apply FAI-style feasibility checks before authorizing the APQP cycle. Medical devices could use early process feasibility reviews before committing to a design trajectory. The aerospace principle is straightforward: verify that a design is producible within a supplier’s specific process before authorizing production setup, and then layer production system validation to ensure sustained quality. Both stages have value, but they answer different questions at different times.
The Framework-Neutral View: CM2
Looking across all three industries, the CM2 framework developed by the Institute for Process Excellence (IpX) provides a useful translation layer. It does not supersede these industry standards. It makes their structural choices visible by naming what each is doing.
CM2’s two-board governance structure applies across all three industries: the Change Review Board (CRB) oversees technical governance, and senior managers review high-risk change requests. The Change Implementation Board (CIB) handles cross-functional implementation governance: representatives from all activities impacted by a change prepare detailed implementation plans and assign effectivity. The CRB model maps to CCB practices in aerospace and medical devices. What CM2 does that none of the three industry standards does explicitly is separate these two governance functions and make the criteria for each a documented operating standard. This is in line with the transition from EIA-649B to 649C, which placed greater emphasis on “Implementation Planning,” a subtle nod toward the CM2 CIB philosophy.
Why Cross-Industry Analysis Matters
Standards are converging in response to software-intensive products. According to Quality Magazine’s standards convergence analysis, ISO 9001:2026 is expected in late 2026, AS9100 is transitioning to IA9100 on a similar timeline, and IATF 16949 revision is planned for Q1 2027. The FDA’s Quality Management System Regulation (QMSR) took effect in February 2026, aligning with the requirements of ISO 13485. Organizations that understand how the other two industries structure their change governance will navigate this transition more quickly than those working only within their own regulatory silo.
The value of cross-industry analysis lies not in copying another industry’s approach. It is to understand why your approach is as it is and to clarify the problem it was designed to solve. That clarity is a prerequisite for adapting it to a problem it was not designed for. When software velocity breaks your framework, you need to understand whether you need a new framework or a more granular application of the one you have. That understanding comes from seeing how others solved the same problem differently. What CM2 offers here is not a fourth industry’s answer, but a framework-neutral vocabulary for asking the question: not what your standard requires, but what your governance structure is actually trying to accomplish, and where the threshold between fast and slow should sit.