Design Controls for Medical Devices: A Practical Design Quality Guide

Design quality is where a medical device is won or lost. Most field failures, audit findings and regulatory deficiencies trace back to requirements that were vague, risks that were never connected to design decisions, or verification and validation that did not prove what they claimed. This guide explains how design controls work in practice under FDA and ISO 13485, and how to build a design file that survives a notified body review or an FDA inspection.

What design controls are and why regulators care

Design controls are a structured, documented way of turning user needs into a safe and effective device. They give you a controlled path from intended use to design inputs, design outputs, verification, validation and transfer to production, with a record at each step. The goal is not paperwork for its own sake. It is evidence that the device you manufacture is the device you intended to design, and that you can show why.

In the United States, design controls were long set out in 21 CFR 820.30. Since the Quality Management System Regulation (QMSR) took effect on 2 February 2026, FDA incorporates ISO 13485:2016 by reference, so the design and development requirements now sit in clause 7.3 of the standard. In the EU, the same expectations flow from MDR Article 10(9) and Annex I, and from the technical documentation in Annex II. The vocabulary changed, but the substance did not: plan, define, build, check, prove, and control change. For the wider FDA picture see our QMSR implementation checklist.

The design control stages, step by step

1. Design and development planning

Write a plan that names the stages, responsibilities, reviews, interfaces between groups and the verification and validation activities. Keep it alive: when scope or risk changes, the plan changes, and the update is recorded.

2. Design inputs

Inputs are the requirements the device must meet: intended use, user needs, performance, safety, regulatory and standards requirements, and risk control measures. Good inputs are specific and testable. “Easy to use” is a wish; “a trained nurse completes set-up in under five minutes without error” is an input.

3. Design outputs

Outputs are drawings, specifications, software, labeling, and manufacturing and inspection instructions. Each output must trace to at least one input, and the set must contain or reference acceptance criteria. Outputs that are essential for safe and proper use must be identified.

4. Design review

Hold formal reviews at planned stages with an independent reviewer who does not have direct responsibility for the stage under review. Record issues, owners and closure.

5. Design verification

Verification confirms that outputs meet inputs: bench testing, inspection, analysis and comparison to a proven design. Use validated methods and justified sample sizes (see our guide to sampling plan generation).

6. Design validation

Validation confirms the device meets user needs and intended use under defined operating conditions, on production-equivalent units. This includes clinical evaluation or performance evaluation where applicable, usability validation under IEC 62366-1, and software validation.

7. Design transfer

Transfer ensures the design is correctly translated into production specifications and that manufacturing can reproduce it reliably. It is the handover into process validation.

8. Design changes and the design file

Every change after the design is released is identified, reviewed, verified or validated as appropriate, approved and recorded before implementation. The design and development file (the old “Design History File”) holds or points to all of the above.

Traceability: the thread auditors pull

Link	What it proves	Typical record
User need to design input	Every need is captured as a requirement	Requirements specification
Design input to design output	Every requirement is implemented	Traceability matrix
Design input to verification	Every requirement is tested against criteria	Verification protocols and reports
Hazard to risk control to verification	Each risk control is implemented and effective	ISO 14971 risk management file
User need to validation	The device works for the intended users and use	Validation and usability reports

Risk management runs alongside every stage. Hazards identified under ISO 14971 become design inputs; risk controls become outputs; verification proves they work. Read our guide to risk management under ISO 14971 for how the two files connect.

Common design quality pitfalls

• Untestable inputs. Requirements with no measurable acceptance criteria cannot be verified.
• Verification and validation confused. Passing bench tests does not show the device meets user needs.
• Risk file kept separate. If hazards never change a design input, the risk file is not driving design.
• Late documentation. Records written after the fact rarely match what was actually done.
• Uncontrolled changes. Small supplier or software changes made without a change assessment are a frequent inspection finding.
• Software treated separately. Software inside a device must also follow a lifecycle such as IEC 62304; see our SaMD training.

How design controls support CE marking and 510(k)

The design file is the source for your submission. For the EU it feeds the Annex II technical documentation (see EU MDR technical documentation). For the US it supplies the performance testing, software and human factors sections of a 510(k) submission. Teams with a clean design file spend far less time answering deficiency questions.

Frequently asked questions

Are design controls required for every medical device?

In the US, design controls historically applied to Class II and III devices and a short list of Class I devices. ISO 13485 clause 7.3 applies to organisations that design and develop devices, and EU manufacturers must meet the General Safety and Performance Requirements for all classes. Check the applicability of your device class with your regulatory lead.

What is the difference between design verification and validation?

Verification asks “did we build the device right?” by confirming outputs meet inputs. Validation asks “did we build the right device?” by confirming it meets user needs and intended use under actual or simulated use conditions.

Is the Design History File still required under QMSR?

The requirement to maintain a record of the design and development is retained through ISO 13485 clause 7.3.10, which describes a design and development file. Many companies keep the DHF name internally.

Do design controls apply to design changes made after launch?

Yes. Changes must be reviewed, verified or validated as appropriate, approved and documented before implementation, and you must assess whether the change needs a new regulatory submission or notification.

Regulatory references change. Confirm clause numbers and effective dates against the current standard and the regulator’s website before relying on them in a submission.

Talk to the AptSkill team

Want hands-on training in design controls, risk management or technical documentation? Send us your role and goal.