Medical Device
Design controls evidence package: what auditors ask for
How to assemble a design-controls evidence package from a living system of record — DHF/DDF expectations under QMSR, what belongs in the package, and how to avoid the binder fire drill.
Under FDA design controls (and the QMSR / Design and Development File framing), you must show that design inputs, outputs, reviews, verification, validation, and transfer were planned and completed. Teams that treat that as a binder assembled before inspection recreate the evidence every time. Teams that treat it as a report from the system of record generate it from current records.
This guide is about the package itself — what to include and how a connected ALM should produce it — not legal advice for your QMS.
What the package usually contains
Exact contents follow your SOP, but inspectors commonly expect a coherent set of:
- Design plan and design-control procedures (controlled docs)
- Design inputs — user needs, requirements, standards
- Design outputs — specifications, architecture, BOM/SBOM where relevant
- Design reviews — attendees, decisions, open items
- Verification — protocols, results, coverage against inputs
- Validation — where applicable (user / clinical / process)
- Risk management file — aligned to ISO 14971
- Design transfer and change history
- Approvals / signatures — attributable where Part 11 applies (electronic signatures)
If those artifacts live in five tools, the “package” is a zip of exports. If they live on one thread, the package is a generated view plus signed baselines.
Living evidence vs copied evidence
| Approach | Strength | Failure mode |
|---|---|---|
| Manual DHF binder | Familiar to quality | Drift the day after assembly |
| Document control only | Strong doc identity | Weak link to tests/risks |
| System-of-record reports + baselines | Current coverage and history | Requires authoring discipline in the tool |
Prefer baselines and signed releases for “what was approved,” and live coverage views for “are we still complete.” See Releases and Reports.
How to build the package from the thread
- Freeze a named baseline of requirements, architecture, tests, and risk for the design under review.
- Run coverage / RTM reports for verification gaps (what is an RTM).
- Attach or generate review and signature history for controlled transitions.
- Include risk file excerpts with residual-risk acceptance.
- Include SBOM attestation when cybersecurity design controls apply.
- Export to Word/PDF/Excel for the submission or inspection room (export paths).
Evaluation questions for tooling
- Can we regenerate last release’s design-control evidence from live data in under a day?
- Are reviews and e-signatures on the same records as requirements and tests?
- Does change control show what became suspect after a design input change?
Related reading
See traceability work as one connected system.
Requirements, architecture, tests, risk, and SBOM on a single thread — audit-ready when you need it.