Written and maintained by CASRAI Editorial Board
Last updated
Design controls are the staged, documented process a manufacturer runs to turn a device concept into a verified, validated design that can be transferred to production — not a document, a single form, or a folder of records. The record set the process produces is the design history file (DHF); the process itself is what an auditor or an FDA investigator actually walks through. This page covers the process itself, subclause by subclause, and where each step’s evidence lands in the DHF.
Where 21 CFR 820.30 stands today
Most people arrive at “design controls” still thinking in terms of 21 CFR 820.30 — the section that introduced design controls to U.S. device regulation in 1996, under the Safe Medical Devices Act, effective 1 June 1997. That section number is still the term of art, but as of 2 February 2026 it is no longer operative regulatory text: FDA’s Quality Management System Regulation (QMSR) replaced the old Quality System Regulation, and 820.30 now reads [Reserved]. The requirement did not disappear — it moved. The QMSR incorporates ISO 13485:2016 by reference, and Clause 7.3, Design and development, is where the requirement now lives, applied to the device classes the QMSR scopes it to under 820.10(c). For the full subpart-by-subpart mapping of what moved where, see CASRAI’s guide to 21 CFR Part 820: subpart-by-subpart map and QMSR transition status.
Practically, this matters less than it sounds like it should. The nine-step process below is essentially the same sequence under both citations — ISO 13485:2016 Clause 7.3 was already the international reference most multinational device makers built their design control procedures against, long before the QMSR made it the U.S. citation too. The subclause letters below are the legacy 820.30(a)–(j) structure, because that is still how most quality manuals, SOPs, and training materials are organized, and because it maps cleanly onto Clause 7.3’s own subclauses.
The design control process, step by step
Design controls are not nine independent checkboxes. Each step consumes the output of the one before it and produces a specific, traceable artefact that becomes part of the DHF. A design control system without traceability between these steps — an input nobody verified, an output that traces to no requirement — is the single most common finding auditors and FDA investigators write up.
Design and development planning (820.30(a)–(b))
Before any input is written, the plan defines the design and development activities, who is responsible for each, how activities interface across departments, and how the plan itself gets updated as the project evolves. The plan is reviewed and approved before design work starts, and re-approved when scope, resourcing, or interfaces change materially. This is the document that later tells an auditor what the process was supposed to look like, against which everything else gets checked.
Design input (820.30(c))
Design inputs are the physical and performance characteristics a device must have — drawn from the intended use, the needs of the user and patient, and applicable regulatory requirements. Each input must be documented, reviewed for adequacy, and resolved for ambiguity before it becomes a requirement the design is measured against. The single most common design-control failure mode starts here: an input written in language that cannot actually be verified — “the device shall be reliable,” “the interface shall be intuitive” — with no measurable acceptance criterion behind it. If a requirement can’t be tested against, it can’t be verified in the next step, and the traceability chain breaks at the very first link.
What separates a testable input from a vague user need is not polish, it’s structure: a testable design input names the characteristic, states a measurable value or range, specifies the condition or method under which it’s measured, and states pass/fail criteria — the same four elements a verification protocol needs to exist at all. “The device shall be reliable” names no characteristic and no measurement. “The device shall operate for a minimum of 500 duty cycles at 23°C ±2°C without failure, per test method X” names one. A genuinely testable input can be traced forward to exactly one verification (or validation, for a user-need-level input) activity that will produce a pass/fail result — if two engineers reading the same input line would disagree about whether a finished device meets it, the input isn’t finished yet, no matter how official-looking the document it lives in is. The same testability discipline applies one level up, when the requirement originates from a purchaser rather than an internal design team — see CASRAI’s guide to the user requirements specification (URS) for the equivalent testability standard applied to procured GxP systems.
Design output (820.30(d))
Design outputs are the specifications, drawings, and other results of the design effort that let the device actually be produced and that can be checked against the inputs that generated them. Outputs must be documented in a form that allows an adequate evaluation of conformance to input requirements, must identify characteristics essential to safe and proper use (labelling, sterility claims, packaging), and must be reviewed before release. A common gap: outputs exist as engineering drawings and specs, but no document maps each output back to the specific input it satisfies — which is exactly the traceability matrix the next several steps depend on.
Not every drawing or spec an engineer produces is a design output in the 820.30(d) sense — a work-in-progress sketch, an unreviewed CAD file, or a specification still marked “draft” is engineering work product, not a controlled design output, until it has gone through the review and release step the regulation requires. What converts a draft artifact into a genuine design output is release under document control: a defined revision, a documented review against the inputs it’s meant to satisfy, and formal approval before it’s used downstream (by manufacturing, by a verification protocol author, or by another design team). A specification an auditor finds still sitting in an engineer’s local folder, unreleased and unreviewed, months after downstream teams have started building against it, is a design-control finding — not because the content was wrong, but because the artifact was never actually promoted to a controlled output.
Traceability: the link between inputs and outputs
The mechanism that connects design inputs to design outputs — and, later, to verification and validation records — is the requirements traceability matrix (RTM, sometimes called a design traceability matrix). Each row typically maps one design input to the output(s) that implement it, the verification activity that confirms the output meets the input, and, where applicable, the validation or risk-control record it supports. An RTM built as the design work happens is a working document that tells the team what’s still open; an RTM assembled after the fact, at submission or audit time, is a reconstruction exercise — and reconstruction is also where gaps first become visible: an input with no output that traces to it, an output with no input behind it (scope creep, or an input that was silently dropped), or a verification record that doesn’t cite the specific input it was meant to test. Auditors and FDA investigators read the RTM as evidence that the design was actually controlled, not just that a folder of documents exists — a design history file with strong individual documents but no traceability matrix tying them together is a materially weaker DHF than one with a thin RTM linking everything. See CASRAI’s guide to the design history file for what belongs in that record set.
Design review (820.30(e))
Formal, documented reviews of the design results happen at appropriate stages of development, with participants including a representative of each function concerned with the stage being reviewed and an individual who does not have direct responsibility for the design stage under review — independence is a specific, checked requirement, not a nice-to-have. Each review is documented in the DHF, including the participants, the date, and the design reviewed.
Design verification (820.30(f))
Verification confirms that design output meets design input requirements — the “did we build it right” question, answered by testing, inspection, analysis, or comparison to a proven similar design, against acceptance criteria fixed before the verification activity runs. The verification results, including the identification of the design, method, date, and the individuals performing it, go into the DHF.
Design validation (820.30(g))
Validation confirms that the device meets defined user needs and intended uses — the “did we build the right thing” question — performed on initial production units, lots, or batches, or their equivalents, under actual or simulated use conditions. Validation includes software validation and risk analysis where applicable, and, for most devices, clinical evaluation under actual or simulated use conditions. Verification and validation are frequently conflated in casual usage; they are legally and practically distinct steps that answer different questions against different baselines — inputs for verification, actual user needs for validation.
Design transfer (820.30(h))
Design transfer ensures the device design is correctly translated into production specifications — the point where a verified, validated design becomes a manufacturable one. This is where process validation, first-article inspection, and pilot or production-representative builds connect design control to the quality system’s production and process controls; a design that was never formally transferred, with production still running from engineering-stage drawings, is a design-control gap even if the earlier steps were done well.
Design changes (820.30(i))
Every design change — before and after the design is transferred to production — must be identified, documented, validated or verified as appropriate, and reviewed and approved before implementation, using the same rigor as the original design controls. This is the second failure mode FDA investigators cite most often alongside unverifiable inputs: changes made through informal engineering channels — a revised drawing issued without a documented change order, a software patch pushed without re-verification — that never go through the design change control the regulation requires. A change control system for manufacturing that doesn’t also reach back into design change control leaves exactly this gap.
The design history file (820.30(j))
The DHF is defined as the compilation of records that describes the design history of a finished device — it is the process’s output, not a separate deliverable written after the fact. Every artefact described above (the plan, the input and output specifications, review minutes, verification protocols and reports, validation evidence, the transfer record, change orders) either lives in the DHF or is referenced from it. Reconstructing a DHF retroactively, once a device is already near a regulatory submission, is materially more expensive than maintaining the file as the design work happens — the DHF should be a byproduct of doing design controls correctly, not a project of its own. The DHF is distinct from the device master record (DMR, the current build specification) and the device history record (DHR, the record that a specific unit or batch was built to the DMR) — the DHF proves the design was controlled; the DMR and DHR prove production conformed to it.
Where design controls connects to risk, usability, and software
Design controls does not run in isolation from the rest of the quality system. Risk management under ISO 14971 runs in parallel with design controls from the planning stage forward — risk control measures become design inputs, and residual risk evaluation depends on verification and validation evidence. Where a device has a user interface, human factors and usability evidence under IEC 62366-1 and FDA’s human factors guidance sits inside design validation, and use-related risk analysis feeds design inputs the same way clinical risk analysis does. For software-driven devices, IEC 62304‘s safety classification determines how much software-specific verification and lifecycle documentation design controls has to carry.
Scope: which devices this applies to
Under the legacy structure, design controls applied to all Class II and Class III device manufacturers, plus a defined set of Class I devices. Under the QMSR, the device classes design controls applies to are scoped by 820.10(c) rather than restated in a design-controls-specific section — see the 21 CFR Part 820 guide for the current class-by-class scope, since that page tracks the regulation’s exact current text rather than this page repeating it and risking drift as the QMSR transition settles.
Frequently asked questions
Is 21 CFR 820.30 still legally in effect?
No, not as standalone regulatory text. As of 2 February 2026, 820.30 reads [Reserved]; the requirement it used to state now applies through the QMSR’s incorporation by reference of ISO 13485:2016 Clause 7.3. The subclause structure and the practical requirements are essentially unchanged — only the citation moved.
What’s the real difference between design verification and design validation?
Verification checks design output against design input — did the design meet its own written requirements. Validation checks the finished device against user needs and intended use, under actual or simulated conditions — did the design solve the right problem. A device can pass every verification test against poorly written inputs and still fail validation because the inputs never captured what users actually needed.
Does design controls apply to a research-stage prototype that isn’t commercialized yet?
Not as a regulatory obligation — design controls attach to devices intended for commercial distribution, at the classes described above. In practice, research teams that expect a prototype to eventually move toward a regulatory submission benefit from starting DHF discipline early: version-controlled requirements, documented reviews, and traceable verification and validation records are far cheaper to build as the work happens than to reconstruct later.
What is the design history file, and how is it different from the device master record?
The DHF documents that the design was developed under control — the plan, inputs, outputs, reviews, verification, validation, transfer, and changes. The device master record (DMR) is the current specification a device is actually built to in production. The DHF answers “was this design controlled correctly”; the DMR answers “what does production build today.”
What are the most common design-control findings in an FDA inspection or an ISO 13485 audit?
Two patterns recur most: design inputs written in language that cannot be objectively verified (no measurable acceptance criterion), which breaks traceability from the first step; and design changes — especially post-transfer engineering or software changes — made through informal channels instead of the same documented, reviewed, approved change control the original design controls required.
What makes a design input testable instead of just documented?
A testable design input names a specific characteristic, states a measurable value or range for it, specifies how and under what conditions it’s measured, and states pass/fail criteria — enough for two people to independently agree whether a finished device meets it. A documented but untestable input (“the device shall be reliable,” “the interface shall be intuitive”) satisfies the letter of “written down” but not the actual regulatory intent, because nothing downstream can verify against it.
What’s the difference between a design output and a draft engineering artifact?
A draft artifact — an unreviewed drawing, a specification still marked “draft,” a work-in-progress CAD file — becomes a design output only once it has been reviewed against the inputs it’s meant to satisfy and formally released under document control. Using an unreleased draft as if it were a controlled output (for example, building or testing against it) is a common, citable design-control gap even when the underlying engineering content turns out to be correct.
See also CASRAI’s guides to ISO 13485 medical device quality management systems for the clause-by-clause QMS context design controls sits inside, and the Laboratory Compliance & Quality pillar for the wider compliance cluster.
