Design control is the set of documented procedures, reviews, and records that govern how a medical device is designed, developed, and transferred to manufacturing. It exists because the FDA determined — after a series of device failures in the 1980s tied directly to design deficiencies — that many safety problems could be prevented if manufacturers followed a structured development process rather than designing ad hoc and testing late.

The original requirement appeared in 21 CFR Part 820.30, the Design Controls section of the Quality System Regulation (QSR), which took effect in 1996. On February 2, 2026, the FDA's Quality Management System Regulation (QMSR) replaced the QSR, aligning U.S. device requirements with ISO 13485:2016. Under the QMSR, design control requirements now map to ISO 13485 Clause 7.3 (Design and Development) rather than the prescriptive text of 820.30.

The substance of what FDA expects from design control programs has not changed significantly. The structure for demonstrating compliance has.

Who Must Follow Design Control Requirements

Under the old QSR's 820.30, design control applied to Class II and Class III devices and certain Class I devices. The QMSR and ISO 13485:2016 take a risk-based approach: design control requirements apply to any medical device where the design and development process could affect product safety, performance, or regulatory compliance.

In practice, this means most manufacturers of finished devices need documented design controls. Contract manufacturers who build to a customer-supplied design may be exempt from design control requirements for that specific product, but they must document the determination. The exemption is not assumed.

The Eight Elements of Design Control

Whether you are working under the old 820.30 or the current QMSR and ISO 13485:2016, the core elements of a design control system remain consistent.

Design and Development Planning requires a documented plan that identifies the activities required to complete the design, assigns responsibilities, and accounts for how the design interfaces with other products or systems. The plan must be updated as the design evolves. A static plan written at project kickoff and never revised is a documentation gap that FDA investigators note consistently.

Design Inputs are the documented requirements the device must meet. These include intended use, user needs, performance specifications, safety requirements, applicable standards, and regulatory requirements. Poorly defined inputs are the upstream cause of most design verification failures. If the inputs do not capture what the device actually needs to do, verification testing that confirms conformance to those inputs proves less than it appears to.

Design Outputs are the translated results of the design process: drawings, specifications, procedures, and software code. Each output must reference the input it satisfies, which is the foundation of design traceability. Under ISO 13485 Clause 7.3.4, design outputs must be in a form that allows verification against design inputs before release.

Design Review is a formal, documented examination at defined stages of the design process. It must include at least one individual who is not directly responsible for the design being reviewed. Design reviews evaluate whether the design meets its inputs, identify problems, and drive resolution before the project advances. Reviews that happen but are not documented — or that are documented as "no issues identified" without supporting records — generate audit findings during FDA inspections.

Design Verification confirms that the design output meets the design input. This is the "did we build it right" question. Verification typically involves testing, analysis, inspection, or comparison to a proven design. The verification protocol defines what will be tested, acceptance criteria, and sample sizes. When verification fails, the finding should feed back into the risk register and trigger a design change process.

Design Validation confirms that the finished device meets user needs and intended uses under actual or simulated use conditions. This is the "did we build the right thing" question. Validation must be performed on production-representative units. Validation on engineering prototypes does not satisfy the requirement. Under ISO 13485 Clause 7.3.6, software used in medical devices requires validation appropriate to its intended use and safety classification.

Design Transfer documents the process for moving the validated design into production. Transfer activities confirm that the production process can consistently produce a device that meets the design specifications. Transfer records connect the design outputs to the production documentation — drawings, work instructions, inspection criteria, and process parameters.

Design Changes require documented procedures for reviewing, approving, and implementing any change after design freeze. Under ISO 13485 Clause 7.3.9, changes must be evaluated for their effect on the complete device and on previously completed verification and validation activities. A change that affects a previously validated interface or safety-related function requires re-validation of the affected elements, not just re-testing.

What Changed Under FDA QMSR

The QMSR, effective February 2, 2026, incorporated ISO 13485:2016 by reference. This means FDA inspectors now evaluate design control compliance against ISO 13485 Clause 7.3 language rather than the specific text of 820.30.

Several practical differences follow from this shift.

The old 820.30 required a Design History File (DHF) — a compilation of records that describes the design history of a finished device. ISO 13485 Clause 7.3 does not use the term DHF, but FDA's QMSR final rule confirmed that FDA-specific requirements, including the DHF obligation, are maintained through supplemental requirements in the regulation. Manufacturers still need to maintain a DHF.

ISO 13485 Clause 7.3 introduces an explicit requirement for documented design and development inputs that include applicable regulatory requirements — a consideration for devices that need to comply with EU MDR, Canada's CMDR, or other international frameworks alongside U.S. requirements. For companies selling into multiple markets, design inputs that explicitly map to each applicable regulation simplify market-specific submission documentation.

The QMSR also strengthened the connection between design control and risk management. Under QMSR, ISO 14971 risk management outputs must be integrated into the design control process throughout development — not treated as a separate activity completed before design freeze. Design reviews must consider risk management outputs. Verification and validation activities must cover safety-critical functions identified in the risk analysis.

FDA Inspection Patterns for Design Controls

Design controls ranked as the second most frequently cited area in FDA device inspections in 2025, according to Hogan Lovells' September 2025 analysis of inspection trends. CAPA ranked first, and the two are closely connected: unresolved design control gaps frequently generate CAPAs, and CAPA investigations often surface design control deficiencies that were not previously documented.

The patterns FDA investigators find most often in design control programs:

Traceability gaps between design inputs and outputs are the single most common finding. Companies produce verification test reports but cannot show which input requirement each test was designed to verify. The traceability matrix either does not exist or was built after the fact and does not reflect the actual testing sequence.

Incomplete Design History Files are cited regularly, particularly in companies that manage design documentation across multiple systems — a PLM tool, a shared drive, and a paper archive. When an investigator requests the DHF and receives a partial compilation, the response "the rest is in the other system" is not sufficient. The DHF must be a coherent, accessible compilation.

Design changes processed outside the formal change control procedure appear in inspection records when companies make field corrections, software patches, or label changes without running those changes through the design control process. Under QMSR, any change to a previously validated design element requires documented evaluation and, where the change affects validated performance, re-validation.

Validation on non-representative units continues to be cited. Companies run final validation testing on hand-built or pre-production units and do not repeat or bracket the testing once manufacturing processes are finalized.

The Design History File: What Must Be in It

The DHF is not a single document. It is a compilation of records that, taken together, tells the complete story of how the device was designed and confirmed to meet its requirements.

A complete DHF includes the design and development plan, design input specifications, design output documentation, design review records, verification protocols and results, validation protocols and results, design transfer records, and all design change records from initial design through product release. Risk management records — per ISO 14971 — should also be referenced or included.

For companies managing DHFs in paper or disconnected electronic systems, the effort required to compile and present the DHF during an inspection is significant. The DHF must be produced quickly when requested. A two-day delay in assembling records creates its own impression during an inspection, separate from the content of the records themselves.

Managing Design Controls in an Electronic QMS

Design control in an electronic QMS connects planning documents, input specifications, output records, review sign-offs, verification and validation results, and change requests in a single traceable system. When a design input changes, the linked verification records receive an automatic notification. When a design change is submitted, the system identifies every downstream document that references the changed element.

This is the difference between traceability that exists as a spreadsheet maintained by one engineer and traceability that the system enforces by structure. During an FDA inspection, the ability to pull a complete, time-stamped, electronically signed DHF in minutes — rather than hours — directly affects how the inspection proceeds.

Cloudtheapp's Design Controls application connects inputs, outputs, reviews, and change management into a single workflow with full audit trail. Verification and validation records link directly to the design inputs they address. Request a demo at cloudtheapp.com/demo/ to see how the system handles DHF compilation and design change traceability.

The Inspection Question You Want to Be Ready For

FDA investigators ask one question in almost every device inspection that involves design controls: "Can you show me the traceability from your design inputs to your verification testing?"

Companies that answer this by opening a spreadsheet and scrolling through rows are spending inspection time explaining gaps. Companies that answer it by opening a QMS and pulling a linked traceability matrix in 30 seconds are moving on to the next question.

The design control requirement has not changed materially under QMSR. What the QMSR changed is the framework language and the explicit integration of risk management throughout the design process. For companies already running a mature ISO 13485 design control program, the transition to QMSR compliance is largely administrative. For companies that built their design control system around the specific text of 820.30 and never updated it to align with ISO 13485, there are substantive gaps to address before the next FDA Form 483 arrives.

This post created by and appeared first on Cloudtheapp

This post created by and appeared first on Cloudtheapp