Definitive Guide to Change Management & Change Control for Medical Devices

TABLE OF CONTENTS

What triggers a change

Changes arrive from predictable and unpredictable directions. The predictable ones come from your own roadmap: a design improvement you planned, a process you're scaling, a document you're revising on its review cycle, a second supplier you're adding for continuity. The unpredictable ones come from outside, and those tend to expose whether a change system works.

Here are some examples of changes that demonstrate the range of possibilities:

• A corrective and preventive action (CAPA) investigation finds that devices are arriving damaged, and the root cause turns out to be a packaging design that doesn't hold up to temperature extremes in transit. The resulting change touches packaging specifications, shipping requirements and possibly labeling.

• A supplier's quality performance degrades to the point where the business risk of staying outweighs the cost of qualifying someone else. The change is commercial in origin and entirely technical in execution.

• A physician reports that an instrument is difficult to grip during a procedure. Post-market feedback of this kind can produce a design change, in this case to the handle geometry or an overmolded grip, with verification and possibly validation attached.

• A locked algorithm in a software as a medical device (SaMD) product turns out to underperform on a patient subgroup that was underrepresented in the original validation data. Retraining the model is a design change, and it carries its own regulatory assessment on top of the engineering work.

The scope of change control is broader than most teams assume. It reaches controlled documents of every kind, templates, forms and work instructions included, along with both quality system processes and manufacturing processes. The product itself is in scope too, which means design outputs, specifications, software, labeling and packaging. A change to any one of these can pull the others along with it, and finding out which ones before the change goes in is the entire job.

Why change systems break down

Three failure patterns account for most of the trouble teams run into with change management.

• The first is a visibility problem. Identifying every document affected by a proposed change requires either encyclopedic knowledge of the quality system or a long manual search through a large document set. Neither scales, and both depend on individuals rather than on the system.

• The second is reactive working. When each change starts from scratch, teams redo analysis that already exists somewhere, and the cost shows up as unbudgeted rework rather than as a line item anyone tracks. Recalls sit at the far end of that curve.

• The third is compounding risk. Teams are under pressure to move quickly, keep quality high and hold costs down, and a change process that depends on memory will eventually miss a document. The result is multiple change orders to fix one change, or inconsistent revision states across product lines that nobody notices until an audit.

What the QMSR changed for change control

Part 820 still exists and still carries the same citation. What's inside it changed almost completely. FDA amended 21 CFR Part 820 to incorporate ISO 13485:2016 by reference rather than restating requirements in its own words, and the QMSR final rule set the effective date at Feb. 2, 2026 after a two-year transition.

For change control, that means the two sections most procedures cite are gone. Section 820.30, which held the design control requirements including design changes at 820.30(i), is now reserved. So is 820.40, which held document controls. The regulation points instead to § 820.10, which requires a manufacturer to document a quality management system complying with ISO 13485:2016, incorporated by reference under § 820.7.

Here's where the change control requirements live now:

The substance of what you have to do is still the same as it was under the QSR. Clause 7.3.9 of ISO 13485:2016 requires that design and development changes be identified, reviewed, verified, validated as appropriate, and approved before implementation, and that the review include an evaluation of the effect on constituent parts and on product already delivered.

Terminology changed, too. Design history file, device master record and device history record are FDA constructions that the QMSR dropped in favor of the ISO equivalents: design and development file, medical device file, and medical device record. The records are substantively the same, but your procedures, forms and change templates will still be using the old names unless someone has gone through them deliberately. We've mapped the old and new record terminology in detail, and the QMSR transition covers the structural changes beyond change control.

For devices sold in Europe, EU MDR 2017/745 adds a separate obligation. Significant changes to design or intended purpose require notification to your notified body, and in some cases prior approval, before you implement.

The six questions a change assessment has to answer

Every change, however small it looks, needs an assessment before it goes in. Six questions cover the ground, and the honest answer to any one of them can expand the change dramatically.

1. Scope: how much of the system does this touch, and what will it cost in time and money? Scope separates a one-document revision from a multi-month effort with testing attached, and getting it wrong at the start distorts everything downstream.

2. Description: what exactly is changing? Vague descriptions are the root cause of changes that get approved and then implemented differently than approved.

3. Justification: why is this necessary, and what objective evidence supports it? Auditors read justifications. So does whoever inherits the file in three years and wants to know why the specification says what it says.

4. Impact: what else does this change reach, and how far? Impact assessment is where most change systems fail, so the sections below work through a single change in detail.

5. Risk: does this introduce a new hazard, modify an existing one, or affect a risk control? Under ISO 14971:2019 the risk file is a live record, which means a change can invalidate a conclusion that was correct when it was written.

6. Regulatory: does this require a submission, a notification, or a documented rationale for neither? Answer it early. Getting this one wrong late is the most expensive mistake available in post-clearance change control, because the fix is almost always a delay you can't compress.

Design changes before submission

Pre-market, the main failure mode isn't a weak change process. It's no change process at all, because the team decided documentation could wait.

Design changes during development are constant, and they're supposed to be. You're resolving unknowns. What gets lost by deferring the records isn't compliance in the abstract, it's the rationale: why a requirement was relaxed, why an alternative was rejected, why a tolerance moved. Reconstructing that eighteen months later from memory and chat threads is how submission timelines slip.

There are a couple reasons teams still defer that record-keeping. One is a worry that documenting early invites regulatory scrutiny sooner than necessary, which leads teams to postpone design control records until an advanced stage and then build them retrospectively, at which point detail falls through the cracks. The other is uncertainty about when formal design controls are supposed to start. Teams wait for a signal that never arrives, sometimes until verification and validation are already underway.

Underneath both is a procedural problem. When the change process is heavy, people avoid it, and avoidance looks like a documentation gap long before it looks like a compliance gap.

Using design reviews as a checkpoint

A lighter approach works for pre-market teams. Document the change decision and the reasoning, tie it to the affected design controls, and use design reviews as the point where accumulated changes get evaluated together rather than one at a time.

Design reviews are checkpoints in the development process, and they serve two purposes for change management specifically. They create a documented record that design controls and risk were assessed against the current state of the design, and they produce the decision about whether a change requires additional verification or validation before it goes further.

Timing and frequency depend on the device and its complexity, and there's no universally correct number. A simple Class II instrument may need a handful. A combination product with embedded software will need considerably more. The useful rule is that a design review should sit at any point where accumulated changes have moved the design far enough that the previous review's conclusions no longer describe it.

The FDA design controls waterfall shows where design reviews sit relative to inputs, outputs, verification and validation. It describes the relationship between those activities rather than mandating a waterfall development methodology, and a change process built around design reviews works equally well with agile, stage-gate or hybrid approaches.

Note: this image simply implies the relationship design reviews play during the design and development process and does not imply that FDA or any regulatory body requires a waterfall methodology.

Verification and validation are not interchangeable here, and the distinction decides how much work a change creates. Verification proves that design outputs meet design inputs, and it's required with any change that affects design outputs. Validation proves that the device meets user needs, and it's required only when the change affects how the device does that. Minor changes frequently need verification and no new validation. Changes to a user interface, an intended use environment or a patient-contacting feature usually need both.

The discipline you build pre-market is the discipline you'll have post-market, when the stakes are higher and the margin for an undocumented decision is gone.

A post-market change, start to finish (example) 

Consider a cleared Class II single-use device with a patient-contacting molded component. The incumbent resin supplier issues an end-of-life notice on the grade named in the specification, with twelve months of last-time-buy availability. An alternate grade exists from a second supplier, chemically similar but not identical.

Nobody chose this change. It's forced, which is common, and it shows the full shape of post-clearance change control better than an elective improvement does.

1. Identify and describe the change

The change isn't "switch resin." Written that way it will be approved in a form nobody can verify against later. The description has to name the component, the outgoing material designation, the incoming material designation, the supplier, and every specification document that carries those values.

The trigger record matters as much as the description. A supplier end-of-life notice is objective evidence that belongs in the change file, because it establishes why the change happened and why the timeline looked the way it did. If the change runs through an engineering change order, the notice is an attachment to it rather than a loose email in somebody's inbox.

2. Screen it against form, fit and function

Form, fit and function (FFF) is the fastest test for whether a modification counts as a design change, and it applies to individual parts rather than to the device as a whole.

• Form covers shape, size, dimensions and the other physical parameters of a component.

• Fit describes how a part physically connects to or interacts with the parts around it.

• Function is the action the part is designed to perform.

A yes to any one of the three indicates a design change, with everything that follows from that.

Run the resin substitution through it. Form is probably unchanged, since the alternate grade runs in the same mold to the same nominal dimensions, though shrinkage differences between grades can move finished dimensions enough to matter and that needs measuring rather than assuming. Fit follows form, so it stands or falls with the same measurement. Function is the one in question, because mechanical properties, the finish of the molded part and wear behavior all depend on the material.

FFF is a screening test and not a complete assessment, which is the part teams miss. Biological safety isn't an FFF question. Neither is regulatory status, and neither is whether existing process validation still holds. A change can pass FFF cleanly and still require biocompatibility work, a new submission and revalidation. All FFF establishes is that a change is a design change, which means the question of what that change actually costs belongs to the fuller assessment below.

3. Assess the impact

A patient-contacting material change reaches further than a non-contacting one. The assessment has to cover at minimum:

• Biological safety. A new material means the existing biocompatibility conclusion no longer carries automatically. ISO 10993-1:2025, published in Nov. 2025 and now the current edition, governs biological evaluation within a risk management process. Chemical characterization may resolve it without new animal testing. It may not.

• Risk file. Any hazard tied to material properties needs re-evaluation, and any risk control that depends on the old material's behavior has to be confirmed against the new one.

• Manufacturing process. Different resin grades have different processing windows. If molding parameters shift, process validation under clause 7.5.6 is in scope, and whether existing validation still covers the new material is a documented decision rather than an assumption.

• Incoming inspection. Acceptance criteria written against the old material designation stop being meaningful the moment the material changes.

• Labeling. If material composition appears in labeling or in the instructions for use, those documents change, and 21 CFR 820.45 applies.

4. Decide the regulatory path

Post-clearance changes split into three outcomes, and the analysis that produces the split is itself a record.

FDA's guidance on deciding when to submit a 510(k) for a change to an existing device provides the decision framework, including flowcharts for specific change categories and a dedicated path for material changes on patient-contacting components. The underlying question is whether the change could significantly affect safety or effectiveness, or constitutes a major change in intended use. The comparison is always against the device as most recently cleared, not against the version you shipped last month.

A letter to file is the outcome when the analysis concludes no new submission is required. It's an internal document, not something you send anywhere, and it records the change, the evaluation and the reasoning. FDA can ask to see it during an inspection, which is the reason a thin letter to file is worse than none: it documents that you considered the question and answered it without support.

A new 510(k) is the outcome when the change could significantly affect safety or effectiveness. The Special 510(k) pathway exists for changes to a manufacturer's own legally marketed device where the methods for evaluating the change are well established and the results can be reviewed in a summarized format, which makes it faster than a traditional submission. Whether a change qualifies depends on the nature of the change and the data needed to support it, so the determination belongs with regulatory affairs rather than with whoever is running the change order.

A PMA supplement is the equivalent route for devices that reached the market through premarket approval rather than 510(k) clearance. The original regulatory pathway for the device decides which of these applies, which is why the regulatory question needs answering before the change plan is built rather than after.

For software-driven devices where modifications are anticipated in advance, a predetermined change control plan can authorize a defined envelope of future changes at the time of the original submission, removing the case-by-case question for changes that fall inside it. Changes outside that envelope return to the framework above.

For devices on the EU market the notified body question runs in parallel and on its own timeline, which is frequently the longer of the two.

5. Update every affected record

Impact assessment identifies what's affected. The update step is where the change actually lands, and it's the step most often left partially complete.

Ten records from one forced material substitution. None of them are optional, and the change isn't complete until all of them carry the same revision state.

6. Obtain approvals

Clause 4.2.4 requires that document changes be reviewed and approved by the same function that performed the original review and approval, unless specifically designated otherwise. For a change this wide, design, quality, regulatory and operations all have a defined role, and the approval record has to show who approved what and when it became effective.

Electronic signatures are the mechanism most teams use, and 21 CFR 11.50 sets out what a signed electronic record has to carry: the printed name of the signer, the date and time the signature was executed, and the meaning of the signature, whether that is review, approval, responsibility or authorship. All three have to appear in any human-readable version of the record, which rules out an approval that exists only as a row in a database somewhere.

The collection of documents moving through that approval cycle is usually called a change packet. In systems without a shared approval workflow, one person ends up carrying the packet from function to function and waiting at each stop, which is where change orders lose weeks that nobody can account for afterward.

7. Decide whether retraining is needed

Retraining gets treated as a formality and skipped more often than any other step. Here it isn't optional. Incoming inspection staff work to revised acceptance criteria, and molding operators work to a revised processing window. Both groups need training on the new revision before it takes effect, and the training records need to show it.

The test is whether the change alters what someone has to do. A specification number that changed with no change in task doesn't require retraining. A revised acceptance criterion does.

Now that we’ve taken a look at some of the things you need to consider before implementing a change, it’s time to determine the tasks and actions necessary to set things in motion.

Consider the previous example with the proposed material change to a catheter — biocompatibility testing would be required for this change. Certain staff members would need to be tasked with overseeing the testing of the new material and with reviewing the test results. Those results would then be factored into your revised design and development plans for the catheter.

Traceability and the living design and development file

Everything in the preceding section depends on knowing what connects to what. Traceability is the property that makes that knowledge available, and after clearance it's the difference between an impact assessment you can defend and one you hope is complete.

A design control traceability matrix links user needs to design inputs, design inputs to design outputs, and outputs to the verification and validation activities that confirm them. Risk sits across the whole structure, since a risk control is implemented as a design output and verified like any other.

For change management the matrix answers one question directly: given this design output, what else moves? Starting from a component specification, the matrix identifies the design inputs it satisfies, the requirements behind those inputs, the verification activities that tested it, and the risk controls that depend on it. The ten-record list from the resin change is derivable from that structure instead of assembled from memory.

The older convention was to maintain the design history file up to design transfer and treat it as closed after that. Post-market change control makes that convention unworkable. A change at year three alters design outputs, and if the file stopped at transfer there's no current record of what the design is, only a record of what it was at launch plus a pile of change orders someone would have to reconcile by hand.

Treating the design and development file as living means it reflects the device as it exists now, with the history of how it got there intact. The difference shows up during inspection. An investigator tracing from a marketed unit back through the file either finds a current, connected record or finds a snapshot from launch and a reconciliation exercise. Full traceability between pre-market and post-market stages is what makes the first outcome possible, and it's the single capability that most determines how expensive post-clearance change management becomes.

What happens when a change is spread across multiple systems

Everything above assumes the records are connected. In many companies they aren't, and the difference shows up as rework rather than as an obvious failure.

Consider the same resin change where the component specification lives in a document management system, the bill of materials lives in an ERP system, the risk file is a spreadsheet, the biological evaluation is a PDF from a testing lab, the approved supplier list is a separate spreadsheet, and training records sit in a third system. The change itself is identical. What's different is that nothing tells you the list of ten records is complete.

Two specific failures follow from that structure.

The first is the missed link. Impact assessment depends on someone remembering that the risk file references this component, or that the instructions for use state the material. Nothing enforces the connection, so completeness rests on institutional memory. The records that get missed are reliably the ones furthest from the person running the change, which after clearance means labeling, training and supplier records.

The second is the outdated version. When the specification is revised but the bill of materials still carries the superseded part number, both documents are internally valid and the system as a whole is wrong. Discovery usually comes from an auditor tracing from the device back through the file, or from a batch built to the wrong revision. Neither is a cheap way to find out.

The cost isn't the original change. It's the second change order opened to fix what the first one missed, the investigation into why the records disagreed, and the explanation to an auditor about how change control is supposed to work when the evidence in front of them shows it didn't. Strong document control reduces the version problem. It doesn't solve the traceability problem, which requires the records to be linked.

Production and process changes

Manufacturing changes follow the same assessment logic with a different center of gravity. The medical device file is the record of what the device is made of and how it's made, so process changes land there first, and the bill of materials (BOM) changes whenever a part or a supplier changes. Your BOM identifies the supplier for each part along with quantity and often cost, which makes it the record most likely to drift out of step with a specification revision.

Scaling production is the most common trigger. Moving from pilot volumes to full production typically means new tooling, different equipment, sometimes a different facility, and often a cheaper component that became viable at volume. The question under clause 7.5.6 is whether the process still produces conforming output, and whether existing validation covers the new conditions or has to be re-executed.

Supplier changes deserve particular attention because they're easy to treat as procurement decisions rather than design changes. A new supplier for an existing part requires qualification, and equivalence to the previous part is something you demonstrate rather than assume. Where the part is patient-contacting or safety-critical, the full assessment above applies, FFF screening included.

Manufacturing partners belong in the conversation early. Whether production runs in-house or at a contract manufacturer, involving them during design and development, before verification and validation begin, is what keeps process changes from arriving as surprises after transfer.

Process risk assessment

A risk assessment should accompany any manufacturing process change, and ISO 14971 supplies the structure. Four concepts carry the analysis: a hazard is a potential source of harm, a foreseeable sequence of events is what leads from that hazard to exposure, a hazardous situation is the circumstance where people, property or the environment are exposed to the hazard, and harm is the resulting damage to health, property or the environment.

Working a process change through those four does three things. It confirms that controls are in place so the product remains safe for users after the change. Inspection criteria and critical characteristics get checked for whether they're still specific enough to catch the defects a new process might introduce. Last, it settles whether further steps are necessary, process validation above all, to address hazards the change creates.

Our guide to ISO 14971 covers the method in depth.

Quality events as change triggers

A quality event is any situation that could require a product, process or document change. Nonconformances, complaints and CAPA investigations all qualify, and after clearance they become the dominant source of unplanned change.

A nonconformance is a product or component failing to meet defined specifications at some stage of manufacturing. A complaint comes from a user or partner and reaches you through post-market surveillance. Either can trigger a change on its own, and a pattern across several can trigger a CAPA investigation, which in turn frequently produces a design or process change of its own.

The connection runs in both directions. A complaint pattern can trigger a design change, and a design change can close an open CAPA. Keeping nonconformance and CAPA processes linked to the change records they produce is what lets you demonstrate that a corrective action was implemented rather than just planned. Post-market surveillance is the input side of that loop, and the quality of your change control determines whether anything comes out of it.

What connected change management looks like in Greenlight Guru

A change control system is doing its job when the impact assessment is generated from the records rather than from memory, and when the revision state of every affected document is visible in one place.

Greenlight Guru's change management capability builds on traceability between design controls, risk, documents and quality events, so a proposed change shows what it touches before it's approved. The traceability matrix stays current as changes land, which keeps the design and development file living rather than frozen at transfer. Review and approval workflows with Part 11 compliant electronic signatures hold the approval record, and training requirements tied to document revisions make the retraining decision a step inside the change rather than a separate effort someone has to remember.

The value isn't speed for its own sake. It's that the ten-record list from a forced material change is produced by the system, complete, at the point of assessment, instead of being assembled by hand and discovered to be incomplete during an inspection.

Get your free personalized demo of Greenlight Guru!