FDA design controls are the documented development process required for most medical devices under 21 CFR 820.30, the design section of the Quality System Regulation. In practice they require you to write down what the device must do, prove that what you designed meets it, prove that what you built solves the user's actual problem, and keep an organized record of the whole chain in a design history file. They apply to Class II and Class III devices and to a small number of Class I devices, and the single most expensive mistake founders make is treating them as paperwork to generate after the engineering is finished.

This article is educational only. Projects House is an engineering firm, not a regulatory consultancy or law firm; a qualified regulatory professional should confirm what applies to your specific device and submission pathway.

What Design Controls Are, and Why They Are Not Just Bureaucracy

Strip away the vocabulary and design controls describe how careful engineering already works: define requirements, review them, test against them, control changes, and keep records. The regulation makes that discipline mandatory and auditable.

The reason it matters commercially is that the documentation is the submission. When you file a 510(k) or a De Novo, the reviewer is reading the artifacts your process produced. Teams that developed without design controls face a reconstruction project — writing requirements retroactively to match a device that already exists, then discovering that some tests were run on a configuration that no longer ships. Reconstruction is slower, more expensive, and less convincing than doing it in order. Where your device sits in the classification scheme drives how much of this applies; see FDA medical device classes and the overall route in the FDA approval process for medical devices.

The Core Elements

Design and Development Planning

A written plan describing the phases of development, the deliverables at each phase, who is responsible for what, and how interfaces between disciplines and organizations are managed. It is maintained and updated as the project evolves — a plan that was written once and never revised is a finding waiting to happen.

Design Inputs

The requirements the device must meet: clinical need, performance, user interface, environment of use, electrical safety, biocompatibility, sterility, packaging, shelf life, and applicable standards. Inputs must be unambiguous, complete enough to design from, and verifiable — "the device shall be easy to use" is not an input; a defined task completion criterion is. This is the phase where most projects are underspecified, and every downstream problem traces back here. The discipline is the same as writing a product requirements document for any product, with regulatory rigor and traceability added.

Design Outputs

Everything that defines the device and how to make it: drawings, specifications, source code, bills of materials, assembly instructions, labeling, and test procedures. Outputs must reference the inputs they satisfy and must contain the acceptance criteria that matter to the device's function and safety.

Design Reviews

Formal, documented reviews at defined stages, with participants including someone independent of the work being reviewed. The record captures who attended, what was reviewed, what issues were raised, and how each was resolved. These are the checkpoints that catch a bad assumption while it is still cheap to fix.

Verification and Validation

Two different questions, and confusing them is the most common conceptual error in the field. Verification asks: did we build the device to the specification? It is bench testing, dimensional inspection, electrical safety testing, software unit and integration testing, measured against the design inputs. Validation asks: does the finished device meet user needs and intended use in real conditions? It involves the production-equivalent device, real or representative users, and often human factors and clinical evidence. A device can pass every verification test and still fail validation because the requirements themselves were wrong.

Design Transfer

The translation of the design into production specifications, demonstrated to actually work in manufacturing. This is where a design that only a skilled engineer could assemble becomes a real problem — process validation has to show that the manufacturing process reliably produces conforming devices. The manufacturability discipline is the same as in any product program, described in design for manufacturing, but here it has to be documented and validated.

Design Changes and the Design History File

Every change after a design is established goes through documented review, and its impact on verification, validation, and risk is assessed before it is approved. The design history file is the compiled record demonstrating the design was developed according to the plan — not a single document but an organized, traceable collection. The change discipline is a stricter version of a normal engineering change order process, with an added requirement to reassess risk.

Risk Management Runs Alongside Everything

Design controls and risk management are separate requirements that reference each other constantly. Hazards identified through risk analysis become design inputs; verification evidence demonstrates that risk controls are effective; and any design change triggers a re-look at risk. Running the two processes on separate tracks is a classic source of gaps found during audit. The process itself is described in ISO 14971 risk management for medical devices.

When to Start

Formal design controls attach once you begin developing the device you intend to commercialize. Early feasibility work and research prototypes are generally outside the requirement, and pretending otherwise slows exploration for no benefit.

The practical answer: keep early exploration light, but draw a clear line — a documented transition from feasibility to development — and from that point forward operate under the plan. Teams that never draw the line end up either over-documenting throwaway experiments or under-documenting the real device. Our guide to medical device prototyping covers how to structure that early phase so nothing useful is lost when the formal process starts.

Mistakes Startups Make Repeatedly

  • Documenting after the fact. Reconstruction costs multiples of doing it in sequence and produces weaker submissions.
  • Vague design inputs. Unverifiable requirements make verification impossible to close out cleanly.
  • Skipping validation on production-equivalent units. Validating a hand-built prototype and then changing the manufacturing process invalidates the evidence.
  • Ignoring software. If your device contains software, it carries its own documentation expectations proportional to its risk level; standalone software may be regulated in its own right, as covered in software as a medical device.
  • Treating the design history file as a deliverable. It is an accumulating record. Building it at the end guarantees gaps.
  • Undocumented supplier changes. A component substituted by a contract manufacturer for availability reasons is a design change, and it needs to be handled as one.

Design Controls With an External Development Firm

Most device startups develop with outside engineering help, which is entirely normal and expected — but responsibility for the quality system does not transfer. Before work begins, agree in writing which party generates which records, whose document control system holds them, how reviews are conducted and by whom, and in what format the design history file is handed over. Ambiguity here produces the worst possible outcome: work that was done properly but cannot be evidenced. Quality system expectations for both sides are covered in ISO 13485 requirements, and the budget implications in medical device development cost.

Doing It Well in Practice

The teams that find design controls manageable share a few habits: they maintain a single traceability matrix linking each user need to a requirement, a design output, and a test result; they hold short, frequent reviews instead of rare enormous ones; they write test protocols before running tests; and they update the risk file in the same week a design change is approved rather than months later. Done this way, the overhead is real but bounded, and it typically saves more schedule than it consumes by catching defects at the requirements stage instead of at verification.

Projects House develops medical devices inside a design-controlled process, producing the inputs, outputs, verification protocols, and traceability that a submission actually needs — with the documentation built as the engineering happens, not reconstructed afterward. If you are developing a device and want the technical work and the record to advance together, describe your project through our contact form.