Device design and software design problems accounted for half of the U.S. recalls of medical devices enabled by artificial intelligence and machine learning (AI/ML) over a 27-year period. That recent analysis of Food and Drug Administration (FDA) recall data found software-related failures across the wider device population as well.
Design changes made without documentation or evaluation also appear in FDA warning letters. The pattern repeats when a component or protocol changes and no one produces the downstream updates.
A controlled workflow makes standards, reviewers, evidence, and the audit record explicit before implementation. This guide covers the standards that govern change control, who owns the decision, and the step-by-step process that keeps a change audit-ready.
What Is Change Control?
Change control formally evaluates, coordinates, approves or rejects, and implements changes to an established baseline. For device manufacturers, the obligation is regulatory. Design changes must be identified, documented, verified or validated as appropriate, reviewed, and approved before implementation.
Change management covers the portfolio of changes and the process that governs them. Change control handles one change at a time, while document and version control sit a level below both. Version control records successive revisions of an individual artifact, while change control decides whether that revision is allowed and what else must change alongside it. Labeling belongs to the medical device file, so labeling changes should run through formal change control.
How Change Control Reduces Audit Risk
Late-stage design modifications cost more to absorb than the same change made early, and they can delay launches and reduce product profitability. Scope creep follows the same arithmetic at the requirements level. Without a gate that forces impact assessment, small modifications accumulate into unplanned risk.
A requirement can change while its risk file under ISO 14971:2019, Medical devices: Application of risk management to medical devices, is never re-evaluated. That divergence only surfaces when an auditor pulls the record. Traceability that stays current keeps a change audit-ready because the record set already links the change, the updated risk analysis, and the re-executed verification.
Change Control Standards and Regulations to Know
The FDA’s Quality Management System Regulation (QMSR) has been in effect since February 2, 2026, and incorporates ISO 13485:2016, Medical devices: Quality management systems, by reference. Design changes must be reviewed, verified, validated as appropriate, and approved before implementation. Clause 7.3.9 of ISO 13485 assesses significance against function, performance, usability, safety, and applicable regulatory requirements. Regulated device programs often answer to multiple standards at once:
- ISO 9001:2015, Quality management systems: Requirements: Helps teams frame how to identify, review, and control design and development changes, and to retain records of reviews and authorizations.
- FDA Title 21 of the Code of Federal Regulations (CFR), Part 11: Audit trails behind change control must be secure, computer-generated, and time-stamped, and must not obscure previously recorded information.
- IEC 62304:2006+A1:2015, Medical device software: Software life cycle processes: The International Electrotechnical Commission (IEC) standard structures approved change requests and traceability within change management.
- European Union Medical Device Regulation (EU MDR): Changes that could affect a device’s safety, performance, or prescribed conditions of use may require notified body involvement.
- Industry frameworks: Aerospace programs answer to DO-178C (airborne software) and DO-254 (airborne hardware), automotive programs to ISO 26262, and defense programs to the EIA-649 configuration management standard. Each one requires a change to be evaluated and approved against a controlled baseline before it takes effect.
Together, these standards make change control a responsibility shared across technical and compliance functions. That shared responsibility shapes who sits on the board and how the board makes decisions.
Who Owns Change Control?
Many organizations use a Change Control Board (CCB) to approve changes to hardware, firmware, software, and documentation across the product lifecycle. The program or project manager often chairs the board.
Membership typically includes quality assurance, regulatory affairs, manufacturing, and research and development (R&D). Add the originator, a systems or chief engineer who owns the impact assessment, and a secretariat that screens requests and assigns reviewers. A CCB charter should define membership by function, quorum rules, authority limits, and escalation paths.
ISO 13485 focuses on appropriate review and approval, so device teams should include personnel who can provide meaningful oversight of the design process.
The Change Control Process: Step-by-Step
The eight-stage process below draws on FDA design and development requirements, ISO 13485, and configuration management practice. It is important to note that the terminology and specific records used in change control vary by organization, but the terms used below are common ways that companies set up their process. Each stage ties the change to evidence of its rationale, impact, approval, implementation, and closure.
Submit the Change Request
The process starts when an originator, often the engineer or quality reviewer who spotted the problem, opens an Engineering Change Request (ECR). It documents the problem, the proposed fix, the affected items, and the preliminary technical, cost, and schedule impacts. That ECR becomes the record every later stage builds on, so incomplete fields here delay the whole cycle.
Log and Classify the Change
Intake classification determines who reviews a change and how much evidence it needs. Medical device teams can score that call against the five ISO 13485 significance dimensions, while configuration management practice distinguishes between major and minor changes. A secretariat or change coordinator routes the ECR to reviewers based on that classification.
Impact Analysis and Risk Assessment
Reviewers evaluate the change’s effect on constituent parts, product in process or already delivered, and risk management inputs and outputs. Hazard analyses and Failure Mode and Effects Analysis (FMEA) records get re-examined here, which sets the scope of downstream verification and regulatory notification. A documented change impact analysis keeps the scope traceable across all affected items, and the resulting evidence package is what the CCB reviews at the next stage.
Review and Approval
The CCB weighs the impact assessment and decides the request. Approval produces an Engineering Change Order (ECO) that defines effectivity and identifies all affected parts, processes, and documentation. Rejected changes are returned with a documented rationale, and the ECO becomes the authorization every downstream team works from.
Verification and Validation
Verification confirms design outputs still meet design inputs. For validation, the team confirms that the product still meets user needs and intended use under actual or simulated conditions. Test and verification engineers run this stage before the change takes effect, and the resulting test records become part of the closure evidence.
Implementation
Teams execute against the approved ECO, updating designs, the bill of materials, drawings, and specifications. An Engineering Change Notice (ECN) tells manufacturing and supplier quality what changed and when it applies, including service impact.
Notification and Regulatory Submissions
A device modification that could significantly affect safety or effectiveness can trigger a new 510(k) in the U.S. In Europe, significant changes may require a notified body review, while a Predetermined Change Control Plan (PCCP) included in a marketing submission can cover the described machine learning modifications. The submission or notification record is added to the change file.
Closure and Documentation
The ECO closes only after required work is complete, and an effectiveness check shows no adverse impact. For medical devices, the records flow into the design and development file. Quality assurance signs off on closure, and that signed record is what an auditor asks to see first.
Common Change Control Challenges
Procedural weaknesses lead to similar failures in manual change control across regulated programs. Change request forms sit in inboxes awaiting a signature, with no way to trace progress or accountability.
Stale trace links hide until an audit surfaces them. A classic finding is a traceability matrix that references “DWG-1045 Rev A” while the current revision is Rev C, with the verification test executed against Rev A and never repeated. For safety-related automotive programs, the same stale link between a changed drawing and a test run against the superseded revision can break an automotive safety case.
Disconnected tools compound both problems by splitting one change across systems that never talk to each other. When the board approves a change but the training roster lives in a spreadsheet nobody updates, employees keep performing the task the old way. Change records dispersed across email, shared drives, and spreadsheets increase audit risk.
Change Control Best Practices
Programs that reduce those failure modes tend to share four habits that make the approval path easier to audit:
- Standardized change request templates: A fixed ECR format captures the problem, the proposed fix, the affected items, and the preliminary impact.
- Risk-based approval thresholds: Intake classification routes minor documentation corrections through a delegated path and reserves board review for changes affecting safety, function, or compliance.
- A single source of truth for change records: One authoritative record set with a complete audit trail replaces approvals reconstructed from email threads.
- Post-implementation monitoring: An effectiveness check at closure confirms the change met its objective and that residual risks stay acceptable.
A Corrective and Preventive Action (CAPA) that results in a process or design change must go through the full change control workflow. Closing a CAPA without opening the corresponding change control record is a common audit finding.
How Software Improves the Change Control Process
Automated routing helps teams avoid stalls in engineering change approvals and gives urgent requests clear ownership when a decision cannot wait for the next board meeting.
Purpose-built systems generate the audit trail as a byproduct of the workflow and enforce the sequencing of steps that Part 11 expects. Distributed teams work from one record set.
Grifols reduced review cycles from 90 days to fewer than 30 and saved more than 80 hours per project, according to Carmen Pazos, Diagnostic Divisions R&D Instruments Senior Manager at Grifols. When an upstream requirement changes, linked downstream records need reassessment. Spreadsheets do not automatically produce that downstream list.
How Jama Connect Supports Change Control
A CCB needs to know what a change touches before it can disposition the change. That visibility comes from the Jama Connect® requirements and traceability platform, a web-based system built for complex, regulated product development. It previews every downstream item that would be affected across multiple degrees of separation.
Live Traceability™ keeps those links current. It flags linked test cases, risk items, and design elements as suspect the moment an upstream item changes. Systems engineering, quality, regulatory, and verification teams review that same picture instead of rebuilding it from separate files. The change decision stays tied to the requirements, risks, tests, and review evidence behind it.
Build Change Control That Stays Audit-Ready
Strong change control gives engineering, quality, regulatory, and manufacturing teams a shared decision record. It turns an audit from a scramble into a formality, because every reviewer already knows where to look. To see how that record comes together on your next change, start a free 30-day trial of Jama Connect.
Frequently Asked Questions About Change Control
What is the difference between change control and change management?
If you can name the specific ECR number, you’re operating at the change control level. Change management governs the broader portfolio of proposed, evaluated, approved, implemented, and reviewed changes, as well as the metrics and improvement work across the entire system.
What is a CCB?
CCBs regulate and approve changes to hardware, firmware, software, and documentation across a system’s lifecycle. Complex programs may run hierarchies of boards, with a top-level board owning program-level change proposals and lower-level boards handling project and systems changes.
What triggers formal change control?
Any planned change that could affect product quality, process performance, regulatory status, or validated state should enter the formal process. Common triggers include supplier or raw material changes, equipment and facility modifications, software updates to regulated systems, revisions to procedures and batch records, and CAPA outcomes. Jama Connect helps teams trace those changes to affected records.
Is change control required by regulation?
Yes, and regulated programs often answer to more than one mandate at once. A single device sold in the U.S. and Europe can fall under the QMSR’s ISO 13485 incorporation and, in the EU, MDR notified body oversight, depending on the device class. Medical device software adds IEC 62304 on top of both. Requirements traceability supports the evidence each of those standards expects.
