Design controls that survive audit: a practitioner's guide to 21 CFR 820.30

Design controls under 21 CFR 820.30 are not a paperwork exercise. The regulation lists eight elements — design and development planning, design input, design output, design review, design verification, design validation, design transfer, design changes — plus the design history file. The list is short. The architectural decisions behind a design-controls system that holds up under FDA inspection are not.

This is a working note on what those decisions are, what the most common failure patterns look like, and how to architect a design-controls system whose evidence is generated as the work happens rather than curated before an inspection.

The eight elements of 820.30

The structural anchor of design controls is 21 CFR 820.30, which lists eight elements plus the design history file. Each element has a specific scope and a specific evidence requirement:

• 820.30(b) Design and development planning. Plans that describe or reference design and development activities, define responsibility, and identify interfaces with other groups. Updated as design evolves.
• 820.30(c) Design input. Procedures ensuring design inputs are appropriate to the device, address user/patient needs, and resolve incomplete, ambiguous, or conflicting requirements. Documented, reviewed, and approved.
• 820.30(d) Design output. Procedures defining and documenting design outputs in terms that allow adequate evaluation for conformance to design input requirements. Outputs essential to the proper functioning of the device must be identified.
• 820.30(e) Design review. Procedures ensuring formal documented reviews are planned and conducted at appropriate stages. Reviews include independent reviewers and any necessary specialists; results are documented in the DHF.
• 820.30(f) Design verification. Procedures confirming design output meets design input requirements. Results documented in the DHF, including identification of the design, method(s), date, and individual(s) performing verification.
• 820.30(g) Design validation. Procedures ensuring devices conform to defined user needs and intended uses, including testing under actual or simulated use conditions, on initial production units (or equivalents). Includes software validation and risk analysis where appropriate.
• 820.30(h) Design transfer. Procedures ensuring the device design is correctly translated into production specifications.
• 820.30(i) Design changes. Procedures for identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation.
• 820.30(j) Design history file. A DHF for each type of device, containing or referencing the records necessary to demonstrate the design was developed in accordance with the approved design plan and the requirements of this section.

What "structural integrity" means

A design-controls system has structural integrity when each element of 820.30 produces evidence that traces — without retroactive curation — to the elements upstream and downstream of it. In practice:

• Forward traceability: every user need traces to one or more design inputs; every design input traces to one or more design outputs; every design output traces to verification and (for the device as a whole) validation evidence; every change traces back to the affected inputs, outputs, and re-verification.
• Backward traceability: every design output references the design input(s) it implements; every verification record references the design input verified; every validation record references the user need validated.
• Risk traceability: every risk control measure (per ISO 14971) is implemented as a design input or output, has verification evidence, and has post-production input feedback.

Structural integrity is what makes the difference between a DHF that an inspector can navigate fluently and one that requires the program owner to narrate the connections.

The four common failure patterns

1. The retroactively-assembled DHF

The DHF is assembled in the weeks or months before submission or inspection, by someone who was not in the design decisions, from records that were generated for other purposes. The assembly itself becomes the only evidence; the index points at records that exist but were not generated as design-controls evidence. Inspectors recognize this pattern quickly — the gap between the index and the records is visible in the records themselves (different revision styles, different approval signatures, different naming conventions across the same purported workstream).

2. The traceability matrix that doesn't close

A traceability matrix exists but has gaps: design inputs without design outputs, design outputs without verification, verifications without validation, or risk controls without verification. The matrix gives the appearance of structure without the substance. The fix is not a better matrix — it is the closure of each gap as it appears, throughout development, with explicit gate criteria that prevent gaps from compounding.

3. The risk file as a parallel deliverable

Risk management (per ISO 14971:2019) is run as a parallel work stream by the QA function, with risk controls listed in the risk file but not propagated into the requirements document. When requirements change, the controls do not track; when changes propagate through 820.30(i), the risk file is not updated; when post-production input arrives (per ISO 14971 §10), it does not feed back into the next round of design inputs. The risk file becomes a compliance artifact rather than a forcing function.

4. The change-control system that doesn't see scope

Design changes (820.30(i)) are tracked, but the impact assessment scopes too narrowly — a change to one component is evaluated only against the directly-affected requirements, not against the broader risk file, validation evidence, or supplier-controlled processes. This pattern is especially common at the device-drug interface in combination products, where a device change can affect drug constituent specifications without obviously touching them.

An architecture that survives audit

The architecture that holds up under coordinated inspection has six properties:

1. One traceability spine. User needs, design inputs, design outputs, verification, validation, risk hazards, and risk controls all carry IDs that reference each other. The spine is the audit trail; the DHF is the index over the spine.
2. Approval-time discipline on inputs. Each design input ships through 820.30(c) approval with a verification approach and acceptance criterion already attached. Verification is a generated artifact, not a curated one.
3. Risk integration into requirements. Risk control measures are expressed as design inputs (or constraints) in the requirements document, not as a parallel section of the risk file. The risk file analyzes; the requirements document constrains.
4. Cross-disciplinary design reviews (820.30(e)). Reviews include independent reviewers and any necessary specialists, and the review record captures decisions, action items, and approval — not just attendance.
5. Tight change control with broad impact assessment. Each change scope-asses against the full requirements set, the risk file, validation evidence, and supplier-controlled processes — not only the directly-touched component.
6. Incremental DHF construction. The DHF is built as work happens, not assembled before inspection. The design-controls procedures specify what records belong in the DHF and where; the DHF index is generated, not authored.

The ISO 13485:2016 overlay

Most US-regulated programs operate against both 21 CFR 820 and ISO 13485:2016. The two frameworks were harmonized in the FDA's 2024 final rule that incorporates ISO 13485:2016 by reference into the Quality Management System Regulation (the new name for what was called the QSR). The harmonization aligns the structural elements but does not eliminate the regulation-by-regulation differences.

ISO 13485:2016 §7.3 covers design and development with elements broadly similar to 820.30 — 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), and change control (§7.3.9). ISO 13485 adds explicit requirements for a design and development file (§7.3.10) that captures the records of the design and development activities and is broadly equivalent to the DHF.

For most programs, the practical question is not which framework to anchor on but how to operate against both with one integrated system. The system that satisfies 820.30 with structural integrity will also satisfy ISO 13485 §7.3 — the additional ISO 13485 requirements (the design file, the more explicit risk-management integration) are largely satisfied as a side effect of doing 820.30 well.

Practitioner summary

Design controls under 21 CFR 820.30 are the operating model of a regulated-product development program, not a deliverable layered on top. Programs that treat them as the operating model produce audit-ready DHFs as a side effect of doing the engineering work; programs that treat them as a deliverable pay the cost in retroactive curation, traceability gaps, and 483 findings under 820.30(j).

The four common failure patterns — retroactively-assembled DHF, traceability matrix that doesn't close, risk file as parallel deliverable, narrow-scope change control — are recognizable from their shape long before an inspector arrives. The architectural fix in each case is to make design-controls work the medium through which design decisions are made.

For the regulatory and design-controls service area, see Regulatory, Quality & Design Controls. For the user-research-to-design-input translation step, see From user research to verifiable requirements.