Medical device design controls are the documented procedures a manufacturer uses to turn user needs into a device design, then prove that design is safe and works as intended. Since February 2, 2026, FDA enforces them through the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 clause 7.3, design and development, by reference in place of the old 21 CFR 820.30.
In short:
- The stages did not change much: planning, inputs, outputs, review, verification, validation, transfer, changes and a design file. The citation numbers did.
- In Atlas's directory of 389 device Form 483s issued from January 7 to July 17, 2026, 108 (28%) cite design controls. Every one issued after February 2 cites ISO 13485 clause 7.3, not 820.30.
- Design change control (clause 7.3.9) is the single most cited design clause, on 33 of the 94 Form 483s that cite clause 7.3.
- Risk management under ISO 14971 now runs through every stage. Clause 7.1 appears on 28% of 2026 device Form 483s in the same sample.

Who must follow design controls under the QMSR
The QMSR keeps the old scope. Section 820.10(c) applies design and development requirements to all Class II and Class III devices and to a short list of Class I devices, including any device automated with computer software. FDA's QMSR page also states that devices made under an investigational device exemption are not exempt from these requirements.
What changed is the source text. The QMSR incorporates ISO 13485:2016 by reference, so the design requirements now live in clause 7.3 and its ten sub-clauses. The term design history file (DHF) is gone from the regulation. ISO 13485 calls the same body of evidence the design and development file (clause 7.3.10). Where an ISO clause conflicts with the FD&C Act or FDA regulations, the US requirement controls. For the wider list of 2026 device rule changes, see our summary of the latest FDA regulations impacting medical device manufacturers.
The design control stages: 21 CFR 820.30 mapped to ISO 13485 clause 7.3
If your procedures still cite 820.30, the fastest fix is a crosswalk. The counts in the last column come from the Atlas sample described below and count each Form 483 once per stage.
| Stage | Old QSR paragraph | ISO 13485:2016 clause | 2026 device 483s citing it |
|---|---|---|---|
| Procedures and general | 820.30(a) | 7.3.1 General | 18 |
| Planning | 820.30(b) | 7.3.2 Planning | 4 |
| Design inputs | 820.30(c) | 7.3.3 Inputs | 9 |
| Design outputs | 820.30(d) | 7.3.4 Outputs | 5 |
| Design review | 820.30(e) | 7.3.5 Review | 4 |
| Design verification | 820.30(f) | 7.3.6 Verification | 9 |
| Design validation | 820.30(g) | 7.3.7 Validation | 23 |
| Design transfer | 820.30(h) | 7.3.8 Transfer | 6 |
| Design changes | 820.30(i) | 7.3.9 Control of changes | 37 |
| Design history file | 820.30(j) | 7.3.10 Design and development files | 17 |
A few clause-level differences matter in practice:
- Planning (7.3.2) asks for the methods that ensure traceability of outputs to inputs and for the resources and competence needed. Many teams already did this; now it is written requirement text.
- Inputs (7.3.3) must include outputs of risk management and applicable regulatory requirements, and must be reviewed for adequacy, completeness and freedom from conflict.
- Validation (7.3.7) must be done on representative product, defined as initial production units, batches or their equivalents, and must include clinical or performance evaluation as required.
- Changes (7.3.9) require you to determine the significance of each change and evaluate its effect on constituent parts, product already delivered, and risk management inputs and outputs.
What Atlas data shows about 2026 design control findings
We pulled every Form 483 in the Atlas Form 483 directory tagged Medical Devices & Rad Health with a 2026 issue date (data release of August 15, 2026; 389 forms issued January 7 to July 17, 2026) and read the cited regulation on every observation. The switch to the QMSR is visible in the data on the day it happened.
| Period | Device 483s | Cite ISO 13485 | Cite design controls | Citation used for design |
|---|---|---|---|---|
| Jan 7 to Feb 1, 2026 | 40 | 0 | 14 (35%) | 21 CFR 820.30 only |
| Feb 2 to Jul 17, 2026 | 349 | 319 (91%) | 94 (27%) | ISO 13485 7.3.x only |
| All 2026 to date | 389 | 319 (82%) | 108 (28%) |
That 91% matches what we published from a smaller window: in 96 device Form 483s from May to July 2026, 91 cited ISO 13485 and only 4 cited the old Part 820. Among ISO clause families, clause 7.3 appears on 94 Form 483s, level with 7.5 production and service provision and behind 8.2 feedback and complaints (117), 7.1 risk-based product realization (109), 8.5 improvement (98) and 4.1 general QMS requirements (95).
Within clause 7.3, the order surprises teams that expect validation to lead:
- 7.3.9 design changes: 33 Form 483s (35% of the 94)
- 7.3.10 design and development files: 17
- 7.3.7 validation: 16
- 7.3.1 procedures: 15
- 7.3.3 inputs: 9
- 7.3.6 verification: 7
Before February 2, the 14 Form 483s citing 820.30 leaned the other way: 7 cited 820.30(g) validation, and 5 of those described the risk analysis as missing or inadequate. Under the QMSR the same gap tends to be written against clause 7.1 or 7.3.7, which is why risk files deserve as much attention as test reports. Design control problems also travel together: 21 of the 108 forms cite two or more design stages, and 30 also cite clause 7.1.
Four indexable examples from the Form 483s directory show the pattern:
- Fresenius Medical Care Renal Therapies Group, June 3, 2026: verification plans not documented (7.3.6) and validation not complete before product release (7.3.7).
- LeMaitre Vascular, June 25, 2026: design inputs do not include all requirements (7.3.3).
- Klarity Medical Products, May 20, 2026: records of design changes and their reviews not maintained (7.3.9).
- National Dentex, April 6, 2026: design and development files not maintained (7.3.10).
Regionally, design controls are tagged 303 times in North American device findings on our region-wise top issues dashboard.
See what the FDA knows about your next investigator.
30 minutes with the founder. No pitch deck.
Verification vs validation
The two are easy to blur in a test report, and investigators notice.
| Design verification (7.3.6) | Design validation (7.3.7) | |
|---|---|---|
| Question it answers | Did we build the design right? | Did we build the right device? |
| Compared against | Design inputs | User needs and intended use |
| Typical methods | Bench tests, inspections, analysis, software unit and integration tests | Clinical or performance evaluation, usability testing, simulated use |
| Product tested | Prototypes or production-equivalent parts | Representative product: initial production units, batches or equivalents |
| Common 2026 finding | Verification not performed, or plans not documented | Validation not complete before release, or not done as planned |
Two practical points. Record the rationale for the product you validated on and why it represents production. And if your device connects to other devices, verification must show inputs are met when connected; one 2026 Form 483 cited inadequate verification for an interfaced device.
How risk management ties into design controls
ISO 13485 clause 7.1 requires documented risk management across product realization, and most manufacturers meet it with ISO 14971, which FDA recognizes as a consensus standard. In the design stages the link is concrete:
- Hazard analysis and risk controls become design inputs (7.3.3).
- Risk control measures are verified, and their effectiveness confirmed, during verification and validation.
- Every design change is assessed for its effect on the risk file (7.3.9).
- Residual risk and the benefit-risk conclusion are reviewed before transfer.
Clause 7.1 was cited on 109 of the 389 device Form 483s in our sample (28%), close to the 31% we reported for May to July on most prevalent ISO clauses by industry. Corrective and preventive action, clause 8.5.2, sat at 28% in that same window. If your CAPA process feeds design changes, our corrective and preventive action guide covers the hand-off. The drug-side equivalent of this thinking is ICH Q9, covered in our quality risk management post.
What investigators ask for under Compliance Program 7382.850
On February 2, 2026, FDA stopped using the Quality System Inspection Technique (QSIT) for device inspections and moved to Compliance Program 7382.850, Inspection of Medical Device Manufacturers. The program organizes coverage into six QMS areas: Management Oversight, Design and Development, Change Control, Outsourcing and Purchasing, Production and Service Provision, and Measurement, Analysis and Improvement. Investigators choose elements within those areas based on product risk rather than walking a fixed subsystem order. Our earlier post on a QSIT inspection describes the approach that was retired.
For design, expect requests like these:
- the design and development procedure and a list of design projects, often filtered to the highest-risk product or recent complaints
- the design plan with its traceability method for one selected project
- the traceability matrix from user needs to inputs, outputs, verification and validation
- the risk management file for the same product, and how risk outputs became inputs
- design review minutes, with attendees and an independent reviewer
- validation reports with the definition of representative product
- transfer records showing outputs became production specifications
- the change log since launch, with significance and risk assessments for each change
Because Change Control is its own QMS area, a weak change record can surface twice, once in design and once in production. Our post on mock FDA inspections shows how to rehearse this flow.
Common design control findings in 2026
Grouping the observation wording across the 108 forms, five patterns account for most citations:
- Changes made without the required review. Wording such as "requirements for design and development changes not met before implementation" and "significance of changes not determined."
- Missing or incomplete design files. The file exists in pieces across drives and cannot be produced as one record.
- Validation done late or on the wrong units. Validation not complete before release, or not done on representative product.
- No written procedure at all. Common at small firms and contract manufacturers that took on design work.
- Inputs that leave out requirements. Regulatory, usability or risk inputs missing, so later verification has nothing to test against.
Design and development file checklist
Use this to check one project end to end. Each item should be retrievable within minutes.
- Design and development plan, with stages, responsibilities, reviews and traceability method, kept current
- Design inputs: functional, performance, usability, safety, regulatory and risk management outputs, reviewed and approved
- Design outputs: drawings, specifications, software, labeling and acceptance criteria, approved before release
- Design review records for each planned stage, with participants and decisions
- Verification plans, protocols, results and conclusions, with records of any actions taken
- Validation plans and results on representative product, including clinical or performance evaluation and usability
- Risk management file under ISO 14971, linked to inputs and verification
- Transfer records showing outputs are suitable for production
- Change records with significance, impact, verification or validation, risk review and approval
- A traceability matrix tying every user need to its proof
FDA Inspection Intelligence Digest
We track every 483, EIR, and warning letter the moment it happens. Get the signals before they hit the FDA website.
Frequently asked questions
No. When the QMSR took effect on February 2, 2026, the old section 820.30 no longer governs design, and design requirements come from ISO 13485:2016 clause 7.3, which Part 820 incorporates by reference. Older Form 483s and warning letters still cite 820.30 because they were issued under the previous Quality System Regulation, but new inspections use the ISO clause numbers.

Written by
Bhavish Agarwal
Founder, Atlas
Bhavish Agarwal is the founder of Atlas and previously worked at Google and Microsoft. He has spent the past several years building regulatory data infrastructure for the pharmaceutical industry.

