MSIs ISO 13485 Procedure Template and Guide

ISO 13485 Design and Development Procedure Template and Guide

$169

A complete, editable ISO 13485:2016 Clause 7.3 design control procedure. Covers design transfer, the design and development file, validation on representative product, and the cybersecurity obligations that come from law rather than from the standard.

What is actually in the document

All ten sub-clauses of 7.3 across sixteen numbered sections, three appendices and a device process interaction map. Covers design transfer, the design and development file, verification and validation plan content including sample size rationale, validation on representative product, clinical evaluation, connected-device verification, and the cybersecurity obligations that arise from regulation rather than from any clause.

  • 49pages, editable Word
  • 44obligations cross-referenced
  • 26MSI notes and callouts
  • 72marked decisions that are yours
Since February 2, 2026 this is a regulatory document. The FDA Quality Management System Regulation now incorporates ISO 13485:2016 by reference into 21 CFR Part 820. For devices marketed in the United States your design control procedure is the operative form of a federal requirement, and the records it generates are inspectable.

Three things converted procedures always miss

01 · Design transfer

Clause 7.3.8 has no ISO 9001 equivalent at all. Outputs have to be verified as suitable for manufacturing before they become final production specifications, and production capability has to be shown able to meet the requirements. A procedure converted from a 9001 base does not have this section, because the conversion works clause by clause and there was nothing to convert. The practical consequence is drawings that reach production verified as correct but never assessed as buildable.

02 · The design and development file

Clause 7.3.10 requires one per device type or family. ISO 9001 maps this to generic control of documented information, so it disappears in conversion. A folder convention survives until somebody reorganizes the server; an index that is itself a controlled document survives, and it answers the only question an inspection actually asks — show me the design and development file for this device — in one document rather than in a search.

03 · The sample size rationale

Clauses 7.3.6 and 7.3.7 require verification and validation plans to state methods, acceptance criteria, and where appropriate the statistical techniques with a rationale for sample size. Protocols routinely state three, or five, or thirty, with no basis recorded. The clause asks for the rationale, not the number. In an inspection the question is not whether you tested enough units; it is whether you can show why that number was the right number.

What’s included

  • The complete Clause 7.3 procedure — all ten sub-clauses, sixteen numbered sections, editable Microsoft Word
  • A device process interaction map, embedded and supplied as an editable SVG, with device-scope interfaces marked
  • Design transfer as a gate — suitability for manufacturing and demonstrated production capability, recorded before outputs become final production specifications
  • The design and development file built as a controlled index rather than a folder
  • Risk management output as a design input, with the ISO 14971 interface defined in both directions
  • Usability as a named input, with IEC 62366-1 signposted
  • Verification and validation plan content including acceptance criteria and sample size rationale
  • Validation on representative product, with the rationale for the choice recorded
  • Clinical and performance evaluation, and connected-device verification and validation
  • A cybersecurity module for cyber devices — SBOM, patchability, coordinated vulnerability disclosure and postmarket monitoring, positioned as design inputs and outputs
  • Change control with the five-factor significance determination, including the effect on product already delivered
  • Two retention clocks — device lifetime and the two-year floor at Clause 4.2.5, made explicit
  • A records table with no blanks, and a cross-reference to ISO 13485, 21 CFR Part 820 and FD&C 524B
  • Appendix A — Design and Development Plan with transfer and release gates
  • Appendix B — Design Review, Transfer and Change Log, with a disclosure register
  • Appendix C — work instruction with a worked example: an $11.40 display substitution that passes on function and fails on usability

Every appendix, form, map and worked example is part of the document. Nothing is sold separately.

Who it’s for

Quality and regulatory professionals at medical device manufacturers, contract manufacturers designing under device quality agreements, and consultants supporting device clients. Relevant whether you are certified to ISO 13485, preparing for certification, or adjusting to QMSR.

Not sure yet? The free Design and Development Maturity Check scores eight elements in under five minutes, and your score appears without entering anything.

Questions

Is ISO 13485 really that different from ISO 9001 here?

More than anywhere else in either standard. ISO 9001’s single design controls clause fans out into four separate clauses in ISO 13485. Outputs and review are inverted between the two — outputs sit at 8.3.5 in ISO 9001 and at 7.3.4 in ISO 13485. And design transfer and the design and development file have no ISO 9001 counterpart at all. A find-and-replace adaptation puts the wrong content under the wrong heading, and it is visible to anyone who knows the standard.

Does this cover the FDA cybersecurity requirements?

It covers where they land in the design process. FD&C Act Section 524B has applied to cyber device premarket submissions since March 29, 2023 — a cybersecurity plan, patchability designed in, a software bill of materials covering commercial, open-source and off-the-shelf components, coordinated vulnerability disclosure, and postmarket monitoring. No ISO 13485 clause points at any of it, which is why it is absent from most design procedures. This one treats each obligation as a design input or a design output and says where it sits.

Does it cover the whole standard?

No. It covers Clause 7.3 in full, with the interfaces to 4.2.4, 4.2.5, 7.1, 7.4, 7.5, 8.2.2 and 8.5 identified rather than replaced.

Is this a template or a finished procedure?

Both, deliberately. It is written as a filled-in worked example so you can see what each element looks like when done properly, with bracketed placeholders wherever a value is genuinely yours to set — thresholds, roles, stage names, systems, retention periods. You are editing a working document rather than filling in a hollow outline.

What format is it?

Editable Microsoft Word (.docx), with the process interaction map embedded in the document and supplied separately as an editable SVG. Adapt it, rebrand it, and adopt it into your own document control system.

Will this pass an audit?

A procedure does not pass an audit; an organization does. What this gives you is a procedure that addresses every requirement of the clauses it covers, with a named owner and a named record, describing a process people can actually follow. Conformity is demonstrated by implementation and evidence. Unfilled placeholders are unmet requirements, so fill them.

We use different clause numbering.

Every cross-reference sits in a table at the back rather than baked into the body text, precisely so you can renumber without unpicking the procedure.

I already own MSI’s Design and Development course. Do I need this too?

The course teaches the method — how to get the process out of the heads of the people who do the work. This is the document. Where a form appears in both, this template carries the current revision; the version stamp in the footer tells you which you are holding. The template contains no video.

Can you help us implement it?

Yes. Call MSI at 760-434-9141 to schedule a planning session.