Last Updated on September 25, 2025 by Melissa Lazaro

Introduction: Why the Design History File (DHF) Matters

One of the biggest pain points I see with medical device companies is this: “We know ISO 13485 requires design controls, but what exactly should go into the Design History File?” And honestly, it’s a fair question. The DHF can feel like a black box—especially for startups or teams going through their first certification or FDA audit.

Here’s the reality: the Design History File (DHF) isn’t just a stack of documents to satisfy auditors. It’s the story of your product’s design journey—proof that you followed a structured, compliant process from concept all the way to transfer into production. If it’s sloppy, missing sections, or pulled together at the last minute, it almost always triggers audit findings.

In my experience, the companies that get the DHF right see two big benefits:

1. Audit readiness — auditors can easily trace how design inputs turned into outputs, reviews, and validations.

2. Internal clarity — engineers, QA, and management all stay aligned because the file acts like a single source of truth.

So in this guide, I’ll break down what the DHF really is, the core elements it must contain, and share a practical Design History File template you can adapt. Along the way, I’ll highlight common pitfalls I’ve seen (and how to avoid them) so your DHF becomes an asset—not a burden—when the auditor comes knocking.

What Is a Design History File?

At its core, the Design History File (DHF) is a collection of records that shows your device was developed according to your design and development plan, ISO 13485 requirements, and any applicable regulations like FDA 21 CFR 820.30(j).

Think of it as the storyboard of your design process. It connects the dots from idea → requirements → design → verification → validation → production. Auditors and regulators use it to check one simple thing: Did you actually follow a structured, compliant design process?

Here’s what I’ve noticed: many teams confuse the DHF with other files. Let’s clear that up:

• DHF (Design History File): Product-specific record of how you developed a device.

• Design & Development Procedure: A system-level SOP describing your general process.

• Technical File (EU MDR): Regulatory submission package with product info, risk management, and testing.

• DMR (Device Master Record): The “recipe” for making the device consistently (manufacturing instructions, specs, etc.).

Pro Tip: Keep in mind the DHF is product-specific. Each device (or product family) needs its own DHF.

Common pitfall: Treating the DHF as an afterthought. I’ve seen companies scramble at the end of development, dumping documents into a folder right before an audit. Auditors pick up on that instantly—it usually results in findings for “incomplete” or “unorganized” DHFs.

Bottom line: the DHF is your evidence trail. If it’s well-structured and up-to-date, it not only satisfies auditors—it makes your design process smoother and more transparent for your own team.

Next, let’s dive into the key elements every compliant DHF should include.

Key Elements of a Compliant DHF

So, what actually goes into a Design History File? In simple terms: all the records that prove you followed a controlled design and development process. Auditors want to see that every stage of design was planned, executed, reviewed, and documented.

Here are the essentials your DHF should contain:

1. Design & Development Plan

• Outlines the project scope, objectives, responsibilities, and timelines.

• Shows you had a roadmap from day one—not just trial and error.
  Pro Tip: Update the plan as the project evolves. A static plan that never changes is a red flag.

2. Design Inputs

• Requirements your device must meet: regulatory, user needs, functional specs.

• Example: “Device must withstand sterilization at 121°C without material degradation.”
  Common pitfall: Inputs that are vague or unmeasurable. Auditors will ask, “How did you verify that?”

3. Design Outputs

• Tangible results of the design process: drawings, BOMs, software code, manufacturing instructions.

• Must be measurable against the inputs.

4. Design Reviews

• Documented checkpoints where cross-functional teams reviewed progress.

• Shows you didn’t just push a design forward blindly.

5. Design Verification

• Evidence that outputs meet inputs.

• Example: test reports showing the product meets dimensional tolerances.

6. Design Validation

• Proof that the final product meets user needs and intended use.

• Often includes clinical evaluation, usability testing, or simulated use testing.

7. Design Transfer

• Records showing the product was successfully handed off to production.

• Example: production readiness checklist, pilot runs.

8. Design Changes

• Documentation of any modifications along the way, with justification and approvals.
  Real-world story: A client avoided a major FDA 483 observation because they clearly documented why they switched suppliers mid-development and how they verified the change.

Pro Tip: Don’t just throw raw data into the DHF. Organize it with summaries, indexes, and references. That way, auditors can easily follow the design story without digging through a mess of files.

Bottom line: if your DHF clearly shows each of these steps—with evidence—you’ve ticked the boxes for both ISO 13485 and FDA design control requirements.

Next, let’s look at a practical DHF template structure you can use as a starting point.

ISO 13485 Design History File Template (Example Structure)

Here’s a practical example of how you can structure your DHF. Use it as a starting point, then adapt it to fit your product and processes.

DHF Template Structure:

1. Title Page (device name, project number, revision, approvals).

2. Table of Contents.

3. Section 1 – Design & Development Plan.

4. Section 2 – Design Inputs.

5. Section 3 – Design Outputs.

6. Section 4 – Design Reviews.

7. Section 5 – Verification Results.

8. Section 6 – Validation Results.

9. Section 7 – Design Transfer.

10. Section 8 – Design Changes & Rationale.

11. Appendices – Supporting data, test reports, risk management links.

Pro Tip: Use a binder or eQMS folder with consistent numbering. It makes it easy for auditors to navigate.

Common pitfall: Treating the DHF as a document dump. Auditors don’t want to wade through hundreds of unlabeled files—they want a clear, traceable story.

Best Practices for Maintaining a DHF

The truth is, most DHF problems don’t come from what gets included, but from how it’s managed over time. I’ve seen teams with all the right documents still fail audits because the file was disorganized, outdated, or incomplete.

Here are some best practices that work in the real world:

5.1 Keep It Updated as You Go

Don’t wait until the end of the project to compile the DHF. Add records as you complete each stage. Auditors can always tell when a DHF was thrown together last-minute—it usually feels messy and inconsistent.

5.2 Use Version Control

Design documents evolve. Make sure every update is versioned and approved so there’s no confusion about which record is the “official” one.
Pro Tip: Keep a revision history table at the start of the DHF for quick reference.

5.3 Make Retrieval Simple

Whether it’s in a binder or an eQMS, the DHF should be easy to navigate. A table of contents, indexing, or consistent folder structure goes a long way.
Real-world example: An auditor once asked a client of mine for a validation report from four years back. Because their DHF was indexed by project phase, they found it in less than two minutes. The auditor literally said, “This is how it should be.”

5.4 Link to Risk Management

ISO 13485 and ISO 14971 go hand in hand. Keep your DHF linked to your risk management file so you can show how risks were identified, mitigated, and verified during design.

5.5 Avoid “Document Dumping”

More isn’t always better. Don’t overload your DHF with every email or draft drawing. Stick to approved, controlled records that add value to the design story.

Bottom line: A well-maintained DHF isn’t just audit-proof—it’s a tool that helps your team stay aligned and makes scaling your product much easier.

FAQs – ISO 13485 Design History File

Q1. Is a DHF required under ISO 13485 or just the FDA?

Good question. The FDA’s QSR (21 CFR 820.30) explicitly requires a DHF, but ISO 13485 also expects you to maintain design and development records that show compliance. In practice, both auditors and regulators expect a DHF, so skipping it isn’t an option.

Q2. Can the DHF be electronic?

Absolutely. In fact, most companies now use an eQMS or structured digital folders to manage their DHFs. Just make sure records are controlled, retrievable, and backed up. Auditors don’t care if it’s on paper or digital—as long as it’s complete and easy to navigate.

Q3. What’s the difference between DHF, DMR, and Technical File?

• DHF (Design History File): How you designed the product.

• DMR (Device Master Record): The “recipe” for how to manufacture it.

• Technical File (EU MDR): The regulatory submission package for EU compliance.
  Think of it this way: DHF = design journey, DMR = manufacturing recipe, Technical File = regulatory dossier.

Conclusion: Make the DHF Work for You

At the end of the day, the Design History File isn’t just a compliance checkbox—it’s your proof that the product was designed properly, with patient safety and regulatory requirements at the center. Done right, it keeps your team aligned, makes audits smoother, and helps you avoid those painful FDA 483s or ISO 13485 nonconformities.

In my experience, the companies that thrive don’t see the DHF as “extra paperwork.” They use it as a living roadmap of their design process. Every input, output, review, and validation builds confidence that the product is safe, effective, and ready for the market.

Here’s the takeaway:

• Know the core elements every DHF must include.

• Keep it organized, version-controlled, and updated as you go.

• Use a clear template so your team isn’t scrambling to figure out what belongs where.

Next step: Download our free ISO 13485 Design History File Template and start customizing it for your device. It’ll save you hours of guesswork and make your next audit a whole lot less stressful.