FDA 483 Citations for Design Controls Under 21 CFR 820.30

Design controls do not draw the single most frequent device citation, but taken together they are one of the largest groups. In fiscal year 2025, FDA investigators cited 21 CFR 820.30 on system-generated Form FDA 483s with these observations:

• "Procedures for design change have not been [adequately] established," 820.30(i), 48 times

• "Risk analysis [was not performed] [is inadequate] [is incomplete]," 820.30(g), 47 times

• "Procedures for design control have not been established," 820.30(a), 40 times

• "Procedures for design validation have not been [adequately] established," 820.30(g), 32 times

• "The design history file [was not established] [does not demonstrate that the design was developed following the approved design plan] ...," 820.30(j), 30 times

Design problems are hard to fix after launch because they are built into every unit. That is why FDA focuses on whether changes, risks and validation are controlled.

What the citations mean

Design change, 820.30(i)

Investigators usually find changes made to released designs without documented identification, verification or validation, review and approval. Common examples are drawing revisions without impact assessment, software updates released without regression testing and supplier-driven component changes that bypassed design review.

Risk analysis, 820.30(g)

FDA expects risk analysis to be part of design validation. Citations describe missing risk files, analyses that ignore use errors or software, risk controls with no verification of effectiveness, and risk files never updated after complaints or design changes.

Design control procedures, 820.30(a)

This citation usually means a firm making a device subject to design controls has no procedures at all. It often appears at small companies, startups and firms that acquired a product.

Design validation, 820.30(g)

Examples include validation performed on prototypes rather than initial production units, validation not done under actual or simulated use conditions, missing software validation and no validation of user needs.

Design history file, 820.30(j)

The DHF is missing, or it cannot show that the design was developed according to the plan and the regulation.

What 21 CFR 820.30 required

Under the Quality System Regulation, manufacturers of Class II and Class III devices, and certain Class I devices, had to establish procedures to control device design. The section covered design and development planning (b), design input (c), design output (d), design review (e), design verification (f), design validation (g), design transfer (h), design changes (i) and the design history file (j).

Design validation under 820.30(g) had to be performed under defined operating conditions on initial production units, lots or batches, or their equivalents, under actual or simulated use conditions. It had to ensure devices conform to defined user needs and intended uses, and include software validation and risk analysis where appropriate. Design changes under 820.30(i) required procedures for the identification, documentation, validation or where appropriate verification, review and approval of design changes before implementation.

What changed under QMSR

Under QMSR, in effect since February 2, 2026, design requirements come from ISO 13485:2016 clause 7.3, Design and development, which covers planning (7.3.2), inputs (7.3.3), outputs (7.3.4), review (7.3.5), verification (7.3.6), validation (7.3.7), transfer (7.3.8), control of changes (7.3.9) and design and development files (7.3.10).

Some differences matter for responses:

• Risk management is required across product realization. ISO 13485 clause 7.1 requires documented requirements for risk management throughout product realization, so risk is no longer only part of design validation.

• Design changes must be evaluated for their effect on constituent parts, product in process or already delivered, inputs and outputs, risk management and regulatory requirements (7.3.9).

• Design validation must be performed on representative product, with the rationale for the choice documented, and must include clinical or performance evaluation as required (7.3.7).

• The design and development file (7.3.10) replaces the DHF term and must include or reference records that demonstrate conformity with design requirements and records of changes.

How to respond to the 483

FDA generally considers responses received within 15 business days of the close of the inspection before deciding on further action. Design remediation usually takes months, so your response must show a credible plan.

Assess risk to products on the market

Start with the cited products. If a change was made without validation, or risk analysis is incomplete, evaluate whether marketed devices are affected and whether any field action is needed.

Remediate the cited design files

Complete the missing design change records, risk analysis or validation for each product cited. Many firms build a remediation plan per product with deliverables and dates.

Fix the design control system

• Design control procedures covering every element of ISO 13485 clause 7.3

• A design change procedure that requires impact assessment, verification or validation, risk file updates and approval before release

• A risk management procedure aligned with ISO 14971, which FDA recognizes as a consensus standard

• Design validation requirements, including representative product, use conditions, software and usability

• A design and development file structure for every product

Review all marketed products

Review the design files for every product on the market against the revised procedures. Prioritize by risk and report the plan and schedule to FDA.

What compliant design control procedures must contain

• Design and development planning

• Design inputs, including user needs, regulatory and risk requirements

• Design outputs and acceptance criteria

• Design reviews with independent reviewers

• Design verification and design validation

• Design transfer to production

• Design change control with impact assessment

• Risk management throughout the life cycle

• Design and development file contents

• Records

Common mistakes in design control responses

• Writing a new procedure but leaving existing product files unremediated

• Treating risk analysis as a one-time document that is never updated

• Validating with engineering prototypes instead of production-equivalent units

• Handling design changes through document control alone, without design review

• Underestimating the time remediation will take, then missing committed dates

Example: how one response section might read

This illustrates structure only; your response must describe your own products and facts.

Observation 8: Procedures for design change have not been adequately established. Specifically, the firmware update released in March was not verified or validated before release.

Response:

• Product assessment: Regression testing and a risk assessment of the March firmware were completed on a stated date. No safety-related defects were found; two minor display issues are being corrected under design change control.

• Root cause: Firmware changes were handled through software release notes outside the design control process.

• Corrective action: The design change procedure was revised to cover software and firmware, require impact assessment on risk, verification and validation, and require design review approval before release.

• Retrospective review: All 38 design changes released in the last three years across five products were reviewed. Seven lacked complete verification; remediation is scheduled product by product, with dates given.

• Training: Engineering, software and quality staff were trained.

• Verification: Design change records will be audited after six months.

Frequently asked questions

Do design controls apply to our device?

Design controls apply to Class II and Class III devices and to certain Class I devices, including devices automated with computer software. Under QMSR, firms should also follow ISO 13485 clause 7.3 for design and development.

Is the design history file still required under QMSR?

ISO 13485 clause 7.3.10 requires a design and development file for each device type or family, which serves the same purpose as the DHF.

Do we have to use ISO 14971 for risk management?

QMSR does not require ISO 14971 by name, but ISO 13485 requires documented risk management, and FDA recognizes ISO 14971 as the consensus standard. Most firms follow it.

How A.P. Lyon documents help

A.P. Lyon's Design Control Procedure for ISO 13485 and FDA QMSR covers planning through transfer, supported by the Design Change Procedure, Design Verification and Validation Procedure and Design Review Procedure. The Design Control Procedure Bundle groups them, and the Risk Management Procedures Bundle covers design and process risk.

Documents are editable Word and Excel files and must be adapted to your products and organization. Design files must still be completed by people who know your devices.

Next steps

• Assess marketed product risk for each design issue cited

• Remediate the cited design files on a dated plan

• Revise design control, change and risk procedures, then review every product

• Respond within 15 business days with the remediation schedule

To build a complete set of procedures at a volume discount, use Build Your QMS. For help with a 483 response, see A.P. Lyon consulting services.

Not sure where your quality system stands? Take the free QMS gap check: about 20 questions, an instant report of your gaps by clause, and the procedures that close each one.