Design Controls are a formal, documented set of practices that medical device manufacturers use to plan, develop, verify, validate, and transfer a device design while creating objective evidence that the design meets user needs and intended uses. They are required under FDA 21 CFR Part 820.30 and ISO 13485 Clause 7.3.
What is Design Controls?
Design Controls are the structured process a manufacturer follows to turn user needs and intended uses into a verified, validated device design, with documented evidence at every step. The process applies across most Class II and Class III devices, and some Class I devices, throughout the design and development phase of the product lifecycle.
The core idea is traceability. Every user needs maps to a design input, every input maps to a design output, and every output is checked by verification and validation. Regulators and notified bodies can follow that chain from a single requirement to the test that proves it was met.
Why Design Controls matter in medical device development
Design Controls exist because design flaws, not manufacturing defects, cause a large share of device recalls. A missed requirement or an unverified output can reach a patient. Catching it in design is cheap; catching it after launch means field actions, recalls, and warning letters.
Regulatory exposure is direct. FDA investigators and EU notified bodies open design reviews by pulling the Design History File (DHF). Gaps in traceability or missing verification records are among the most common audit findings. A weak DHF can stall a 510(k) clearance or a CE marking submission for months.
Rework late in development is expensive and slows time to market. Disciplined Design Controls front-load the hard questions, so problems surface while they are still cheap to fix.
How the Design Controls process works
FDA 21 CFR Part 820.30 and ISO 13485 Clause 7.3 define the same elements. The process is iterative, not linear, but it centers on these stages:
- Design and development planning. Document who does what, the phases, and the review points before work starts.
- Design inputs. Translate user needs into specific, measurable, verifiable requirements covering function, performance, safety, and regulatory criteria.
- Design outputs. Produce the drawings, specifications, software, and acceptance criteria that define the finished device and feed manufacturing.
- Design review. Hold formal, documented reviews at planned stages, with an independent reviewer who has no direct responsibility for the stage under review.
- Design verification. Confirm outputs meet inputs through testing, inspection, or analysis. This is “Did we build the device right?”
- Design validation. Confirm the device meets user needs and intended uses under actual or simulated use conditions, usually on production-equivalent units. This is “did we build the right device?”
- Design transfer. Convert the design into production specifications that manufacturing can build to repeatably.
- Design changes. Control, review, and approve every change, with revalidation where the change warrants it.
Two adjacent standards run alongside the process. Risk management under ISO 14971 feeds hazards and risk controls into design inputs. Usability engineering under IEC 62366-1 ties use-related risks to validation. For software, IEC 62304 governs the software development lifecycle within the same framework. It all lands in the Design History File, the record proving the design was developed to plan.
Common challenges and best practices
The most frequent failure is poor traceability. Teams write inputs and outputs in separate documents that drift apart, then scramble to build a trace matrix before an audit. Maintain the matrix live, from day one.
Vague design inputs cause downstream pain. “Easy to use” is not verifiable. “Single-handed activation with under 5 N of force” is. Write inputs a test engineer can act on.
Confusing verification with validation is common. Verification checks outputs against inputs. Validation checks the device against real user needs. Both are required, and they answer different questions.
Treating Design Controls as paperwork done at the end defeats the purpose. The records should be a byproduct of real engineering work, generated as it happens, not reconstructed later. Good teams keep design reviews honest, with a genuine independent reviewer rather than a rubber stamp.
How SJML helps with Design Controls
SJML runs medical device design and development as an end-to-end CDMO, so Design Controls are part of how programs are structured rather than an afterthought. Teams cover mechanical, electronics, embedded, and software engineering, with risk management to ISO 14971 and usability engineering to IEC 62366 built into the workflow. Phase-gate program management with formal change control maps to the design review and design change requirements, and in-house labs handle verification testing for electrical safety, EMC, and reliability. Design transfer connects engineering to manufacturing under one roof.
Talk to SJML’s engineering team →
Frequently asked questions
No. Design Controls apply to most Class II and Class III devices and to a specific subset of Class I devices listed in FDA 21 CFR Part 820.30(a). Many basic Class I devices are exempt from design control requirements. Under ISO 13485, design and development controls apply wherever a manufacturer designs a product.
Verification confirms that design outputs meet design inputs, answering whether the device was built correctly against its specifications. Validation confirms the finished device meets user needs and intended uses under real or simulated conditions, answering whether the right device was built. Verification often uses testing or analysis; validation typically uses production-equivalent units with representative users.
A Design History File (DHF) is the compiled record showing a device was developed according to its design plan and the design control requirements. It typically holds the design plan, design inputs and outputs, verification and validation records, design review minutes, the traceability matrix, and design change records. Auditors use it to confirm that the design process was followed.
Design Controls begin once a project moves past pure research into formal design and development, when design inputs are being defined. Starting early avoids costly rework. Feasibility and concept exploration can precede formal controls, but the planning stage should be in place before design inputs are locked.
Related terms
- Design Verification
- Design Validation
- Design History File (DHF)
- Design Inputs and Outputs
- Risk Management (ISO 14971)
