Design Controls
For a medical device, the design *is* the product in a way it rarely is for a drug — and design controls are the formal, traceable process that proves the design is correct before it ships. They run from design inputs (what the device must do and be safe for) through design outputs, verification, validation, and design transfer to production, with the whole chain captured and linked so any requirement can be traced to the evidence that it was met. Inadequate design controls are among the most-cited device inspection findings, because a defect built into the design propagates into every unit made. This page is the anatomy of that process; the wider device quality system it lives in — ISO 13485, the QMSR, risk management, software — is the subject of the [Medical Device Quality System](/topics/medical-device-quality) explainer.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 23 LINKSFor a device the design is the product: design controls trace inputs through verification, validation, and transfer across the quality-system and engineering disciplines as the QMSR folds 21 CFR 820.30 into ISO 13485 section 7.3.
06 · QUALITY MATURITY — DESIGN CONTROLS, REACTIVE TO ADAPTIVE
The design history is reconstructed on request; verification is treated as if it satisfied validation, and inputs are vague ('easy to use').
Design inputs, outputs, verification, and validation are proceduralized, but the risk file is assembled at the end rather than driving the design.
A traceability matrix links each input to its output, verification, and validation; ISO 14971 risk analysis feeds the inputs; review gates each stage.
Human-factors and post-market data re-enter the risk file and design; validation proves the finished device in actual use before regulators ask.
One harmonized ISO 13485/QMSR design process; risk knowledge steers inputs, software lifecycle, and transfer so production matches what was proven.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 3
Derived from the 3 standards SPEQ maps to this subject, across 2 regulatory bodies: FDA, ISO.
RECORDS & OBJECTIVE EVIDENCE
- A Design History File tracing inputs to outputs, verification, and validation
- A design traceability matrix with no dropped input and no orphan output
- Design validation under actual or simulated use by intended users (human factors)
- ISO 14971 risk management file feeding design inputs across the lifecycle
- Design-transfer records showing production specs reproduce the validated design
COMMON INSPECTION FINDINGS
- Design validation not performed under actual or simulated conditions of use
- Verification passed and treated as if validation were complete
- Design inputs vague or unverifiable, so outputs cannot be objectively tested
- Risk file assembled at the end rather than driving the design
- DHF, DMR, and DHR confused, or the DHF incomplete on request
Why devices have design controls and drugs largely do not
The distinctive discipline of device quality is that the requirement is to control the *design itself*, not just its manufacture. A pharmaceutical product is defined largely by its formulation and process; a device is defined by a design that must correctly translate a clinical need into physical form, and a design error — a mis-specified alarm threshold, an unvalidated use assumption — becomes a systematic hazard replicated across every unit. Design controls exist to catch those errors before production, which is why the process is front-loaded: the effort goes into getting the requirements and the verification right, not into inspecting defects out at the end.
The framework is a chain of linked stages. **Design inputs** capture what the device must do, its performance, safety, and regulatory requirements, and its intended use and users. **Design outputs** are the specifications, drawings, and code that result — the tangible form of the design. **Verification** confirms outputs meet inputs; **validation** confirms the finished device meets user needs in actual use; **design review** provides formal, independent checkpoints at defined stages; and **design transfer** translates the validated design into production specifications so what is manufactured is what was designed. The entire chain is documented in the **Design History File (DHF)** — the record that the design was developed under control.
Verification vs. validation — the distinction that is constantly blurred
The single most important — and most frequently confused — pair in design controls is verification versus validation. **Verification asks "did we build the device right?"** — do the design outputs meet the design inputs? It is an internal, specification-against-specification check: the housing meets the dimensional spec, the software function returns the specified value, the tensile strength exceeds the required minimum. **Validation asks "did we build the right device?"** — does the finished product, under actual or simulated conditions of use and by the intended users, meet the user needs and intended uses? A device can pass every verification test and still fail validation because the requirements themselves were wrong, or because real users cannot operate it safely.
The classic worked example is a home-use device that meets every engineering specification (verification passes) but that elderly patients cannot read or actuate under real conditions (validation fails). This is also why **human-factors / usability** work sits inside validation for devices: the question is not whether the device performs to spec but whether it performs safely in the hands it was designed for. Treating verification as if it satisfied validation — "all our specs passed, so the design is validated" — is a genuine and dangerous conflation, because it declares the design proven while the "did we build the right thing?" question remains unanswered.
Design inputs and traceability — where design-control findings actually originate
The root of most serious design-control failures is not a missed test late in the process but a weak design input at the start. Vague, incomplete, or unverifiable inputs ("the device shall be easy to use," "the battery shall last a long time") cannot be objectively verified or validated, so everything built on them is unprovable. Good inputs are complete, unambiguous, and stated so that a later test can unambiguously pass or fail against them — and where a requirement derives from a hazard, the risk analysis is what feeds it, tying ISO 14971 risk management directly into the input set rather than running alongside it.
What holds the process together is **traceability** — typically a design traceability matrix that links every design input to the output that addresses it, the verification that confirms it, and the validation that closes it. The matrix is what lets a reviewer (or an inspector) confirm that no requirement was dropped and no output exists without a requirement behind it. Its natural endpoint is **design transfer**: the deliberate, verified hand-off of the design into manufacturing, ensuring production specifications faithfully reproduce the validated design. A design that is validated but poorly transferred produces units that do not match what was proven — the gap where an excellent design still yields a defective product.
The QMSR transition: 21 CFR 820.30 folds into ISO 13485 §7.3
Design controls are entering a period of terminology change worth understanding, because the concepts are stable even as the words shift. Historically US design controls lived in **21 CFR 820.30** while the international world used **ISO 13485 §7.3 (design and development)** — two expressions of the same discipline. The FDA’s Quality Management System Regulation (QMSR), which incorporates ISO 13485 by reference and takes effect in **February 2026**, largely converges them: the standalone 820.30 design-controls language gives way to the ISO 13485 design-and-development requirements, with FDA-specific expectations layered on top. Manufacturers already running an ISO 13485 design process will find the substance familiar; the change is primarily one of framework and vocabulary, not of what design control fundamentally requires.
One durable point to keep straight through the transition is the family of device records design controls touch, which are routinely confused: the **DHF (Design History File)** documents how the design was developed; the **DMR (Device Master Record)**, becoming the "device master file" concept under the harmonised framework, is the recipe for building the device; and the **DHR (Device History Record)** is the evidence that a specific batch was built to that recipe. Design controls populate the DHF and feed the DMR at design transfer — and knowing which record answers which question is part of demonstrating a design process that is actually under control rather than merely documented.
FREQUENTLY ASKED
What are design controls?
A formal, traceable process that proves a medical device design is correct before it is built: design inputs (requirements), design outputs (specifications), verification (outputs meet inputs), validation (the device meets user needs in use), design review at defined checkpoints, and design transfer to production — all documented in the Design History File. They are distinctive to devices because for a device the design itself is what must be controlled, not just its manufacture.
What is the difference between design verification and design validation?
Verification asks "did we build the device right?" — do the design outputs meet the design inputs (spec against spec)? Validation asks "did we build the right device?" — does the finished product meet user needs and intended uses under actual or simulated use by the intended users? A device can pass every verification test and still fail validation because the requirements were wrong or real users cannot operate it safely, which is why human-factors work sits inside validation.
Why do most design-control findings trace back to design inputs?
Because vague, incomplete, or unverifiable inputs ("easy to use," "long battery life") cannot be objectively verified or validated, so everything built on them is unprovable. Good inputs are complete, unambiguous, and testable, and where a requirement derives from a hazard it is fed by the ISO 14971 risk analysis. A design traceability matrix then links each input to its output, verification, and validation so nothing is dropped.
How does the FDA QMSR change design controls?
The QMSR incorporates ISO 13485 by reference and takes effect in February 2026, largely converging the US design-controls language of 21 CFR 820.30 with ISO 13485 §7.3 (design and development). The concepts are stable — inputs, outputs, verification, validation, review, transfer — so the change is primarily one of framework and vocabulary, with FDA-specific expectations layered on top. Manufacturers already running an ISO 13485 design process will find the substance familiar.