How to Build a Design History File That Survives FDA Scrutiny (Part I)

Most engineering teams know they need a Design History File. Fewer build one that’s actually defensible when an FDA investigator sits across the table and starts asking questions.

The DHF is the official story of how your device was designed and developed. When it’s done well, it’s a coherent, traceable record that demonstrates every design decision was intentional, every requirement was tested, and every change was reviewed. When it’s done poorly or assembled backward under deadline pressure, it’s a liability.

The challenge is that the DHF isn’t just a filing cabinet. It’s a living record that has to be built in parallel with development, maintained through every design change, and organized so that a reviewer who has never seen your product can follow it. That takes discipline. Most of the DHF failures we see aren’t from teams that didn’t care; they’re from teams that were moving fast, deferring documentation, and assuming they’d clean it up at the end.

This article is about what the DHF actually needs to contain, where most programs fall apart under scrutiny, and the practical habits that make the difference between a file that holds up and one that generates a 483.

---

What the DHF Actually Is and What It Isn’t

The Design History File is the compilation of records that describes the design history of a finished device. Under 820.30(j), the regulation requires manufacturers to “establish and maintain a DHF for each type of device. The DHF shall contain or reference the procedures and results of the design and development activities required” under the design controls subpart.

Two things in that language matter:

• “Contain or reference.” The DHF doesn’t have to store every document physically, but it must index and reference every relevant record. A DHF without a clear index, one that relies on a reviewer to know where to look, is going to create friction.
• “Each type of device.” If you make product variants, you need to understand what constitutes a separate device type versus a variant that’s covered by an existing DHF. Changes with safety or effectiveness implications generally require formal change controls within the existing DHF, or, if the change is substantial, a new DHF.

What the DHF is not is a summary document or a narrative. It’s a primary record; the authoritative source for the design history of your device.

---

What the DHF Must Contain

The design controls section of 820.30 (and the parallel ISO 13485 sections 7.3.2 through 7.3.9) defines the required activities and their associated records. Here’s what the DHF must contain or reference, and what auditors are looking for in each area.

Design Inputs (820.30(c) / ISO 13485 7.3.3)

Design inputs are the physical and performance requirements for the device. They’re translated from user needs, intended use, and applicable regulatory requirements.

What auditors look for:

• Inputs that are specific and verifiable (not “the device should be easy to use”)
• A documented process for how inputs were reviewed and approved
• Evidence that incomplete, ambiguous, or conflicting requirements were resolved before design began
• A starting point for the traceability matrix

Common failure mode: Design inputs that are too high-level to verify against. If your input says “device shall be durable,” you can’t build a test protocol around it. If it says “device housing shall withstand a 1-meter drop onto a concrete surface per IEC 60068-2-32,” you can.

Design Outputs (820.30(d) / ISO 13485 7.3.4)

Design outputs are the results of the design process: the drawings, specifications, software code, assembly procedures, and labeling that define the device. They’re what gets handed off to manufacturing.

What auditors look for:

• A complete set of outputs that, taken together, fully define the finished device
• Evidence that outputs were reviewed and approved before release
• Clear linkage between outputs and the inputs they’re intended to satisfy
• Identification of outputs that are critical to device safety and proper functioning

Common failure mode: Outputs that were updated informally without revision control. A drawing with pencil marks, an assembly procedure that was modified verbally, or a BOM that doesn’t match the latest prototype are all red flags that the output record doesn’t reflect what was actually built.

Design Reviews (820.30(e) / ISO 13485 7.3.5)

Formal design reviews are required at appropriate stages of development. They must be documented, include representation from relevant disciplines, and produce a record that identifies participants, the date, and any required actions.

What auditors look for:

• Evidence that reviews actually happened, not just that a form was signed
• Cross-functional participation (quality, regulatory, and manufacturing represented, not just engineering)
• Action items tracked to closure
• Any concerns raised at the review and how they were resolved

Common failure mode: Design review minutes that look like unanimous consensus every time. Real design reviews surface questions, disagreements, and open items. A record that shows no challenges and no action items rarely reflects what actually happened, and auditors know it.

Design Verification (820.30(f) / ISO 13485 7.3.6)

Verification confirms that design outputs meet design inputs. We’ve covered this in detail in a separate post on design verification vs. validation, but for DHF purposes the critical requirements are:

What auditors look for:

• Test protocols written before testing begins, with acceptance criteria defined in advance
• Traceability from each verification test back to the specific input it’s testing
• Objective test data (not just pass/fail conclusions)
• Documentation of who performed the test, when, and on what units
• Any failed tests and how they were resolved (retesting after a fix must be documented and linked to the change record)

Common failure mode: Acceptance criteria that appear to have been written after seeing the results or results reported without clear criteria at all. The phrase “results were acceptable” with no defined standard is a 483 waiting to happen.

Design Validation (820.30(g) / ISO 13485 7.3.7)

Validation confirms that the device meets user needs and intended use under actual or simulated use conditions. Unlike verification, which is an internal engineering test, validation is an outward-facing evaluation.

What auditors look for:

• Validation performed on initial production units (or their equivalent), not early-stage prototypes
• Representative end-users involved in usability testing
• Clear documentation of the intended use conditions and how they were simulated
• A validated traceability path from user needs through design inputs through validation results
• Rationale for why the validation approach was appropriate for the intended use

Common failure mode: Performing validation on pre-production prototypes. The FDA is explicit that validation must use production-equivalent devices. If a design change occurs after validation begins, that change needs to be assessed against the validation plan, and affected test activities may need to be repeated.

Design Transfer (820.30(h) / ISO 13485 7.3.8)

Design transfer is the documented activity that confirms the design was correctly translated into production specifications, and that manufacturing processes are capable of producing the device to specification.

What auditors look for:

• Evidence that manufacturing reviewed and approved design outputs before production began
• Process validation activities (IQ/OQ/PQ) tied to the transfer
• Any design changes made during transfer and whether they went through formal change control
• Confirmation that the manufactured device matches the design that was verified and validated

Common failure mode: Treating transfer as informal. When engineering “hands off” a design verbally or via email, and manufacturing makes adjustments without documentation, the DHF can’t demonstrate that the manufactured device is identical to the tested device.

Design Changes (820.30(i) / ISO 13485 7.3.9)

Design changes, even small ones, must be formally identified, documented, reviewed, and approved before they’re implemented. The change record must address whether the change requires re-verification or re-validation.

What auditors look for:

• A change control process that actually captures changes before they’re made
• For each change: description, reason, impact assessment, required re-testing, approval
• Evidence that changes didn’t bypass the verification and validation record (i.e., the DHF reflects the device that was actually tested)

Common failure mode: Undocumented changes discovered during audit. If the device on the production floor doesn’t match the most recent approved drawing in the DHF, the program has a documentation integrity problem, and it raises questions about every record in the file.

---

Building a DHF that holds up under FDA scrutiny starts with getting these core records right — and keeping them current as the design evolves. If you’re mid-program and unsure whether your file would survive a review, start a conversation with our team. We’re happy to talk through what we’re seeing on medical device programs and what a defensible DHF looks like in practice.

Stay tuned for Part II!