Design Controls Under QMSR: The 820.30 to ISO 13485 Clause 7.3 Crosswalk

Design controls didn't go away under the QMSR — they moved. Here's the section-by-section mapping from the old 820.30(a)-(j) to ISO 13485:2016 Clause 7.3, and what's actually different in practice.

Are Design Controls Still Required Under the QMSR?

Yes — design controls are still required, but the citation and structure changed. What used to live in a single, self-contained section, 21 CFR 820.30, now lives in ISO 13485:2016 Clause 7.3, incorporated into the QMSR by reference. The good news for manufacturers with a mature design controls process: the mapping between the old subparts and the new clauses is close to one-to-one, ten old provisions to ten new subclauses, covering essentially the same activities in the same logical order. The work is verifying your process and records actually satisfy the ISO clause language, not just relabeling a binder.

How Do the Old 820.30 Design Controls Map to ISO 13485 Clause 7.3?

The crosswalk between the old design controls subparts and the new ISO 13485 subclauses is the cleanest mapping anywhere in the QMSR transition:

If your design controls procedure is currently organized around the (a) through (j) lettering, restructuring it around 7.3.1 through 7.3.10 is largely a renumbering exercise — the content requirements at each step are substantively similar.

What's Actually Different in Practice, Not Just in Numbering?

The renumbering is the easy part. A few substantive differences are worth checking against your actual process, not just your procedure headers:

Risk management is explicitly woven through the whole clause, not appended to it. ISO 13485 Clause 7.1 requires risk management, referencing ISO 14971, to be applied throughout product realization — including design and development. The old 820.30 expected risk analysis as good practice, but didn't tie it into the design controls section as explicitly as Clause 7.3 does in combination with 7.1. If your design risk management activity lives in a separate procedure that isn't cross-referenced from your design controls procedure, that's a gap worth closing.

Design and development planning must be more explicitly interdisciplinary. Clause 7.3.2 requires design and development planning to define the organizational and technical interfaces between different groups involved in design and development, and to update planning outputs as the project progresses — language that's more specific than the old 820.30(b) planning requirement, even though well-run design projects were already doing this.

The design and development file (7.3.10) has the same substance as the DHF, different framing. ISO 13485 doesn't use the term "Design History File" — it requires a "design and development file" for each device type or family, containing or referencing records generated to demonstrate conformity to Clause 7.3. In practice, this covers the same content a compliant DHF already contains: design plan, inputs, outputs, review records, verification and validation evidence, transfer records, and change history. FDA's guidance on the transition has indicated that the DHF concept and its content requirements carry forward under the new terminology — you don't need a new document, you need your existing DHF structure checked against the 7.3.10 requirement.

Design transfer and design change control read almost identically. Clauses 7.3.8 and 7.3.9 track the old 820.30(h) and (i) closely — design transfer must ensure the design is correctly translated into production specifications, and design changes must be identified, reviewed, verified or validated as appropriate, and approved before implementation. If your design change control process already ties into your broader document control system, minimal rework is needed here.

Is the DHF Still Called the DHF Under QMSR?

Informally, yes — most manufacturers and quality professionals continue to use "DHF" as shorthand, and there's nothing in the QMSR that prohibits it. Formally, the requirement is now for a "design and development file" per Clause 7.3.10. The distinction matters for document titling consistency during an inspection: an investigator working from the current regulation may ask about your design and development file, and if your quality manual and procedures haven't been updated to acknowledge the term, that's an avoidable moment of confusion during an otherwise unremarkable interview.

Do You Need to Rebuild Your DHF Structure?

For active design and development projects, yes — new projects opened after the compliance date should be organized around the Clause 7.3 structure from the start. For completed design projects with a DHF that was closed and design-transferred under the old 820.30 framework, a full rebuild generally isn't necessary; the content requirements are substantively equivalent, and retroactively reformatting historical records adds cost without adding compliance value.

What's worth doing regardless of project status:

Update your design controls procedure and DHF index template to reference Clause 7.3.1 through 7.3.10 rather than 820.30(a) through (j).

Verify your risk management procedure is explicitly cross-referenced from your design controls procedure, consistent with Clause 7.1.

Check open, in-progress design projects against the interdisciplinary planning and file-completeness expectations in 7.3.2 and 7.3.10 before they reach design transfer — closing a gap mid-project is far cheaper than discovering it during a post-transfer audit.

For the full picture of what else changed beyond design controls, see the 21 CFR 820 to QMSR comparison, and for a structured way to work through your whole quality system, the QMSR readiness checklist.

Coplain's AI Job Aid Builder helps design and quality teams convert existing design control procedures and DHF templates into current, ISO 13485-mapped documentation without rebuilding from a blank page. Free trial at coplain.com.

Frequently Asked Questions

Q: Does the QMSR eliminate the requirement for design controls?

A: No. Design controls are still required for every design-responsible manufacturer — the requirement moved from 21 CFR 820.30 to ISO 13485:2016 Clause 7.3, incorporated into the QMSR by reference, with substantively similar content.

Q: Is there still a Design History File under the QMSR?

A: The formal ISO 13485 term is "design and development file" (Clause 7.3.10), covering the same content the DHF historically contained. Most manufacturers continue to use "DHF" informally, and FDA's transition guidance indicates the underlying content requirement carries forward.

Q: Do I need to rebuild completed DHFs to match the new clause numbering?

A: Generally no. Completed design projects with a DHF closed under the old 820.30 framework don't need retroactive reformatting. Update your procedure and templates going forward for new and in-progress projects.

Q: What's the most commonly missed requirement in the transition to Clause 7.3?

A: The explicit tie to risk management under Clause 7.1 and ISO 14971. Design controls procedures that don't cross-reference a documented risk management process are the most frequent gap found in QMSR design controls transitions.

Stop reading about better documentation. Start creating it.

Coplain turns any work instruction into a print-ready, audit-proof job aid in minutes.