Design Controls Under QMSR: What Changes When 820.30 Becomes ISO 13485 Clause 7.3
For nearly three decades, 21 CFR 820.30 defined design controls for U.S. medical device manufacturers. Its structure (design and development planning, input, output, review, verification, validation, transfer, changes and the design history file) shaped how an entire industry organized engineering documentation. On 2 February 2026, 820.30 ceased to exist. Under the Quality Management System Regulation (QMSR), design controls are now governed by ISO 13485:2016 clause 7.3, incorporated by reference into 21 CFR Part 820.
The substance is similar. The details are not. Terminology changed, some requirements became more explicit, and several FDA-specific concepts, including the Design History File (DHF), were retired as regulatory terms. For regulatory affairs and quality teams, the risk lies in assuming that a QSR-compliant design control process is automatically QMSR-compliant. This article maps the differences and explains what needs to change.
Which Devices Are Subject to Design Controls?
The QMSR preserved the scope of design control applicability from the QSR. Under 21 CFR 820.10(c), the design and development requirements of ISO 13485 clause 7.3 apply to:
all Class II and Class III devices; and
the following Class I devices: devices automated with computer software; tracheobronchial suction catheters; surgeon's gloves; protective restraints; manual radionuclide applicator systems; and radionuclide teletherapy sources.
Other Class I devices remain exempt from design control requirements, even though ISO 13485 itself does not provide such an exemption. Manufacturers certified to ISO 13485 for other markets will typically apply clause 7.3 to all devices anyway.
Clause-by-Clause: QSR 820.30 vs. ISO 13485 Clause 7.3
Design and development planning (7.3.2)
Like 820.30(b), ISO 13485 requires planning and control of design and development. Clause 7.3.2 is more specific about content: plans must document the design and development stages; the reviews needed at each stage; verification, validation and design transfer activities; responsibilities and authorities; methods to ensure traceability of design outputs to design inputs; and the resources needed, including necessary competence of personnel. The explicit requirement for traceability methods and resource and competence planning is new in regulatory terms for U.S.-only manufacturers.
Design and development inputs (7.3.3)
ISO 13485 lists required input categories: functional, performance, usability and safety requirements according to intended use; applicable regulatory requirements and standards; applicable outputs of risk management; information derived from previous similar designs, as appropriate; and other requirements essential for design and development. Inputs must be reviewed for adequacy and approved, and requirements must be complete, unambiguous, able to be verified or validated, and not in conflict with each other.
Compared with 820.30(c), the explicit inclusion of usability requirements and risk management outputs as inputs is a meaningful change. Investigators will look for evidence that risk controls from the ISO 14971 file became design inputs, and that usability engineering (typically under IEC 62366-1) generated requirements.
Design and development outputs (7.3.4)
Outputs must meet input requirements, provide appropriate information for purchasing, production and service provision, contain or reference product acceptance criteria, and specify product characteristics essential for safe and proper use. Outputs must be in a form suitable for verification against inputs and approved before release. This closely mirrors 820.30(d).
Design and development review (7.3.5)
Systematic reviews must be performed at suitable stages, according to planned arrangements, to evaluate the ability of the results to meet requirements and to identify and propose necessary actions. Participants must include representatives of functions concerned with the stage being reviewed, as well as other specialist personnel. The QSR's explicit requirement for "an individual(s) who does not have direct responsibility for the design stage being reviewed" in 820.30(e) is not stated in the same words in ISO 13485. Many manufacturers retain the independent reviewer requirement in their procedures as a good practice, and doing so remains advisable.
Design and development verification (7.3.6)
Verification must be performed according to planned and documented arrangements to ensure outputs meet inputs. ISO 13485 is more explicit than the QSR about verification plans: they must include methods, acceptance criteria and, as appropriate, statistical techniques with rationale for sample size. If the intended use requires the device to be connected to or interface with other devices, verification must include confirmation that design outputs meet inputs when so connected or interfaced.
Design and development validation (7.3.7)
Validation must be performed on representative product (initial production units, batches or their equivalents), with the rationale for the choice of product documented. Validation must include clinical evaluations or performance evaluations of the device in accordance with applicable regulatory requirements. Validation must be completed prior to release of the product for use by the customer. As with verification, validation plans must include methods, acceptance criteria and, as appropriate, statistical techniques with sample size rationale.
The explicit requirement to justify the choice of product used for validation, and to include statistical rationale, closes gaps that were sometimes left open under 820.30(g).
Design and development transfer (7.3.8)
Procedures must ensure that design outputs are verified as suitable for manufacturing before becoming final production specifications and that production capability can meet product requirements. This is more demanding than 820.30(h), which required only procedures to ensure the design is correctly translated into production specifications. The expectation that production capability is demonstrated links design transfer directly to process validation.
Control of design and development changes (7.3.9)
Changes must be identified, and the organization must determine the significance of the change to function, performance, usability, safety and applicable regulatory requirements for the device and its intended use. Changes must be reviewed, verified, validated as appropriate, and approved before implementation. The review must include evaluation of the effect of the changes on constituent parts and product in process or already delivered, and on inputs or outputs of risk management and product realization processes.
The explicit requirement to assess the effect on regulatory requirements makes regulatory affairs a necessary participant in design change review. It also connects directly to the decision on whether a change requires a new 510(k), a PMA supplement, or other regulatory action.
Design and development files (7.3.10)
ISO 13485 requires a design and development file for each medical device type or family, including or referencing records generated to demonstrate conformity to the design and development requirements and records for design and development changes. This replaces the QSR's "Design History File." The content is substantially the same, so existing DHF records can generally be carried forward into the design and development file. However, procedures, templates and training should be updated to use current terminology.
Related Terminology Changes
The retirement of QSR terms affects more than design controls:
Device Master Record (DMR) is replaced by the medical device file under ISO 13485 clause 4.2.3, which covers the general description and intended use, labeling, product specifications, specifications for manufacturing, packaging, storage, handling and distribution, measuring and monitoring procedures, installation and servicing requirements where applicable.
Device History Record (DHR) is replaced by records required under clause 7.5.1 and the batch or device record requirements of clause 7.5.1 and 7.5.8 (identification) and 7.5.9 (traceability).
Quality System Record is subsumed into ISO 13485 documentation requirements under clause 4.2.
The QMSR also clarifies, in its definitions provisions, that where terms in ISO 13485 conflict with definitions in the FD&C Act or FDA regulations, the FDA definitions prevail. For example, "manufacturer" and "product" retain their FDA meanings.
What FDA Investigators Look For
FDA's new inspection approach under the QMSR, which replaced the Quality System Inspection Technique, follows risk through the QMS rather than auditing each subsystem in isolation. In design controls, the practical focus areas include:
Traceability. Can the manufacturer show a trace from user needs and risk controls to inputs, outputs, verification and validation?
Risk integration. Do risk management outputs appear as design inputs, and were risk controls verified for implementation and effectiveness?
Usability. Were usability requirements captured, and was summative evaluation performed with representative users in representative conditions?
Statistical rationale. Do verification and validation plans justify sample sizes and acceptance criteria?
Design change control. Are changes assessed for their effect on risk, regulatory status and product already delivered?
Software. For device software, is the development lifecycle consistent with IEC 62304 and FDA's guidance on content of premarket submissions for device software functions?
A Practical Transition Checklist
Update procedures and templates to reference ISO 13485 clause 7.3 and use current terminology (design and development file, medical device file).
Add explicit traceability methods to design plans, and verify that trace matrices are complete for active projects.
Make risk outputs visible as inputs. Add a column or link in the input specification referencing the risk control each input implements.
Require statistical rationale for sample sizes and acceptance criteria in verification and validation protocols.
Document the rationale for validation product selection, especially where pilot builds are used.
Strengthen design transfer by linking it to process validation and a demonstration of production capability.
Add regulatory assessment to design change review, with RA sign-off for changes that could affect regulatory status.
Retain the independent reviewer in design reviews as a best practice.
Review legacy DHFs for high-risk devices still in production and create gap assessments for missing elements, prioritizing devices with active design changes.
Train engineering staff on the changes, since they generate most design records.
Worked Example: A Traceable Design Record
Traceability is easiest to understand through a single thread. Consider a wearable cardiac monitor with a user need that the patient can apply the device correctly at home without clinical assistance.
User need: patient can correctly apply the device at home.
Risk management output: the risk file identifies incorrect electrode placement as a hazardous situation leading to missed arrhythmia detection. The selected risk controls are an alignment feature molded into the housing (inherently safe design), an in-app placement check using signal quality (protective measure), and illustrated instructions (information for safety).
Design inputs: the housing shall physically prevent placement rotated more than 15 degrees from the intended orientation; the app shall detect insufficient signal quality within 60 seconds of application and prompt the user to reposition; the instructions shall enable 95% of representative lay users to apply the device correctly in summative usability testing.
Design outputs: housing drawing with alignment feature dimensions; software requirements specification and code for the signal quality check; instructions for use document.
Verification: dimensional inspection of the alignment feature; software verification of the signal quality algorithm against a defined test signal set with a documented sample size rationale; readability review of the instructions.
Validation: summative usability study with representative lay users in a simulated home environment, using production-equivalent devices, with the rationale for using production-equivalent units documented.
Risk control verification: the risk file records that each control was implemented and that the summative study demonstrated effectiveness.
Each link in this chain should be visible in the design and development file without relying on the memory of the engineers involved. An investigator following this thread will ask to see each record in turn.
Software, Combination Products and Special Cases
Device software
For device software, ISO 13485 clause 7.3 operates alongside IEC 62304, which FDA recognizes as a consensus standard. FDA's 2023 guidance on the content of premarket submissions for device software functions describes documentation levels (Basic and Enhanced) based on risk. The design and development file for software should contain the software development plan, requirements, architecture, detailed design where applicable, verification at unit, integration and system level, anomaly lists and configuration management records, consistent with the documentation level.
Combination products
Under 21 CFR Part 4, manufacturers of combination products can demonstrate compliance with CGMP through a streamlined approach, applying either the drug CGMPs or the device quality system requirements as the base and adding specific provisions from the other. For drug-led combination products, the device design control requirements must still be applied. Part 4 was amended alongside the QMSR so that its references to Part 820 point to the new provisions, including the design and development requirements of ISO 13485 clause 7.3 as incorporated. Teams responsible for drug-device combination products should review their Part 4 compliance approach against the updated references.
Outsourced design
Where design activities are outsourced to a design firm or contract developer, the manufacturer remains responsible for design controls. ISO 13485 clause 4.1.5 requires control of outsourced processes proportionate to risk, and the quality agreement should specify how design records are generated, reviewed, approved and transferred into the manufacturer's design and development file.
The Bottom Line
ISO 13485 clause 7.3 will feel familiar to any engineer who worked under 820.30. But the QMSR brings sharper expectations on traceability, risk integration, usability, statistical rationale and production capability at transfer, and it makes regulatory assessment an explicit part of design change control. The manufacturers that adapt best are those that treat the transition as an opportunity to tighten the connections between design, risk and regulatory decision-making rather than a terminology exercise.
Sources
21 CFR Part 820 (QMSR), including 820.3, 820.7 and 820.10(c); final rule 89 FR 7496 (2 February 2024)
ISO 13485:2016, clauses 4.2.3, 7.3 and 7.5
FDA, Quality Management System Regulation frequently asked questions: fda.gov
IEC 62304:2006+A1:2015, Medical device software – Software life cycle processes
IEC 62366-1:2015+A1:2020, Application of usability engineering to medical devices
ISO 14971:2019, Application of risk management to medical devices
Comments