Design Change Control Under the QMSR, Step by Step

A design change alters the requirements, the risk file, the test set and the labeling. Under the QMSR, clause 7.3.9 of ISO 13485 says what must happen before the change ships. It does not list the records the change touches. That list is yours to build, and it is what an investigator reads.

This post follows one invented change through those records. The sources are the ISO 13485 clause as FDA incorporates it, FDA's 2017 guidance on software changes to cleared devices, FDA's inspection program for the QMSR, and public warning letters.

The requirements of clause 7.3.9

Clause 7.3.9 is titled "Control of design and development changes". It applies to the manufacturers 21 CFR 820.10(c) puts under design controls: class II, class III, and class I devices that run on software or appear on FDA's short list. The clause asks for the following.

• A documented procedure for controlling changes.
• A decision on the significance of each change to function, performance, usability, safety and applicable regulatory requirements.
• Identification of the change.
• Review, verification, validation as appropriate, and approval, all before implementation.
• A review that covers the effect on constituent parts, on product in process or already delivered, and on the inputs and outputs of risk management and product realization.

Records of the changes, their review and any actions taken must be kept under clause 4.2.5. Clause 7.3.10 then requires the design and development file to hold or reference everything needed to show compliance. FDA's preamble to the final rule says the file continues the role of the old design history file.

The wording differs from the QSR it replaced. Section 820.30(i) asked for "validation or where appropriate verification". Clause 7.3.9 asks for verification, and validation where appropriate. A team that kept the old reading may be skipping verification on changes it considers too small to validate.

Documenting the change and telling FDA

Is the change documented and controlled? Clause 7.3.9 answers this for every change. FDA's software change guidance says a bug fix, hot fix, patch, code change or tweak is a design change under Part 820, whatever the team calls it.

Does FDA need to see it? Under 21 CFR 807.81(a)(3), a new 510(k) is required for a change that could significantly affect safety or effectiveness, or a major change in intended use. FDA's guidance "Deciding When to Submit a 510(k) for a Software Change to an Existing Device" (25 October 2017) sets out the method. It has a companion for non-software changes issued the same day. These points shape the records.

• The team first runs a risk-based assessment. Testing then confirms the decision. Passing tests do not turn a significant change into an insignificant one.
• Each change is assessed alone and together with the others made at the same time.
• The comparison is always to the original device, meaning the most recently cleared version. Changes that each looked small can add up to a submission.
• When no new 510(k) is needed, the manufacturer documents the analysis and files it.

The guidance predates the QMSR and still cites the old section numbers. FDA added a note to the front of it saying so and urging manufacturers to check the current regulation.

A hypothetical change

Everything below is invented. The device, the identifiers and the team's ratings are made up for illustration, and a real device could land elsewhere on any judgment call.

A company sells a class II wearable nerve stimulator under a 510(k). A phone app logs each therapy session and sends the log to the clinician's portal when the phone has a signal. The app keeps 24 hours of logs in storage. Patients in areas with poor coverage lose logs before they sync. Change request CR-114 proposes to keep 72 hours and to compress the stored logs so the larger buffer fits on older phones.

The change reaches these records.

Significance and the submission question

Clause 7.3.9 asks the team to judge the change against function, performance, usability, safety and regulatory requirements. For CR-114 the team writes one line for each. Function: retention and compression change. Performance: sync timing changes. Usability: the patient sees a longer gap before a warning. Safety: one new hazardous situation. Regulatory: the stimulation output and the indications for use are untouched.

For the 510(k) question the team works through the guidance. It asks whether the change creates or modifies a hazardous situation that could result in serious harm and is not already mitigated in the cleared device. The team rates the new hazardous situation as minor. A clinician who sees an incomplete log might adjust therapy unnecessarily, and the next visit would correct it. The team says so in the record, with the rating scale it used.

The guidance's question on clinical functionality and performance specifications comes out the same way, because the log is not part of the therapy. The team concludes a new 510(k) is likely not required. It compares CR-114 to the cleared device, lists two earlier unsubmitted changes, and checks the sum. The analysis is signed and filed, as the guidance says.

A reviewer could rate the severity higher. For a device whose log drives a treatment decision, the same change would start at a different answer. The example shows where the reasoning lives, not what the right answer is.

Hazards and existing controls

The risk file gets a new entry, and the team has to decide what mitigates it: a checksum on each compressed log, and a discard-and-resend path. Clause 7.3.9 requires the review to cover the inputs and outputs of risk management. The old 12-hour reminder is the easy one to miss. Nothing in the change request mentions it, but it was sized for the 24-hour buffer. The team records a decision to keep it and why.

FDA did not incorporate ISO 14971 into the QMSR. ISO 13485 still requires risk management through the life cycle, and FDA's guidance on software changes uses the 14971 vocabulary of hazard, hazardous situation and cause.

Verification and validation

The team verifies the new requirement with the round-trip test and reruns the sync tests. It retires the 24-hour boundary test and writes down why it is no longer valid, so a reader of the file does not mistake the gap for an omission.

Validation is "as appropriate". The team decides whether the longer gap before a warning changes how patients use the device. The answer can be a written rationale. For a larger change it would be a usability study.

Review and approval before release

Clause 7.3.5 asks for review by representatives of the functions concerned, plus other specialists. The old requirement for a reviewer without direct responsibility for the stage was dropped from the regulation, and the team's own procedure may still demand one. Approval happens before the build ships.

For product already delivered, the record says that app version 2.3 keeps the 24-hour buffer, that the portal reads both formats, and that support will tell users the longer buffer needs an update.

Labeling, UDI and release

Section 820.45 requires release of labeling to be documented. The updated instructions for use are examined and released through that path. The UDI decision is recorded. The release record for the new app version cites CR-114. If the ticketing system that holds the change records is part of the quality system, clause 4.1.6 requires its software to be validated for its use.

Last, the design and development file is updated so that one search from CR-114 reaches every record above.

Inspection of change control

FDA's inspection program for the QMSR, Compliance Program 7382.850, has a change control area. Its elements are QMS changes, software changes, product and process changes, and purchasing changes. For product and process changes the program names clauses 4.1.4, 7.2.2, 7.3.9, 7.3.10, 7.5.6 and 7.5.7. The software changes element names clauses 4.1.6, 7.5.6 and 7.6, which concern software used in the quality system, production and measurement. The program does not say which element covers device software. Clause 7.3.9 is under product and process changes, so a design change to device software fits there.

Investigators pick records by product risk, and the program says several records should usually be reviewed so the finding does not rest on one. It also tells them not to write observations on the Form 483 about "the adequacy, safety, or efficacy of a particular design". Observations are limited to the adequacy of the manufacturer's procedures and controls and whether the manufacturer followed them.

Citations since the QMSR

FDA posts the citations from device inspections in its Data Dashboard. From 4 February to 20 October 2026, 404 device inspections ended with citations posted. Thirty-eight of them, 9 percent, cite clause 7.3.9. Clause 7.1, planning of product realization, led at 124 inspections (31 percent). Corrective action (clause 8.5.2) appeared in 96 and complaint handling (clause 8.2.2) in 91. The full ranking is in the post on the most cited FDA 483 observations.

FDA's wording on the 38 citations of clause 7.3.9 falls into six groups.

• Procedures to control design and development changes not documented: 13
• Requirements for changes not met before implementation: 12
• Records of changes and their reviews not maintained: 6
• Significance of changes not determined: 3
• Review that does not evaluate the effects of the change: 2
• Changes not identified: 2

Each group corresponds to a requirement in the list at the top of this post.

The nearest QSR section by subject, 820.30(i), appeared in 43 of 715 device inspections with posted citations in fiscal year 2025, which is 6 percent. Do not read 9 percent against 6 percent as a trend. The new period is shorter, and the newest inspections are still being posted. The data also cannot say whether the difference reflects how manufacturers behave or how investigators write observations under clause numbers.

Posted citations are a subset of FDA's 483s. They were 83 to 97 percent of the count in FDA's own yearly spreadsheets for devices across fiscal years 2018 to 2025. Method and limits are in the 483 post, and scripts/analyze-qmsr-iso-clauses.py in this site's repository reproduces every figure here.

Warning letters on design changes

Warning letters show what that limit looks like in practice. We searched the text of CDRH warning letters dated 1 January 2018 or later in a crawl of FDA's letter pages made in early September 2026. Of 361 letters dated before the QMSR took effect, 87 cite 21 CFR 820.30 (design controls). Eighteen cite 820.30(i), design changes. That is 5 percent of the CDRH letters in the crawl. Ten of the eighteen also cite 820.30(g), design validation. The script that produces these counts is scripts/analyze-design-change-citations.py in this site's repository. FDA removes older letters from its site, and letters are the visible tail of inspection findings, so the counts say little about how often the problem occurs.

The letters repeat a few patterns.

• The change went through the wrong door. Micro-X Ltd. (10 September 2024) processed several design changes as manufacturing deviations. The deviation permits recorded changes to fit, form or function and held no verification or validation results.
• The test did not test the fix. NeuroSync, Inc. (9 May 2025) released a software version to correct a data collection fault. The test record did not verify that the version corrected it.
• The risk assessment missed the reason for the change. Medline Industries, LP (18 March 2024) changed syringe dimensions to reduce cracking and plunger pullout. FDA said the risk assessment did not address those hazards.
• The change record was empty. Hong Qiangxing Shenzhen Electronics Limited (28 October 2025) had three of three change records reviewed that lacked adequate documentation of the description, the reason and the impact evaluation.
• The procedure never asked about premarket status. Sonesta Medical AB (22 September 2023) had no step to determine new premarket clearance or approval requirements, or the effect on the design risk analysis.

The crawl holds 35 CDRH letters dated 2 February 2026 or later. None cites an 820 section number. Eight name the QMSR and four name ISO 13485.

PCCPs and change records

A predetermined change control plan lets a manufacturer pre-authorize planned modifications in its marketing submission. Under 21 CFR 807.81(b)(1)(ii), no new 510(k) is needed for a change consistent with a cleared PCCP.

FDA's guidance for AI-enabled device software functions covers 510(k), De Novo and PMA devices. FDA first issued it as final guidance on 4 December 2024 and reissued it on 18 August 2025. A plan has three parts: a description of the planned modifications, a modification protocol, and an impact assessment. FDA's broader guidance for all devices (22 August 2024) is still a draft on FDA's site.

FDA's list of AI-enabled devices has no PCCP field. Of the 949 listed 510(k)s decided since 2023, 69 have a clearance letter saying the review included a PCCP. See the list analysis.

A PCCP changes the submission question. It does not change the records. The AI guidance says a modification consistent with the authorized plan should be documented, with its analysis, under the manufacturer's quality system. The 18 August 2025 text still cites sections 820.30(i) and 820.181. A footnote says FDA will update the references when the QMSR takes effect, and the guidance page shows no update since. Read those citations as clause 7.3.9 and the medical device file.

Tools that hold the records

FDA's computer software assurance guidance covers software used in device production or in the quality management system. FDA issued it as final guidance on 24 September 2025. On 3 February 2026 FDA replaced it with a version titled "Computer Software Assurance for Production and Quality Management System Software". The guidance takes a risk-based approach to deciding how much testing such software needs. Its scope is that software, not the device's own software. A change request system is quality system software. The app in the example is not.

One vendor has published a small study on the effort of tracing a change. Ketryx, which sells software for this task, posted results on 3 March 2026. Nine participants each did two change impact assessments, one by hand and one with Ketryx's assistant, in 30 minutes each. That gives 18 assessments across two scenarios. The post reports about 14 percent completeness for 30 minutes of manual work, and higher completeness with the assistant. The company ran the study on its own product. The post says the methodology is available on request. Nine people is a small group. Take it as a hint that people tracing links by hand under a time limit miss items. It is not a measurement of any tool.

Frequently asked questions

What does ISO 13485 clause 7.3.9 require?

Documented procedures for controlling design and development changes. The manufacturer decides how significant each change is for function, performance, usability, safety and regulatory requirements. Before implementation the change is reviewed, verified, validated as appropriate, and approved. The review covers constituent parts, product in process or already delivered, and the inputs and outputs of risk management. Records are kept under clause 4.2.5.

Do small software changes need design change control?

Yes, for devices under design controls. FDA's 2017 software change guidance treats a bug fix, patch or tweak as a design change under Part 820. The record can be short, but the significance decision and the verification are still required.

Does every software change need a new 510(k)?

No. A new 510(k) is required when a change could significantly affect safety or effectiveness, or is a major change in intended use (21 CFR 807.81(a)(3)). FDA's guidance describes a risk-based assessment, confirmed by testing, with changes compared to the most recently cleared device. When no submission is needed, the manufacturer documents the analysis.

Is verification or validation required for a design change under the QMSR?

Clause 7.3.9 requires verification of each change before implementation and validation where appropriate. The old § 820.30(i) read the other way around, as validation or, where appropriate, verification.

Does a PCCP remove the need to document changes?

No. A PCCP can remove the need for a new marketing submission for changes it covers. FDA's guidance still expects the change and its analysis to be documented under the quality system.

Where can I read the clause text?

ISO 13485:2016 is sold by ISO. FDA says the standard can be read free, in read-only form, through the ANSI incorporated-by-reference portal and the ISO Online Browsing Platform. The regulation that incorporates it is 21 CFR Part 820.