What is the difference between a design and development file and a device master record?

Both records are required under the QMSR. The design and development file (historically called the Design History File under 21 CFR 820.30(j)) is now the ISO 13485 Clause 7.3.10 record; it documents how the device was designed. The device manufacturing information (historically the Device Master Record under 21 CFR 820.181) is now captured by the ISO 13485 Clause 4.2.3 "medical device file"; it contains the current specifications and instructions for producing the device. The distinction stands: the design and development file records how the device was designed; the medical device file contains the current recipe for producing it.

Are Class I devices subject to design controls?

Most Class I devices are not subject to the full design and development requirements. The exceptions are the Class I devices listed in 21 CFR 820.10(c)(1) and Table 1 to 820.10(c)(2). Check the applicable product code in FDA's device classification database to confirm your device's requirements.

Does FDA require a specific design and development file format?

No. The requirement is that the file be a compilation of records demonstrating the device was developed in accordance with the approved design plan. The format, location (paper or electronic), and organization are up to the manufacturer. Many companies use quality management software to maintain the file, which simplifies retrieval during inspections. What FDA looks for is completeness, organization, and evidence that records were created contemporaneously.

When does design validation have to be done?

Validation must be performed before a device is released for distribution. Under ISO 13485 Clause 7.3.7, it must be conducted on the product as it will be produced, using representative production units, under actual or simulated use conditions. Representative production units means the test units reflect the actual manufacturing process, not prototype units from a different process.

What is design transfer and why does it matter?

Design transfer is the process of ensuring the device design is correctly translated into production (ISO 13485 Clause 7.3.8). After design transfer, the manufacturing team should be able to produce devices that meet the design specifications consistently. It must include verification that production methods can produce devices meeting design requirements. Poor design transfer is a common source of manufacturing defects that surface post-market.

Do design controls apply to software-only devices?

Yes. Software as a Medical Device (SaMD) and software that is a component of a medical device is subject to the design and development requirements under 21 CFR 820.10(c) and ISO 13485 Clause 7.3. Software devices should also comply with IEC 62304 (software life cycle processes), which FDA recognizes (IEC 62304:2006+AMD1:2015), and should follow FDA's current premarket software guidance for what documentation goes in a submission.

Medical Device Design Controls: What They Are and How They Work Under FDA's QMSR (21 CFR 820.10 and ISO 13485 Clause 7.3)

Direct answer: Design controls are the FDA-required procedures that govern how a medical device is designed, tested, and transferred to manufacturing. As of the QMSR compliance date of February 2, 2026, FDA's design and development requirements are set out in 21 CFR 820.10(c), which requires manufacturers of Class II, Class III, and certain Class I devices to comply with ISO 13485:2016 Clause 7.3 (Design and Development). What U.S. practice long called "design controls" under the former 21 CFR 820.30 is now the ISO 13485 "design and development" process, covering design and development planning, inputs, outputs, review, verification, validation, transfer, changes, and the design and development file. The goal is to ensure that the finished device meets its intended use and user needs before it reaches patients. (As of July 2026.)

Design controls exist because FDA learned, from decades of device recalls and adverse events, that defects caught in design are far cheaper and less dangerous than defects discovered after a device reaches the market. The requirements formalize what good engineering practice already demands: plan before you build, verify what you built, validate that it works for the intended user, and document all of it.

If you are a device founder or product lead early in development, understanding design controls is not just a compliance checkbox. It shapes how you run your development program, what you document as you go, and how quickly you can respond when FDA asks questions during a 510(k) review.

The QMSR Framing: Where Design Controls Live Now

Design controls were historically codified at 21 CFR 820.30 in FDA's Quality System Regulation. As of February 2, 2026, that section is reserved and the requirements are carried by 21 CFR 820.10(c), which incorporates ISO 13485:2016 Clause 7.3 (Design and Development) by reference. FDA's 1997 "Design Control Guidance for Medical Device Manufacturers" (https://www.fda.gov/media/116573/download) remains a useful plain-language explanation of the underlying concepts, which carry forward substantively unchanged.

FDA has adopted ISO's terminology, so what U.S. practice long called "design controls" is now the ISO 13485 "design and development" process. The plain-language element names below are the vocabulary the industry still uses; the citations are the current ones.

The QMSR's compliance date was February 2, 2026, and it applies to all manufacturers as of that date (there is no phased transition or grace period after the compliance date). The design and development requirements carry forward substantively via ISO 13485:2016 Clause 7.3, which 21 CFR 820.10(c) makes the operative standard for Class II, Class III, and listed Class I devices.

The Seven Elements of Design and Development

The design and development process has seven core elements. They are not entirely sequential, though the process generally flows from inputs to outputs to transfer.

1. Design and Development Planning

Before development begins, the manufacturer must establish a plan that describes or references the design and development activities and defines responsibility for implementation. The plan must be updated as the design evolves (ISO 13485 Clause 7.3.2, Design and development planning).

In practice this means a document, often called a Design and Development Plan or Project Plan, that names who is responsible for each phase, what milestones exist, and what reviews, verification, and validation activities will be conducted. The requirement is that the plan exist and be followed.

2. Design Input

Design inputs are the physical and performance requirements of the device (ISO 13485 Clause 7.3.3, Design and development inputs). They translate user needs into engineering requirements. Inputs must be documented, incomplete or ambiguous or conflicting requirements must be resolved, and someone with authority must approve the final set of inputs.

Getting design inputs right is arguably the most important step in the entire process. A device built to the wrong requirements will fail verification and validation regardless of how well it was built. Common input sources include user research, clinical literature, applicable standards (ISO, ASTM, IEC), regulatory requirements, and feedback from intended users.

3. Design Output

Design outputs are the results of each design phase (ISO 13485 Clause 7.3.4, Design and development outputs). They include drawings, specifications, software code, production procedures, and acceptance criteria. Outputs must be documented, reviewed, and approved before they are released.

The relationship between inputs and outputs is the foundation of design traceability. Each output should be traceable to a specific input, and each input should be addressed by at least one output. This traceability is what allows you to demonstrate, during a 510(k) review or an audit, that every requirement was addressed.

4. Design Review

Design reviews are formal, documented evaluations of design results at defined stages of development (ISO 13485 Clause 7.3.5, Design and development review). Reviews must include individuals with authority and responsibility for the design stage being reviewed, and a reviewer who does not have direct responsibility for that stage.

Design reviews are not informal team check-ins. They require documented records including who attended, what was reviewed, what action items were identified, and how those items were resolved. FDA inspectors routinely ask for design review records.

5. Design Verification

Design verification confirms that the design outputs meet the design inputs (ISO 13485 Clause 7.3.6, Design and development verification). It answers the question: did we build it the way we specified it? Verification typically includes bench testing, dimensional inspection, software code review, electrical safety testing, and similar activities.

Verification is not clinical testing. It does not establish that the device works for its intended clinical use. That is the role of validation. Verification and validation are related but distinct, and FDA treats the distinction seriously.

6. Design Validation

Design validation establishes that the device conforms to defined user needs and intended use (ISO 13485 Clause 7.3.7, Design and development validation). Validation must be performed on the product as it will be produced, using representative production units, under defined operating conditions.

Software validation is a significant and separately documented obligation. FDA's guidance "General Principles of Software Validation" (https://www.fda.gov/media/73141/download) applies to software that is a component of a medical device or is used in the production or quality system.

Validation also connects to risk management: ISO 13485 Clause 7.1 requires risk management across product realization, with reference to ISO 14971. This is where design validation connects to your ISO 14971 risk management program.

7. Design Transfer and Design Changes

Design transfer ensures that the device design is correctly translated into production specifications (ISO 13485 Clause 7.3.8, Design and development transfer). It is the bridge between development and manufacturing, and it requires verification that production can produce devices that meet the design requirements.

Design changes, including changes to software, must be identified, documented, reviewed, verified, validated (where appropriate), and approved before implementation (ISO 13485 Clause 7.3.9, Control of design and development changes).

The Design and Development File

The design and development file (historically called the Design History File, or DHF) is the collection of records that demonstrates the device was developed in accordance with the approved design plan (ISO 13485 Clause 7.3.10, Design and development files). It is not a single document. It is a set of records, maintained in an organized way, that tells the story of the device's development from initial inputs through design transfer.

When FDA conducts a 510(k) review, it may ask for these records to verify claims in the submission. When FDA inspects a manufacturing facility, investigators will examine them. A well-maintained file makes both of those interactions faster. A disorganized or incomplete file can slow a review or trigger a Form 483 observation.

Minimum contents:

Design and development plan
Design input documentation and approval records
Design output documents (drawings, specifications, procedures)
Design review records (minutes, attendees, action items)
Verification protocols and results
Validation protocols and results
Risk analysis (typically the ISO 14971 risk management file)
Design transfer records
Design change records

When Design and Development Requirements Apply

Under 21 CFR 820.10(c), the design and development requirements (ISO 13485 Clause 7.3) apply to:

All Class III devices
All Class II devices
Class I devices listed in 21 CFR 820.10(c)(1) and Table 1 to 820.10(c)(2)

Most Class I devices that are not on that list are not subject to the full design and development requirements, though they are still subject to other QMSR requirements.

If you are not certain whether your device is covered, FDA's product classification database (https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfpcd/classification.cfm) identifies the device class and applicable requirements by product code.

Design Controls and 510(k) Submissions

Design controls are separate from the 510(k) process, but they interact with it in important ways. Your 510(k) submission must include a 510(k) summary or 510(k) statement, performance testing data, and (for software devices) documentation described in FDA's software guidance. Much of the test data in a 510(k) comes from design verification and validation activities that are part of the design and development process.

In other words, if you run your design and development process rigorously, the evidence you need for your 510(k) exists as a byproduct of development. If you skip or shortcut it, you will often find yourself conducting duplicative testing to generate data for the submission. See our companion article on verification and validation for medical devices.

Common Mistakes That Delay 510(k) Reviews

Based on the pattern of FDA Additional Information (AI) requests, the most common design-and-development gaps that delay review are:

Incomplete traceability. Design inputs are listed but not mapped to verification or validation testing. FDA asks: how do we know every requirement was tested?

Verification without validation. Bench testing is thorough, but no usability or clinical validation is documented. FDA asks: how do you know it works for the intended user?

Design reviews with no independent reviewer. A review attended only by the development team does not satisfy the independent-reviewer requirement in Clause 7.3.5.

A file that exists on paper but was not created contemporaneously. Reconstruction of records after the fact is a significant quality system finding.

Software validation gaps. For devices with software, missing or inadequate software validation documentation is among the most common reasons for FDA Additional Information requests.

From Design Controls to Launch

Design controls are an engineering discipline, but their outputs feed directly into your marketing and commercialization program. The claims you will make in your 510(k) submission, on your product website, and in sales materials to hospital procurement teams are grounded in your design validation data. The clinical evidence and performance data you developed during verification and validation is what makes those claims credible and defensible.

When Buzzbox Media works with device companies approaching launch, the marketing program is built around what the device actually demonstrated in V&V testing, not aspirational language. That alignment between regulatory evidence and marketing copy is what helps a launch hold up to regulatory scrutiny.

If you are 12 to 18 months from your 510(k) submission and want to understand how your development program connects to your commercialization strategy, a 30-minute call is a useful starting point. Book at https://www.buzzboxmedia.com/book.