Skip to main content
Medical Devices April 4, 2026

21 CFR Part 820 Design Controls: What FDA Investigators Look For in a QSR Audit

A practical guide to 21 CFR 820.30 design controls and the five sub-elements FDA investigators probe most during QSR audits of medical device manufacturers.

SS
Sam Sammane
Founder & CEO, Aurora TIC | Founder, Qalitex Group

Every year, FDA’s Center for Devices and Radiological Health (CDRH) publishes its ranking of the most frequently cited 483 observations across U.S. medical device facilities. Design controls deficiencies under 21 CFR 820.30 have appeared in the top three on that list for at least six consecutive years. Six years. That kind of consistency doesn’t reflect a gap in the regulation — it reflects a gap in how companies operationalize it.

If you’re preparing for a routine surveillance inspection, a pre-approval inspection (PAI), or pulling your team together after a warning letter, understanding exactly what investigators probe under 820.30 is worth more than any compliance checklist you’ve downloaded from the internet.

What 21 CFR 820.30 Actually Requires

The regulation applies to manufacturers of finished Class II and Class III devices, along with Class I devices that have not been exempted by 21 CFR 820.30(a). Most manufacturers know that part. What trips them up is that 820.30 is not a single requirement — it’s nine discrete sub-elements, each with its own expectations:

  • (a) Design and development planning — a documented plan that assigns responsibilities and describes design activities
  • (b) Design input — requirements relating to the device’s intended use and the needs of all intended user populations
  • (c) Design output — the results of design efforts at each phase, with defined acceptance criteria
  • (d) Design review — formal documented reviews at appropriate stages, conducted by representatives from all relevant functions
  • (e) Design verification — confirming that design outputs meet design inputs (“does it meet spec?”)
  • (f) Design validation — confirming the finished device meets user needs and intended use (“does it actually work for real users?”)
  • (g) Design transfer — ensuring the design is correctly translated into production specifications
  • (h) Design changes — documentation, review, and approval of changes before implementation
  • (i) Design history file (DHF) — a compiled record demonstrating the device was developed per the approved plan

Investigators don’t walk through these in order. They typically start with the DHF and work backwards. If the DHF is incomplete, they operate on the assumption that the activities never happened — and they’ll write it that way.

The Five Sub-Elements FDA Investigators Probe Most Aggressively

Based on CDRH inspection trends and warning letters issued between 2021 and 2025, five areas consistently dominate 483 observation reports.

Conflating Verification and Validation (820.30(e) and (f))

This is the single most persistent misunderstanding in device quality systems. Verification answers: “Does the device meet design specifications?” Validation answers: “Does the device meet user needs under real-world conditions?” These are fundamentally different questions.

A manufacturer of a Class II infusion pump that ran bench testing to confirm output flow rates met specification — but never conducted usability validation with clinical nurses in a realistic care environment — has completed verification without completing validation. That’s a 483. FDA expects design validation to incorporate human factors data for interface-heavy devices, software of unknown provenance testing where relevant, and in some cases clinical performance data. The FDA’s 2022 guidance on applying human factors and usability engineering to medical devices reinforced this expectation explicitly, and investigators reference it.

Design Inputs That Can’t Be Tested (820.30(b))

Design inputs must be “appropriate” and “complete.” Investigators look for requirements that are measurable, specific, and traceable all the way to your verification test reports. Inputs like “device shall be durable” or “constructed of biocompatible materials” are insufficient standing alone. Investigators will ask: durable for how many use cycles? Biocompatible per which standard — ISO 10993-1:2018? Which specific test endpoints apply?

We’ve reviewed design history files where the input requirements document runs 40 pages but contains virtually no testable acceptance criteria. That’s 40 pages of legal exposure, not regulatory protection.

Incomplete Design Reviews (820.30(d))

The regulation requires design reviews “at appropriate stages of device design” by individuals who don’t have direct responsibility for the design being reviewed. In practice, investigators look for dated meeting records with attendees listed by function (not just name), open action items tracked to formal closure, and at least one independent reviewer per review event.

Smaller manufacturers often combine design review with design verification sign-off — one meeting, one signature block. That conflation puts both activities at risk during inspection. An investigator can legitimately argue that neither was properly executed.

Design Transfer Gaps (820.30(g))

820.30(g) requires that manufacturers establish procedures to ensure “the device design is correctly translated into production specifications.” The operative word is correctly. Investigators want evidence that pilot production runs were compared against design specifications before commercial production began — and that any discrepancies were formally resolved and documented.

Missing design transfer records are especially common when a company has acquired a device product line post-market. The acquiring entity inherited a product but not a complete design history. If the DHF was fragmented to begin with, transfer records are almost always the first casualty.

Undocumented Design Changes (820.30(h))

Changes made during design — even seemingly minor ones — must be documented, reviewed, and verified or validated before implementation. FDA investigators will compare design input documents against final design outputs and the device master record. Any divergence is open to a 483 if there’s no corresponding change order.

A warning letter issued by CDRH in 2024 cited a manufacturer for making 17 discrete software interface changes to a Class II diagnostic device without completing any design change documentation. All 17 were identified by comparing version-controlled software builds against the design history file — a review any experienced investigator can complete in under three hours.

What a Defensible Design History File Actually Contains

The DHF is the physical artifact that ties everything together. Under 820.30(j), it must contain — or reference — all records necessary to demonstrate the device was developed per the approved design plan. A DHF that holds up under inspection includes:

  1. A master design plan with revision history, assigning responsibilities and defining milestones
  2. Design input requirements document with measurable, traceable acceptance criteria for each requirement
  3. Design output documents — drawings, specifications, software architecture docs — version-controlled and dated
  4. Design review meeting minutes for each formal review stage, with attendee roles listed and open items tracked
  5. Verification protocols and reports for each design input, showing test method, sample size (typically n ≥ 3 for bench studies, though statistically justified sample sizes are stronger), pass/fail criteria, and actual results
  6. Validation protocols and reports, including human factors summaries for user interface-intensive devices
  7. Design transfer protocol or checklist documenting pilot run comparison against design specifications
  8. Design change orders for every modification made during the development lifecycle
  9. Risk management file — FDA increasingly expects ISO 14971-compliant risk documentation directly traceable to design inputs and outputs

If any of those nine elements is absent or references an external document that doesn’t exist in your records system, an investigator can legitimately issue a 483 observation. And they will.

Three Steps to Audit-Ready Design Controls

You don’t need a year-long remediation project to be inspection-ready for design controls. But you do need to be deliberate.

Step 1: Run a DHF gap analysis at least 90 days before an anticipated inspection. Map every element of your current DHF against the nine sub-elements of 820.30 and document what’s missing. This isn’t creating a paper trail of problems — it’s generating a prioritized remediation list. CDRH investigators consistently respond better to companies that have identified gaps and are actively closing them than to companies that claim everything is complete and clearly aren’t.

Step 2: Conduct an independent design review mock-up. Bring in a senior engineer and a quality professional who had no direct involvement in the original design. Hand them the design inputs document and the design outputs package and ask them to verify traceability without help. If they can’t draw a clear, unbroken line from stated user need to design input to design output to verification test result, your traceability matrix needs work before FDA gets that same exercise.

Step 3: Audit your design change process against recent history. Select three to five design changes made in the past 18 months and walk each one through your current change control SOP. Confirm that every change was documented, reviewed, and validated or verified per 820.30(h) before it was implemented. Informal changes — made verbally, in email threads, or in unmarked redlines — are among the highest-risk findings during inspection. Identify them and remediate proactively.

Companies that bring in regulatory compliance consulting services during the pre-inspection window — not after receiving a 483 — close design control gaps faster and with fewer downstream consequences. The cost of a thorough mock audit is reliably lower than the cost of responding to a warning letter.


Written by Sam Sammane, Founder & CEO, Aurora TIC. Learn more about our team

Talk to our compliance consultants — we help medical device manufacturers identify and close design control gaps before FDA does. Contact us

Need Help Choosing the Right Lab?

Aurora TIC matches manufacturers and brands with accredited testing laboratories — fast, free, and tailored to your product.

Get a Free Quote