MSI's ISO 9001/13485 Design and Development procedure template

ISO 9001 and 13485 Integrated Design and Development Procedure Template

$269

One integrated procedure satisfying ISO 9001:2015 Clause 8.3 and ISO 13485:2016 Clause 7.3 simultaneously — for organizations designing both general product and medical devices through the same engineering function. Includes the integration decision record.

ISO 9001:2026 publishes around September 2026. Buy now, get the rebuild free.
This template is built to ISO 9001:2015 — the edition currently in force and the one your certificate is issued against. When the new edition publishes, MSI rebuilds this template against it and sends it to you at no charge. Nothing for you to do: the version stamp in your file is how we know which edition you hold.

What is actually in the document

Both clause sets merged into one document across sixteen numbered sections and four appendices, with device-scope content marked inline and in headings rather than separated. Includes the integration decision record: every place the two standards genuinely diverge, what this procedure does about it, and what the alternative was.

  • 56pages, editable Word
  • 60obligations cross-referenced
  • 31MSI notes and callouts
  • 75marked decisions that are yours
Scope determination comes before anything else. Every project is assigned general, device or uncertain at initiation — and uncertain runs as device scope until Regulatory determines otherwise. The two errors are not symmetrical: running a general project under device scope costs some documentation nobody needed, while running a device project under general scope produces a device whose design history does not exist and cannot be reconstructed afterward.

Three things integrated procedures get wrong

01 · Scope assigned late, or by the wrong person

The commonest failure in an integrated system is a device project running down the general path because scope was assigned by whoever opened the project rather than by someone who could answer the question. The classic case is a component designed to a customer drawing, where the customer incorporates it into a device under a quality agreement nobody in engineering has read. This procedure assigns scope at initiation and gives only Regulatory Affairs the authority to lower it — a role with no delivery date attached to it.

02 · No record of why the two standards were merged the way they were

An integrated procedure that never records its integration decisions looks, to anyone examining it, like a document that merged two standards by accident. Appendix D is eighteen rows of genuine divergence — the controls-clause fan-out, the outputs and review inversion, transfer, the design file, usability, risk management as an input, sampling rationale, representative product, the five-factor change determination — with what this procedure does and what the alternative was.

03 · Applying the looser standard by default

Where the two standards differ, this procedure takes the stricter as the house standard and says so at the point it applies. Design transfer is the clearest case: ISO 13485 requires it, ISO 9001 has no equivalent step, and here it applies to both scopes. That costs the general line a formal step it was not required to have, and it is stated openly in Appendix D so your leadership can reverse it deliberately rather than discover it.

What’s included

  • Everything in both single-standard templates, integrated into one document, editable Microsoft Word
  • An integrated process interaction map, embedded and supplied as an editable SVG, with device interfaces marked
  • A scope determination section with three-way criteria and the uncertain default
  • Device-scope content marked inline and in headings, so the reader never has to work out which standard applies
  • Merged requirement sets at planning, inputs, review, verification, validation, outputs and change control — the union of both standards, stated once
  • Design transfer applied to both scopes, so the general line gets discipline ISO 9001 never required
  • The five-factor significance determination applied to every change, on both scopes
  • A dual clause cross-reference mapping requirements across ISO 9001, ISO 13485 and 21 CFR Part 820
  • Two retention regimes, applied by scope
  • Appendix A — one Design and Development Plan serving both scopes, with device parts conditional
  • Appendix B — combined Review, Transfer and Change Log
  • Appendix C — work instruction with two worked examples, one general and one device, that fail on different factors
  • Appendix D — the Integration Decision Record, with six decisions to confirm before adoption

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

Who it’s for

Organizations running an integrated management system across a device line and a non-device line. Contract design and manufacturing organizations with mixed portfolios. Consultants supporting clients through integration. Anyone maintaining two design procedures who already knows the second one is out of date.

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

What is the integration decision record, and why does it matter?

Appendix D. A row for every place ISO 9001 and ISO 13485 genuinely diverge, what this procedure does, and what the alternative was — followed by six decisions to confirm before you adopt it. It is the evidence that the two standards were merged deliberately rather than by accident, and it is the first thing worth showing when someone asks how one procedure satisfies both.

Is this just the two single-standard templates in one file?

No. Where both standards require the same thing in different words, it is stated once. Where one is stricter, the stricter version is written as the house standard and identified as such at the point it applies. Where a requirement exists in only one, it is marked and left in sequence rather than separated into a device section.

Which one do I need?

This one if one engineering function designs both general product and devices. If you work to only one standard, the single-standard versions are cheaper and shorter.

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.