Design controls are among the most frequently cited areas in FDA inspections of medical device manufacturers. Under 21 CFR Part 820 and the updated Quality Management System Regulation (QMSR), design controls require manufacturers to document the entire development process for a device, from initial user needs through design transfer and post-market feedback.

This article covers the specific requirements under 21 CFR Part 820 Subpart C, the design history file (DHF), common audit findings, and how the QMSR update aligns design control requirements with ISO 13485.

What are design controls and who must follow them?

Design controls apply to all manufacturers of Class II and Class III medical devices, and to Class I devices that are automated with software or are implantable. The FDA codified design control requirements in 21 CFR Part 820.30 when it issued the original Quality System Regulation in 1996. The QMSR, which became effective February 2, 2026, retains design control requirements and aligns them more closely with ISO 13485 Section 7.3.

The purpose of design controls is to establish a defined, documented, and verifiable process for converting user needs into device specifications and to confirm through objective testing that the final device meets those specifications.

The design control sequence under 21 CFR Part 820.30

Design and development planning (§820.30(b))

Every design project must begin with a documented plan. The plan identifies the design stages, the responsibilities assigned to each stage, and the interfaces between different development teams. The plan must be updated as the project evolves.

Design input (§820.30(c))

Design inputs are the physical and performance requirements for the device derived from the intended use and user needs. They must be documented, reviewed for adequacy, and approved by a designated individual.

The most common audit finding in design inputs is incomplete or ambiguous requirements. An input that states the device must be "easy to use" is not a design input. A measurable, verifiable requirement, such as a force threshold for actuation or a specific display resolution, is a design input.

Design output (§820.30(d))

Design outputs are the documents that define the finished device: drawings, specifications, procedures, and software code. Outputs must meet design inputs, and the connection between each output and its corresponding input must be traceable.

Design review (§820.30(e))

At each major design stage, a formal documented review must occur. The review includes at least one individual who does not have direct responsibility for the design stage being reviewed. Results, including follow-up actions, must be documented.

Design verification (§820.30(f))

Verification confirms that design outputs meet design inputs. It answers the question: did we build the device we designed? Verification methods include testing, inspection, analysis, and demonstration. Each verification activity must be documented with results, dates, and the individuals who performed and approved the testing.

Design validation (§820.30(g))

Validation confirms that the finished device meets user needs and intended uses. Where practical, validation must be performed on initial production units. Validation answers the question: does the device we built actually do what users need?

Software validation under FDA's Computer System Assurance (CSA) guidance applies to software that forms part of a device or controls a device.

Design transfer (§820.30(h))

Design transfer ensures that the device design is translated into production specifications that allow consistent manufacturing. Transfer procedures must confirm that production processes can produce a device that meets specifications.

Design changes (§820.30(i))

Any change to the design after initial approval must be identified, documented, reviewed, and approved before implementation. Changes that could affect the device's safety or effectiveness require an assessment of whether a new 510(k) or PMA supplement is needed.

Design history file (§820.30(j))

The design history file is the complete record of the design and development process. It does not need to be a single document, but it must contain or reference all records needed to demonstrate that the design was developed in accordance with the approved design plan.

Common FDA audit findings in design controls

The FDA's inspection data consistently shows design controls as one of the top observation categories for medical device manufacturers. The most frequently cited specific findings include:

Traceability gaps. Design inputs are not linked to corresponding design outputs, verification tests, or validation activities. Without traceability, there is no documented confirmation that every requirement was addressed. A design traceability matrix (DTM) or requirements traceability matrix (RTM) resolves this.

Validation using prototype devices. FDA requires that validation be performed using initial production units or their equivalent. Companies that validate using hand-built prototypes or pre-production samples and then change the manufacturing process before commercial production have a validation gap.

Incomplete design reviews. Reviews that lack the documented participation of a qualified independent reviewer, or reviews where action items are not tracked to closure, do not meet §820.30(e).

Design inputs that cannot be verified. Inputs must be stated in measurable terms. Qualitative inputs like "durable," "lightweight," or "user-friendly" cannot be verified through testing. FDA cites these as inadequate design inputs.

Design change control gaps. Post-approval changes that were implemented without documentation or without a risk assessment of their impact on safety and effectiveness represent some of the most serious design control violations. These can result in the device being distributed in an unapproved configuration.

Missing or incomplete DHF records. A design history file that cannot be located, that is incomplete, or that contains records not signed and dated by the responsible individuals fails to satisfy §820.30(j).

How QMSR changes design control requirements

The FDA's Quality Management System Regulation, effective February 2, 2026, incorporated by reference ISO 13485:2016, including Section 7.3 on design and development. The QMSR retains the substantive design control requirements from 21 CFR Part 820.30 while harmonizing the terminology and structure with ISO 13485.

Key changes quality teams should note:

• The QMSR uses the term “design and development” rather than “design controls,” aligning with ISO 13485 language
• Risk management under ISO 14971 is now explicitly integrated into the design and development process, rather than being treated as a separate activity
• The QMSR requires documented design and development inputs to include applicable regulatory requirements, making it explicit that regulatory research is part of the input process
• Transfer of design to manufacturing is now referenced in the context of documented procedures, consistent with ISO 13485 Section 7.3.7

Companies already operating under ISO 13485 certification found that their existing design control procedures required relatively minor updates to comply with the QMSR. Companies operating only under the original QSR faced more substantial documentation and process updates.

Managing design controls in a QMS platform

Design controls generate a large volume of interconnected records across a long development timeline. Managing those records manually in spreadsheets or shared drives creates traceability risks and makes it difficult to demonstrate a complete DHF during an inspection.

Cloudtheapp's QMS platform includes a Design Controls application that manages the full design and development lifecycle, from design plans and input requirements through verification, validation, design reviews, change control, and DHF compilation. Each record links to related records, creating automated traceability across the development process.

The platform's design change control workflow routes change requests through configurable approval steps and triggers a risk assessment for changes that affect safety or effectiveness, directly addressing the most common design control audit finding.

For medical device manufacturers preparing for an initial FDA inspection or addressing design control observations from a prior cycle, Cloudtheapp offers a live demo showing how the platform manages design and development documentation: https://www.cloudtheapp.com/demo/

See also: How to write a design history file that passes FDA review

Key takeaways

Design controls under 21 CFR Part 820 require a documented, traceable, and verifiable development process for every medical device. The most common audit findings, traceability gaps, invalid validation, and incomplete design reviews, all reflect the same underlying issue: the design process was not planned and documented as a controlled system from the start.

The QMSR update aligns FDA's design control requirements with ISO 13485 Section 7.3 and explicitly integrates risk management throughout the design process. Companies that maintain a complete design history file with traceable links from user needs through validated device performance have a strong foundation for both FDA inspections and ISO 13485 audits.