Audit-ready attestation: what your Design History File actually needs

A DHF needs traceable evidence that every design decision was deliberate, every requirement was verified and every risk was controlled. Volume matters less than auditors think. Integrity matters more than most quality teams document.

If you've ever watched an FDA inspector ask for the change record on a single line of firmware and watched your team scramble for 45 minutes, you already know the gap between "we have a DHF" and "we have an audit-ready DHF."

What 21 CFR 820.30 actually requires

The DHF requirement comes from 21 CFR 820.30(j). The DHF must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of §820.30.

Three words do most of the work in that sentence. Necessary. Demonstrate. Approved.

Necessary means enough evidence to prove design control was followed. Not every email, not every meeting note. Enough.

Demonstrate means an auditor with no prior knowledge of your project must be able to follow the trail from user need to verified output. The trace matrix is the spine. If the spine is broken, nothing else holds up.

Approved means the records reflect the plan that was actually approved at the time. Not the plan you wish you'd had. Backdating documentation is the fastest way to convert a 483 observation into a warning letter.

The seven things auditors check

Across the FDA inspections and notified body audits I've watched, the DHF questions fall into a small set.

1. User needs documented and approved per §820.30(c). Auditors compare the user needs to the labeled indications for use. Mismatches are observations.

2. Design inputs traceable to user needs per §820.30(c). The trace matrix should show every user need decomposed into testable design inputs.

3. Design outputs that meet design inputs per §820.30(d). Outputs include drawings, specifications, code and labeling. The acceptance criteria for each output must be defined and verifiable.

4. Design verification per §820.30(f). Evidence that design outputs meet design inputs. This is where most software DHFs are thin.

5. Design validation per §820.30(g). Evidence that the device meets user needs. Often confused with verification, and the confusion shows up in audits.

6. Design transfer per §820.30(h). Documented procedures for translating design to production. Software DHFs need build process documentation.

7. Design changes per §820.30(i). Every change after design freeze documented, evaluated, verified and approved.

If you can produce evidence for all seven within 30 minutes of an auditor request, you have an audit-ready DHF. If it takes longer than that, you have a DHF.

What "evidence" actually means

The QSR doesn't define a format. The FDA accepts any record that demonstrates the requirement was met, provided the record is contemporaneous, attributable and durable.

That accepts a wide range of formats:

• Test reports with pass/fail records, executed protocols and signed approvals
• Code review records with reviewer identity and date
• Static analysis reports with severity classification and disposition
• Risk management files with hazard identification, control measures and residual risk
• Model performance reports for AI-enabled software with statistical evidence

What the FDA doesn't accept:

• Records reconstructed from memory after an inspection notice
• Records with edits that lack version history
• Test outputs without the test inputs that produced them
• Pass/fail conclusions without the underlying data

The integrity standard is higher than the volume standard. A small DHF with verifiable provenance beats a large DHF with provenance gaps. Every time.

Why cryptographic hashes matter

Modern DHFs increasingly include hash-based attestation. The reason is straightforward. A SHA-256 hash of a verification artifact creates a tamper-evident record that the artifact at attestation time matches the artifact in the DHF.

Three places this matters in practice.

Software builds. Hash the binary, hash the source tree, hash the build environment. The hash proves the validated build matches the released build years later. Without it, "this is the build we tested" is a claim the auditor has to take on faith.

Test datasets. For AI-enabled software, hash the validation dataset and reference the hash in the verification report. If the dataset is questioned during audit, you can prove what was actually tested. Datasets drift. Hashes don't.

Configuration baselines. For complex software systems, hash the configuration files at validation time. Configuration drift is a common audit finding. Hashes detect it before the auditor does.

The hashes themselves aren't magic. The discipline of generating them at the moment of validation, and integrating them procedurally into the DHF, is what makes them defensible.

Trace matrices fail at scale

A 2,000-row Excel file is not a defense against an auditor question. The auditor will find the broken link.

What works at scale is a traceability tool with three properties: bidirectional links from user needs through design inputs, outputs, verification and validation; change tracking on every link with attribution to a user and timestamp; export to a human-readable format for the audit packet.

Most QMS tools claim this. Few execute it well. The signal of a real implementation is whether your team uses the trace matrix during change impact analysis. If they do, it's working. If they only export it for audits, it's broken and you should know that before the inspection.

The IEC 62304 mapping

For medical device software, IEC 62304 maps directly into DHF content. §5.1 software development planning maps to design plan. §5.2 software requirements analysis maps to design inputs. §5.3 software architectural design and §5.4 detailed design map to design outputs. §5.5 unit implementation and verification, §5.6 integration testing and §5.7 system testing map to design verification.

§5.5.2 is where many teams cut corners. Unit verification with documented acceptance criteria is required for Class B and Class C software. "We ran unit tests" is not evidence. "Unit X passed acceptance criteria Y at version Z, executed by reviewer A on date B" is evidence.

The DHF should make this explicit. A unit test report should answer: what was tested, what version of the software, what acceptance criteria, what result, who executed and when. If your reports skip any of those, the gap will surface in inspection.

What's worth doing now

Pick one validated software item from the last year and try to assemble its complete DHF evidence trail in under an hour. Time yourself. The gaps you find are your audit risk, sized in real time.

Audit your traceability tool for bidirectional links. Pick five random design inputs and trace them up to user needs and down to verification evidence. Any breaks are findings waiting to happen.

Add hash-based attestation to your software validation outputs. Start with build artifacts. Expand to test datasets and configurations. The procedural change is small. The audit defense improvement is significant.

The DHF is a living record of your design discipline. It either makes the audit short or it makes the audit a recall. There isn't much in between.

VibeVal returns a SHA-256 attestation hash with every IEC 62304 validation check. The hash covers the diff, the verdict, the rationale, the framework version and the engine version. Drop it into the DHF as tamper-evident evidence. Pay per check.