Introduction
A medical device that fails in the field rarely fails because of bad luck. It fails because a requirement was never written down clearly, or nobody verified that the finished product actually matched what was designed. That's what design controls exist to prevent.
Design controls now sit at the center of U.S. medical device regulation. As of February 2, 2026, FDA's Quality Management System Regulation (QMSR) fully incorporates ISO 13485:2016 by reference into 21 CFR Part 820. Clause 7.3 is now the legal baseline for design control in the United States.
Many teams still treat design controls as paperwork to complete after the engineering is done. That mindset drives audit findings and recalls. This guide covers what design controls require, the nine stages of Clause 7.3, how to build audit evidence that holds up, and where most teams lose control of the process.
Key Takeaways
- Design controls fall under ISO 13485 Clause 7.3, now the U.S. baseline under FDA's QMSR (effective February 2, 2026)
- The process runs through nine sub-clauses, from planning to the design and development file, each needing documented evidence
- Verification proves you built it right; validation proves you built the right thing
- Most audit findings trace back to team capability gaps, not missing procedures
What Are Design Controls Under ISO 13485?
Design controls are the systematic requirements in Clause 7.3 (Design and Development) that govern how a medical device moves from a stated need to a finished, documented product. They exist to prove, with objective evidence, that the device meets user needs, regulatory requirements, and its intended use.
How QMSR Changed the Rules
Before February 2026, U.S. manufacturers followed the FDA-written 21 CFR 820.30. That text is gone. Current 21 CFR 820.10(c) now requires covered manufacturers to comply directly with ISO 13485 Clause 7.3, eliminating the old divergence between FDA's Quality System Regulation and the ISO standard.
QMSR design control requirements apply to:
- All Class II devices
- All Class III devices
- Specific higher-risk Class I devices, including software-automated devices and non-powdered surgeon's gloves
Why Regulators Care So Much
FDA has long pointed to design failures as a preventable cause of recalls. An FDA analysis found that 44% of voluntary device recalls between 1983 and 1989 may have been prevented by adequate design controls. That figure helped shape the original design control requirement and still explains why this clause draws heavy audit attention.
Risk management under ISO 14971 isn't a side task. It must run through every design control stage (inputs, outputs, verification, validation), not bolted on at the end.
Design controls govern the regulated activities within product development. They don't cover your project budget, timeline, or general engineering management. Those live in your broader development process, outside Clause 7.3's scope.
The 9 Stages of ISO 13485 Design Controls (Clause 7.3)
Each sub-clause below requires a documented procedure and objective evidence that each activity was completed. FDA expects the same rigor under QMSR, with no exceptions for legacy habits.
Design and Development General (7.3.1)
ISO 13485 opens design controls with a general duty: plan and control design and development, and maintain a design and development file. That file holds the records for every stage that follows. Auditors treat it as the spine of their design-control sample.
Design and Development Planning (7.3.2)
The plan is your roadmap, and it has to name specifics:
- Design stages and their sequence
- Required reviews at each stage
- Verification, validation, and transfer activities
- Responsibilities and personnel competence needed
- Traceability methods linking requirements to evidence
Planning starts with risk management under Clause 7.1, not after it. And the plan isn't static. Update it as the project evolves, or your audit trail won't match reality.
User Needs and Design Inputs (7.3.3)
Design inputs must be objective, measurable, unambiguous, and verifiable. This is also where teams distinguish intended use (what the device does) from indications for use (the clinical conditions it treats).
A vague input like "the device shall be lightweight" fails every test above. A precise version — "device mass shall not exceed 450 grams, measured per test method X" — passes all four. Watch for conflicting units of measure between departments; resolving that ambiguity early saves painful rework during verification.
Design Outputs (7.3.4)
Outputs are the specifications, drawings, and documentation that result from the design process. They must:
- Meet the corresponding input requirements
- Include defined acceptance criteria
- Identify safety-critical characteristics
- Be reviewed and approved before release
These outputs form the preliminary Device Master Record — the blueprint manufacturing will eventually build from.
Design Reviews (7.3.5)
Reviews are formal, staged checkpoints — not casual status meetings. They require cross-functional participants and documented decisions, with any follow-up actions tracked to closure.
Reviews typically happen:
- After design inputs are defined
- After design outputs are generated
- After verification
- After validation
- Before design transfer
Design Verification vs. Design Validation (7.3.6 & 7.3.7)
This is where teams most often blur the lines. Verification asks: did outputs meet inputs? Validation asks: does the device meet the user's actual needs and intended use?
| Aspect | Verification | Validation |
|---|---|---|
| Question | Did we build it right? | Did we build the right thing? |
| Compares | Outputs to inputs | Device to user needs |
| Methods | Inspection, testing, analysis | Usability studies, clinical evaluation |
| Performed on | Design specifications | Production-equivalent units |
Both require a documented, pre-approved plan before execution begins, not evidence assembled retroactively to match whatever happened in the lab.
Design Transfer and Design Changes (7.3.8 & 7.3.9)
Design transfer confirms that production can consistently and reliably reproduce the approved design. It converts engineering outputs into finalized manufacturing specifications.
Design changes, once the device is in development or on the market, aren't a quick fix. Every change requires:
- Documented review of the change's significance
- Re-verification or re-validation, as appropriate
- A risk impact assessment
- Formal approval before implementation
Skip any of these steps, and you've created exactly the kind of finding auditors flag most often.
Design History File, DMR, and DHR: Turning Design Controls Into Audit Evidence
Clause 7.3.10 requires a design and development file for each device type: the compiled record proving the device was developed under approved design controls. Most practitioners still call this the Design History File (DHF). The name stays common in industry even though current QMSR no longer defines it as a separate term.
Three records turn design controls into audit evidence:
- Design History File (DHF): compiled proof the device was developed under approved design controls
- Device Master Record (DMR): the manufacturing recipe — specifications, drawings, and procedures
- Device History Record (DHR): proof each individual unit was built to that recipe
FDA retains these functional distinctions under QMSR even though the legal text now runs through ISO 13485's own record structures.
Build the DHF as you go, not after the fact. Teams that leave DHF assembly for the end of development almost always find gaps: missing signatures, outdated versions sitting next to current ones, and approvals nobody can locate.
Paper files and generic tools like shared drives or spreadsheets are especially prone to this. Every review, verification report, and approved change should land in the file the same week it happens.
Why Design Controls Fail in Real Audits (and How to Prevent It)
FDA's own inspection data shows how concentrated these failures are. In one CDRH review of former design control citations, design-related findings made up 14% of all quality system observations — and within that category, design validation and design changes accounted for nearly half of all citations combined.
Four patterns show up again and again:
- Broken traceability: user needs don't connect cleanly to inputs, outputs, verification, and validation. Auditors ask "show me the link," and teams can't.
- Weak design reviews: missing an independent or cross-functional perspective, or lacking documented rationale for the decisions made.
- Unauthorized changes: modifications implemented before risk reassessment or formal approval, sometimes discovered only when the auditor asks for the change log.
- Subjective inputs: requirements written as opinions ("the device should feel durable") instead of measurable, testable specifications.
The root cause behind most of these findings isn't a missing procedure. It's a capability gap. Engineers know the steps exist — they haven't been trained to execute traceability, run a review, or scope a verification protocol under real audit pressure.
That distinction matters. You can rewrite your SOPs a dozen times and still get the same findings if the people executing them haven't practiced doing it correctly.
Prevent the repeat findings by building execution skill, not just documentation:
- Write every design input as a measurable, testable specification—no subjective language
- Require independent or cross-functional voices in every design review, with documented rationale
- Lock change control so no modification ships before risk reassessment and formal approval
- Drill traceability end-to-end until any engineer can show the link from user need to validation on demand
Role-specific practice under audit-like pressure closes the gap procedures alone never will.
Building Audit-Ready Design Control Capability in Your Team
Classroom-style ISO 13485 training has a consistent blind spot: it builds knowledge of what Clause 7.3 says, not the judgment to apply it when an auditor is standing over your shoulder asking why a design input was never verified.
That's the gap QMS Learning built its Medical Device & Life Sciences QMS pathway to close, with pilot cohorts opening in Q3 2026. The pathway bundles four self-paced courses (ISO 13485, FDA 21 CFR Part 820, ISO 14971, and HIPAA) with:
- An AI Workbench trained on ISO 13485:2016, 21 CFR Part 820, ISO 14971, and FDA QSIT technique that drafts DHF entries and risk-management plans
- A Manager Dashboard tracking team competency and compliance metrics against each applicable standard
- An Audit-Evidence Package export combining training records, completed scenarios, and generated documentation into a single file
Founder Will Trikha built the platform after two decades on aerospace audit floors, writing over 1,000 findings and closing twice that number as a quality manager. That background shaped every pathway's premise: teams pass audits through applied practice, not procedures alone.
Organizations interested in the pilot can book a 30-minute demo (Tuesday through Thursday, 10 a.m.–4 p.m. PST) to scope the pathway against their own audit timeline. The first 3–5 buyers get early access at reduced pricing in exchange for design-partner feedback before the curriculum locks.
With full QMSR enforcement already in effect, build traceability-matrix discipline and DHF habits now. Waiting until an audit notice lands leaves too little time to reconstruct evidence.
Frequently Asked Questions
What are design controls in ISO 13485?
Design controls are the structured requirements in Clause 7.3 covering planning, inputs, outputs, review, verification, validation, transfer, and change control. Together, they prove a device was developed systematically rather than informally.
What is the difference between design verification and design validation?
Verification confirms design outputs meet design inputs: you "built it right." Validation confirms the finished device meets user needs and intended use: you "built the right thing." Both require documented, pre-approved plans.
What is a Design History File (DHF) and what does it need to include?
The DHF is the compiled record of a device's design and development activities. It should include the design plan, inputs, outputs, review records, verification and validation evidence, and documentation of any design changes.
How does FDA's QMSR affect ISO 13485 design control requirements?
As of February 2, 2026, QMSR incorporates ISO 13485:2016 directly into 21 CFR Part 820, making Clause 7.3 the U.S. legal baseline for design controls. FDA retains DMR and DHR terminology alongside ISO's design file requirement.
What is the difference between design inputs and design outputs?
Inputs are the measurable, verifiable requirements a device must meet: performance, safety, usability. Outputs are the specifications, drawings, and documentation created to satisfy those inputs and support manufacturing.
How many design reviews does a medical device project need?
There's no fixed number. Reviews should occur at key stage transitions (after inputs, after outputs, after verification, after validation, and before transfer), with cross-functional participants and documented outcomes each time.
