Design Controls for Founders Who Have Never Worked in Medtech

If you're a first-time medtech founder, you are already doing design control work — you just don't know it yet. Every time you write down what your device has to do, decide how you'll test whether it does it, or get a colleague to look over a change before it ships, you're doing the activity the regulation asks for. The only question is whether any of that leaves a record. The single most expensive mistake a startup makes here isn't skipping the work — it's doing the work and then trying to reconstruct the paper trail months later, at submission time, from memory and old Slack messages. That reconstruction is never honest, and reviewers can generally tell.

This guide covers what design controls actually require today, why an old citation you've seen in a blog post or template kit is wrong, which devices are in scope, and the records a pre-submission startup should already have.

First, the thing nobody told you: § 820.30 is gone

For nearly thirty years, "design controls" meant one specific place in the Code of Federal Regulations: 21 CFR 820.30. An older guide or template kit that cites "820.30(f)" for verification or "820.30(g)" for validation is citing a section that no longer exists in force. Under the Quality Management System Regulation (QMSR), §§ 820.20 through 820.30 of Subpart B¹ are marked [Reserved] — removed, not replaced in place. Instead, 21 CFR 820.7² incorporates ISO 13485:2016 by reference wholesale, and 21 CFR 820.10³ makes conformance to it mandatory. Design and development is now Clause 7.3 of that standard, not a subsection of Part 820 — a change that took effect as part of the QMSR final rule⁴, effective February 2, 2026.

Do design controls apply to me?

Most founders assume design controls are a "big company, high-risk device" problem. The scope is broader than that, and it's worth checking precisely rather than guessing.

One scope question founders routinely get wrong: Devices under an Investigational Device Exemption are not exempt from § 820.10(c) design and development requirements⁵. "It's still investigational" is not a reason to skip design records. If you're not sure which class your device falls into, start with FDA's device classification⁶ tools before assuming either way. Getting a right-sized system built around your actual classification is exactly the kind of scoping a Virtual QMS implementation starts with.

Devices under an Investigational Device Exemption are not exempt from these design and development requirements⁵.

The loop, in founder language

Strip away the regulatory vocabulary and design controls are a feedback loop most engineering teams already run informally. The regulation just asks you to make it explicit, connected, and documented.

User needs

What the clinician, caregiver, or patient actually has to be able to do with your device — stated in plain language, from their point of view, not yours. This is the anchor everything else traces back to.

Design inputs

User needs turned into requirements specific enough to test: measurable, unambiguous, and traceable back to the need that generated them. A vague input ("the device should be reliable") can't be verified; a good one can.

Design outputs

What you actually made to meet those inputs — drawings, specifications, source code, labeling, packaging. Outputs are the thing you check the inputs against.

Verification

Did we build the thing right? Verification confirms design outputs meet design inputs — output against input, objective evidence, before you move on.

Validation

Did we build the right thing? Validation confirms the finished device meets user needs, tested under actual or simulated use conditions — device against user need, not device against spec sheet.

Design review

A documented, dated gate with someone independent of the specific design in the room — not a hallway conversation, a record of what was reviewed, who raised what, and what happened next.

Design transfer

The point where the design becomes manufacturing instructions someone else can actually build from — drawings and specs that a production team can follow without the original designer standing over their shoulder.

Design changes

Nothing in a released design changes casually. Changes get identified, documented, evaluated for risk, and re-verified or re-validated to the extent the change requires — including changes made after launch.

Verification vs validation — the distinction that trips up every first-timer

Nearly every founder mixes these up the first time, and it's worth one concrete, clearly hypothetical example. Suppose a design input states that an infusion pump must deliver fluid at a rate accurate to within 5% of the programmed setting. Verification is a bench test confirming the pump hits that ±5% spec under controlled lab conditions — output measured against the stated input. Validation is watching a real (or realistically simulated) clinician program and operate that pump as it will actually be used, and confirming the device serves the underlying clinical need — not just the spec sheet number. A device can pass verification and still fail validation if the spec itself missed something about how the device is actually used. That gap is exactly what both steps exist to catch.

Risk management is not a separate project

ISO 13485 applies a risk-based approach across the whole quality system, and design and development is where that shows up most directly: Risk analysis feeds design inputs, gets revisited at design review, and any design change gets re-assessed for the risk it introduces. The standard most device teams use in prose for the risk-management work itself is ISO 14971 — but the regulatory fact that conformance is required at all traces back to the same provisions covering design controls generally: § 820.7, which incorporates ISO 13485:2016 by reference, and § 820.10³, which makes it mandatory. FDA held a 2026 town hall specifically on risk and design and development under the QMSR, with slides and a transcript published⁷.

Human factors: the input founders forget

Use-related risk — the ways real people misuse, misread, or mishandle a device in the field — is a design input too, not an afterthought bolted on before submission. FDA's human factors and usability engineering guidance⁸ lays out the expectation: Identify use-related hazards, design to reduce them, and validate that real (or representative) users can use the device safely and effectively under realistic conditions. Folding this into design inputs from the start is cheaper than discovering a use error during formative testing after the design is frozen.

What "the file" is called now

If you've heard of the Design History File (DHF), the Device Master Record (DMR), or the Device History Record (DHR), those terms aren't banned or illegal — the current CFR text simply no longer defines them by name. Under ISO 13485, the DHF's successor is the design and development file (DDF) (clause 7.3.10), the retained design and development records demonstrating a device conforms to the standard. The DMR and DHR map instead to ISO 13485's broader medical device file concept (clause 4.2.3) — a related but separate set of records, not just the design history. In practice, the substance is what matters: Whatever you call your folders, the records that used to live in a DHF-shaped structure still have to exist, be dated, and be retrievable on request. A working DDF/medical device file structure generally doesn't need renaming — it needs its content confirmed against current requirements. For the fuller picture of which QMSR terms changed, see the QMSR transition checklist.

The five records a pre-submission startup should already have

If you're designing a device today and haven't formalized anything yet, these are the records to start with — not because a checklist says so, but because they're what an investigator or a premarket reviewer will actually look for:

• A design and development plan. What phases you're running, who's responsible for what, and how design review fits into your engineering schedule.
• A traceability matrix connecting user needs → design inputs → design outputs → verification → validation, so any requirement can be traced in both directions.
• Dated design review records with attendees and action items — not a meeting invite, an actual record of what was decided.
• A risk file that's been updated since kickoff, not written once at the start and never revisited as the design changed.
• A change log capturing what changed, why, and what was re-verified or re-validated as a result.

Worth knowing before you submit: Premarket reviewers may ask for quality-system information — including design control evidence — as part of certain submission reviews⁹. Having these five records in order isn't just an inspection safeguard; it can matter at submission too.

Getting started without slowing down engineering

The founders who get this right don't bolt on a heavyweight process — they right-size it. One design and development plan. One traceability matrix, kept current as you go rather than reconstructed later. A design review cadence tied to the engineering rhythm your team already has, not an artificial schedule imported from a template. That's the same right-sizing philosophy behind BushmanQC's Virtual QMS implementation and its approach to document control — scoped to what your company and device actually need.

Related reading: The FDA QMSR 10-point compliance checklist · How much does a QMS cost for a medical device startup? · Virtual QMS FAQ