21 CFR 820 design controls—what engineering teams need to know

21 CFR 820 is the FDA's Quality System Regulation for medical devices. Section 820.30—design controls—is where engineering teams spend most of their regulatory energy, and where most compliance failures originate. The regulation is not complicated. What is complicated is integrating its requirements into the way real engineering teams actually work, without turning every decision into a documentation event.

What 820.30 actually requires

The design control process under 820.30 is a cascade. It begins with user needs—the clinical and operational requirements that define why the device exists—and flows through design inputs, design outputs, verification, validation, and design transfer. Each stage has a defined relationship to the next, and the Design History File (DHF) is the record that proves those relationships were managed with intent.

User needs are not marketing requirements. They are the starting conditions for the entire engineering program. Getting them right—specific, testable, traceable—determines whether the rest of the cascade holds. Design inputs translate user needs into engineering requirements: dimensional tolerances, material specifications, software functional requirements, biocompatibility thresholds. Design outputs are the deliverables that implement those inputs: drawings, specifications, software builds, manufacturing procedures.

The regulation requires that design outputs be defined in terms that allow an adequate evaluation of conformance to design input requirements. That is an engineering statement. It means your outputs have to be written with enough precision that someone—an engineer, an auditor, a notified body reviewer—can look at a design output and determine whether it satisfies the corresponding input.

Decisions that trigger documentation

The practical challenge of 820.30 is knowing which engineering decisions create documentation obligations. The answer is almost all of them—but the burden is proportional to consequence.

A design review (820.30(e)) is required at appropriate stages of design development. "Appropriate" is not defined because it depends on the device, the risk class, and the complexity of the design. For most Class II devices, engineering teams should plan formal design reviews at three minimum gates: after design inputs are established, after design verification is complete, and prior to design transfer. Each review requires documented results—including the identification of reviewers—and the records become part of the DHF.

Design verification (820.30(f)) answers the question: does the design output conform to the design input? It is engineering-led testing—bench testing, analysis, inspection, simulation. Design validation (820.30(g)) answers a different question: does the finished device meet the user needs under actual or simulated conditions of use? Validation is where clinical context re-enters the picture.

The distinction matters operationally. You can verify a catheter's burst pressure specification with a bench test. You cannot validate usability by testing against your own engineers—you need representative users. Understanding which activities are verification and which are validation determines your testing strategy, your resource plan, and your timeline.

Design changes and the DHF

Design changes (820.30(i)) are where many teams accumulate their most significant compliance debt. Every change to design inputs, design outputs, or the design itself requires evaluation of the change's effect on the device and its components. If the change affects an approved design, it requires formal review and approval before implementation.

In practice, engineering teams make dozens of design decisions between formal reviews. Not all of them are changes in the regulatory sense. But the ones that are—material substitutions, geometry changes that affect function, software changes that touch safety-critical paths, labeling changes—have to be captured, evaluated, and dispositioned. The DHF is the accumulation of that record.

The DHF does not need to be a physical binder or a monolithic document. It is a collection of records that, taken together, demonstrates that the design was developed in accordance with 820.30. What it cannot be is incomplete, reconstructed after the fact, or disconnected from the engineering decisions that actually shaped the device.

Design transfer

Design transfer (820.30(h)) is the process of ensuring that the design basis—the requirements, the specifications, the verification results—is translated correctly into production procedures. This is where engineering and manufacturing intersect, and where design control records have to be stable enough to serve as the authoritative reference for production.

Transfer is not a handoff event. It is a verification that the device you validated in development is the device that production can reliably build. That requires engineering rigor in how specifications are written, how process parameters are defined, and how production equivalence is confirmed.

How MANKAIND structures design control

MANKAIND treats the design control cascade as an engineering workflow, not a documentation workflow. When an engineer establishes a design input, MANKAIND links it to the user need it satisfies and creates the scaffold for the verification protocol that will close it. When a design review occurs, MANKAIND generates the meeting record from the engineering context already in the platform—attendees, open action items, design status. When a design change is proposed, MANKAIND evaluates its traceability footprint: which inputs does it touch, which verification records need to be updated, which risk items may be affected.

The result is a DHF that grows as engineering progresses—not a documentation sprint that happens at submission time. For teams preparing an FDA 510(k) or pursuing ISO 13485 certification, that distinction is the difference between a submission that holds up under scrutiny and one that generates a request for additional information.