21 CFR 820.30 · ISO 13485 · FDA QMSR
Design Controls
& the Design History File
Proof That Your Device Was
Designed, Not Just Built
Proof That Your Device Was
Designed, Not Just Built
Design controls are the discipline that proves a medical device was developed deliberately: that real user needs became defined inputs, that the design met those inputs, and that the finished device does what patients and clinicians actually require. They are mandated by 21 CFR 820.30 and ISO 13485, and — as FDA harmonizes its Quality System Regulation into the Quality Management System Regulation (QMSR) — they sit at the center of a device's regulatory record.
Design controls are not a phase you pass through and leave behind. They are a linked set of requirements that run from concept to production transfer, with formal reviews and records at every stage.
Requirements derived from user needs and intended use, written so they can be objectively verified.
The specifications, drawings, and code that must meet the inputs and define the finished device.
Formal reviews at defined stages, with independent reviewers who can catch what the team cannot.
Objective evidence — tested and measured — that the outputs meet the inputs.
Evidence that the device meets user needs in actual or simulated use, on production-equivalent units.
Translating the validated design into production specifications that hold on the line.
Reviewers see these two conflated more than any other design-control error. Verification asks whether you built the device right — outputs meet inputs. Validation asks whether you built the right device — it meets the user's real need. Confuse them and you produce a design record that looks complete and proves nothing.
Outputs meet inputs — tested, measured, and objective.
The device meets user needs in real or simulated use, on production-equivalent units.
Every input traces to an output, a verification, and a validation — the thread an auditor follows end to end.
The Design History File is the compiled record demonstrating that a device was developed under design controls. Assembled as you go — not reconstructed at the end — it is the first thing an auditor opens and the fastest way a program's discipline is judged.
The plan defining stages, responsibilities, and reviews, in place before development work starts.
Requirements and the specifications that meet them, captured as they are set, not after.
Verification and validation results tied back to the specific inputs they satisfy.
The living map linking user needs, inputs, outputs, and V&V across the whole program.
The reviewed handoff into manufacturing, and the device master record it generates.
None of these come from weak engineering. They come from treating design controls as documentation to finish rather than a discipline to run.
Requirements written so loosely that nothing can be objectively verified against them later.
Calling verification "validation," so the device is never actually shown to meet user needs.
Assembling the file at the end, when the record can only be reconstructed, never truly proven.
Inputs, outputs, and tests that cannot be linked, so an auditor cannot follow the thread.
Changes made without re-verification, quietly invalidating the evidence that came before.
Skipping use-related risk and usability validation — the gap FDA increasingly rejects devices over.
Design-control judgment is bought with inspections survived: knowing how an investigator reads a DHF, where traceability tends to break, and what verification a reviewer will actually accept. Your leads are senior quality practitioners who have built and defended these records.
We build the DHF an FDA investigator will open first — because we have sat across from them.
We thread needs to inputs to outputs to V&V from the start, not as a closing scramble.
We build to where FDA is going as 820 harmonizes with ISO 13485 under the QMSR.
We keep design controls and risk management as one loop, the way ISO 14971 intends.
Design controls do not stand alone. They interlock with the risk file, the quality system that houses them, and the standards that govern them.
The quality-system and risk-management standards design controls operate inside.
Explore Standards →Design controls and ISO 14971 risk management are one loop; we run them together.
Explore Risk →The quality system that houses design controls, the DHF, and the DMR they produce.
Explore QMS →Tell us about your device, where it is in development, and the state of your design controls. We will assess the gaps and match you with a senior quality lead, with a response within one business day. All inquiries are strictly confidential.
