Design Controls & the DHF: A Practical Guide for Small Device & SaMD Teams

Design controls are where the FDA finds the most trouble. Year after year, design-control deficiencies sit near the top of the agency's inspection findings — and they're the observations most likely to escalate, because a weak design history casts doubt on whether the device was developed under control at all. For a small device or Software as a Medical Device (SaMD) team, design controls can feel like bureaucracy invented to slow you down. They aren't. They're a structured way to prove that what you built is what you intended, that it's safe and effective, and that you can show your work. This guide walks through what design controls actually require, what belongs in the Design History File, and the pitfalls that most often trip up small teams.

What "design controls" actually means

Since February 2, 2026, the FDA's Quality Management System Regulation (QMSR) incorporates ISO 13485:2016 by reference. Design controls, which used to live in 21 CFR 820.30, now sit in ISO 13485:2016 §7.3 (Design and development). The concepts are the same ones device makers have followed for decades — the citation just changed.

Design controls apply to almost every device that isn't the lowest-risk Class I, and to SaMD as much as to hardware. The core idea is a disciplined loop: you plan the work, define what the device must do, produce a design that meets those requirements, prove it does through verification and validation, review it at defined points, and control every change along the way. Nothing gets to be "done" on someone's say-so — it's demonstrated, reviewed, and recorded.

The Design History File (DHF), post-QMSR

The Design History File is the familiar term from the old QSR (21 CFR 820.30(j)): the compilation of records that describes the design history of a finished device. ISO 13485 doesn't use the phrase "DHF" — the equivalent requirement is the design and development file in §7.3.10, one per device type, that either contains or points to the records demonstrating conformity to §7.3. Most teams still call it the DHF, and an FDA investigator will still ask for it by name.

The single most important thing to understand: the DHF is a compilation, not a binder you write at the end. It's the collected evidence generated as you go — plans, requirements, design outputs, verification and validation results, design-review minutes, and change records. A DHF assembled retrospectively, the week before an audit, is exactly what an investigator is trained to spot, and it undermines the credibility of everything in it.

The elements, in plain terms

ISO 13485 §7.3 breaks the design process into stages. Here's what each one is really asking for.

• Design and development planning (§7.3.2). A plan that says what will be designed, who's responsible, what the stages are, and how review, verification, validation, and transfer will happen. It's allowed to evolve — but it has to exist and be kept current.
• Design inputs (§7.3.3). The requirements the device must meet: intended use, user needs, functional and performance requirements, safety, applicable standards, and regulatory requirements. Inputs must be unambiguous and testable — "easy to use" is not an input; "a trained nurse can complete setup in under two minutes" is.
• Design outputs (§7.3.4). What the design work produces — specifications, drawings, source code, labeling, acceptance criteria. Outputs must be expressed in terms that can be verified against inputs, and they define what goes into production.
• Design review (§7.3.5). Formal, documented reviews at planned stages, including someone independent of the stage being reviewed. This is a real control, not a status meeting — its job is to catch problems while they're still cheap to fix.
• Design verification (§7.3.6). Proof that outputs meet inputs — that you built the device right. Testing, inspection, analysis against the requirements.
• Design validation (§7.3.7). Proof that the device meets user needs and intended use under actual or simulated use conditions — that you built the right device. Verification and validation are not the same thing, and conflating them is one of the most common (and most cited) mistakes.
• Design transfer (§7.3.8). Making sure the design is correctly translated into production specifications, so what ships matches what was designed and validated.
• Design change control (§7.3.9). Every change to the design is identified, reviewed, verified or validated as appropriate, approved, and recorded — before it takes effect. Uncontrolled changes are how a validated design quietly stops being the design you validated.

Traceability is the spine

If there's one thing an auditor will pull on, it's traceability: can you follow every design input to the output that satisfies it, and to the verification and validation that proves it? A traceability matrix is the artifact that makes this visible — inputs down one axis, outputs and V&V across, with the gaps immediately obvious. A missing link (an input with no output, an output with no verification) is a finding waiting to happen. Building traceability as you design, rather than reconstructing it later, is the difference between a DHF that holds up and one that unravels under questioning.

A note for SaMD teams

If you're building Software as a Medical Device, design controls apply in full — software doesn't get a pass. In practice you'll run design controls (§7.3) alongside a software development life cycle under IEC 62304, and risk management under ISO 14971. Your design inputs include software requirements; your outputs include the architecture and source; verification includes unit and integration testing; validation demonstrates the software meets user needs in its intended clinical context. The discipline is identical to hardware — the outputs just look like code, test suites, and architecture documents instead of drawings.

Where small teams get into trouble

• The retrospective DHF. Design first, document later — then scramble to assemble a file that looks like control was there all along. It rarely survives scrutiny.
• Verification/validation confusion. Treating "it passed our tests" as validation. Verification checks outputs against inputs; validation checks the device against user needs. You need both, distinctly.
• Design reviews as theater. A meeting with no independent reviewer, no recorded issues, and no actions isn't a design review — it's a checkbox.
• Inputs that can't be tested. Vague requirements make verification impossible and validation subjective. Time spent making inputs measurable pays for itself.
• Uncontrolled changes. A "small" tweak after validation, made without change control, is how a compliant design silently drifts out of compliance.

How a modern eQMS helps

None of this requires enterprise software — but a system built for it removes most of the manual failure modes. A right-sized eQMS keeps design inputs, outputs, and V&V as linked records with a live traceability matrix, so gaps are visible in real time instead of discovered in an audit. Design reviews and V&V sign-offs are captured as electronic signatures bound to the exact record version, with an immutable audit trail — so "who approved this, and against what" always has an answer. And design changes run through controlled change management, so nothing takes effect without review. The point isn't more paperwork; it's that the evidence assembles itself as you work, which is exactly what the DHF is supposed to be.

Indelio is built for small device and SaMD teams who need real design controls — inputs-to-outputs traceability, e-signed design reviews and V&V, and change control — without an enterprise price tag or a six-month rollout. If your design history lives in spreadsheets and shared drives today, that's the gap worth closing before your first submission or inspection.