ISO 13485 · Clause 7.3.2 · Design Planning
By Diana Lynn, President and Principal ISO Consultant, MSI · Updated October 8, 2026
Direct Answer
An ISO 13485 design and development plan is the documented roadmap Clause 7.3.2 requires for each device design. It names stages, reviews, verification, validation and transfer activities, responsibilities, the traceability method, and resources, and stays current as the design moves.
An ISO 13485 design and development plan is the documented roadmap Clause 7.3.2 requires for every medical device design project.
Here is how most of them fail in practice, and why a weak ISO 13485 design and development plan costs more than the time it saves.
Month nine of a catheter program, a supplier changes a resin. The change itself is minor. The questions it raises are not: which design outputs does the resin touch, which verification tests prove those outputs still meet their inputs, and who has the authority to decide whether validation has to be repeated?
The engineers know the device cold. What they cannot find is the plan’s answer, because the plan was written in week two to close out a kickoff checklist and has not been opened since.
That is the pattern MSI has seen across 28 years, 200+ audits attended, and 80+ certifications supported. The plan exists. It carries the right headings. And it stops working the first time the project changes, not because the team lacks discipline, but because nobody designed the plan to be used. A plan that fails in practice is still a plan on paper, which is exactly why the problem survives so long.
This guide is about building the other kind. You will see what Clause 7.3.2 actually requires and what it leaves to you, the six patterns that turn an ISO 13485 design and development plan into shelfware, a free six-section template you can copy today, what the FDA’s Quality Management System Regulation (QMSR) changed in 2026, and exactly how a trained internal auditor tests a plan. If you are new to the standard, start with MSI’s ISO 13485 standard overview and come back.
Key Takeaways
- Clause 7.3.2 of ISO 13485:2016 requires six documented planning elements, items a) through f), for each design and development project.
- The plan is a living record: planning documents are maintained and updated, as appropriate, as the design progresses.
- Traceability of outputs to inputs, item e), is the element plans most often leave undefined, in MSI client experience.
- Since February 2, 2026, the FDA QMSR incorporates ISO 13485:2016 by reference, so Clause 7.3 is the operative US design control requirement.
- As of October 2026, ISO 13485:2016 remains the current edition; ISO confirmed it after systematic review on October 31, 2025.
- An internal audit that traces one design output back through the plan is the fastest way to prove a plan works.
The Basics
What Is an ISO 13485 design and development plan?
Plan. Trace. Prove.
Direct Answer
An ISO 13485 design and development plan is project-level: one plan per design project, written within the rules your design and development procedure sets. The procedure (Clause 7.3.1) says how your organization designs. The plan (Clause 7.3.2) says how this project will do it, and it belongs in the design and development file (Clause 7.3.10).
ISO 13485 separates two documents that teams often blur together. Clause 7.3.1 requires documented procedures for design and development, the system-level rules every project follows. Clause 7.3.2 requires the organization to plan and control the design and development of product, with planning documents maintained and updated as the design progresses. For the full clause-by-clause picture of inputs, outputs, reviews, verification, validation, transfer, changes, and files, read MSI’s guide to ISO 13485 design and development. This article zooms in on the planning document itself.
A useful way to hold the distinction: the procedure is the rulebook, and the plan is the game plan. A well-written design and development procedure tells every project team which stages are mandatory, how design reviews are convened, and what records each gate produces. The ISO 13485 design and development plan then applies those rules to one device, with real dates, real names, and real decisions about which verification methods fit this design. MSI’s article on aligning design procedures with company culture explains why the rulebook has to fit the way your engineers actually work.
Where does the plan live?
Clause 7.3.10 requires a design and development file for each medical device type or medical device family. The file contains or references the records that show conformity to design requirements and the records of design changes. The plan, with its revision history, belongs in that file, and the file connects to the medical device file required by Clause 4.2.3. That chain is why a plan that drifts out of date eventually surfaces as a documentation problem far from engineering. MSI’s document control guide explains how to keep revision history meaningful rather than cosmetic.
Does every design change need a new plan?
Not necessarily. Clause 7.3.9 governs design changes and requires the organization to determine the significance of each change to function, performance, usability, safety, and applicable regulatory requirements.
Many organizations scale planning to that significance: a significant change earns its own plan or a formal plan revision, while a minor change is planned inside the change record. Whatever threshold you choose, write it into the procedure. MSI client experience suggests an unwritten threshold is the most common reason change planning varies from one project to the next. MSI’s regulatory change management article covers the same discipline for changes that start outside the company.
The Requirements
What Does Clause 7.3.2 Require in an ISO 13485 design and development plan?
Six. Items. Documented.
Direct Answer
Clause 7.3.2 requires an ISO 13485 design and development plan to document: a) the design and development stages; b) the reviews needed at each stage; c) the verification, validation, and design transfer activities appropriate at each stage; d) responsibilities and authorities; e) methods to trace outputs to inputs; and f) resources, including necessary competence of personnel.
The clause opens with a plain duty to plan and control the design and development of product, then lists six things the planning must document. Each item is short on the page and long in practice. Here is what each one asks for, and what a weak version looks like in a real design file.
a) Design and development stages
Name the stages the project will move through, for example feasibility, design input, design output, verification, validation, and transfer. ISO 13485 does not prescribe a lifecycle model. Stage-gate, waterfall, and iterative approaches all conform when the stages and their controls are documented. The weak version lists stages with no entry or exit criteria, so nobody can say when one ends and the next begins.
b) Reviews needed at each stage
Plan the design reviews each stage needs. Clause 7.3.5 then requires those reviews to follow planned and documented arrangements, to include representatives of the functions concerned with the stage being reviewed plus other experts as needed, and to produce records identifying the design reviewed, the participants, and the date. The weak version says “design reviews as needed,” which plans nothing.
c) Verification, validation, and design transfer activities
Plan the verification, validation, and design transfer activities appropriate to each stage. Notice that transfer sits in the planning list: ISO 13485 expects manufacturability to shape the design before it is frozen, not after. Clause 7.3.6 adds that verification plans document methods, acceptance criteria, and, as appropriate, statistical techniques with a rationale for sample size. Clause 7.3.7 requires validation on representative product, with the choice of product justified. The weak version reads “verification per protocols TBD.”
d) Responsibilities and authorities
Name who does the work and who has the authority to approve stage exits, accept residual risk, and release outputs. Authority is the word that matters. Plans often list responsibilities and skip who decides, which is how a project reaches design transfer with no one empowered to sign it. The weak version is a responsibility chart with no approver at the gates.
e) Methods for traceability of outputs to inputs
Document how outputs will be traced to inputs: a trace matrix, a requirements management tool, or an identifier convention carried through the design history. This item separates plans that work from plans that look complete, and it is the one the resin change in our opening exposed. The weak version contains the word “traceability” with no method behind it. MSI’s design control metrics article shows how to measure trace coverage so you can see it slipping.
f) Resources, including necessary competence
List the resources the project needs, including the necessary competence of personnel. That links the plan to Clause 6.2, which requires the organization to determine and provide competence. A plan that names a usability engineer as a resource should be able to point to evidence that the person is competent in human factors work. The weak version lists headcount only. MSI’s human resource management procedure article explains how competence evidence is built and kept.
What is required, and what is good practice?
Teams lose time arguing about what the standard demands versus what a consultant or a previous employer preferred. The table below separates the two, with the status of each item stated plainly.
| Plan element | Clause or source | Status |
|---|---|---|
| Design and development stages | ISO 13485 7.3.2 a) | Requirement |
| Reviews needed at each stage | 7.3.2 b), with 7.3.5 | Requirement |
| Verification, validation, and transfer activities per stage | 7.3.2 c), with 7.3.6 to 7.3.8 | Requirement |
| Responsibilities and authorities | 7.3.2 d) | Requirement |
| Methods for tracing outputs to inputs | 7.3.2 e) | Requirement |
| Resources, including competence of personnel | 7.3.2 f), with 6.2 | Requirement |
| Plan maintained and updated as the design progresses | 7.3.2 | Requirement (as appropriate) |
| Verification plans with methods, acceptance criteria, sample-size rationale | 7.3.6 | Requirement |
| Risk management outputs feeding design inputs | 7.1 and 7.3.3 | Requirement |
| Significance of design changes determined | 7.3.9 | Requirement |
| Written threshold for when a change needs re-planning | Procedure design | MSI recommendation |
| Entry and exit criteria for every stage | Practice | MSI recommendation |
| Dates and milestones | Not listed in 7.3.2 | MSI recommendation |
| Usability engineering and software lifecycle plans referenced | IEC 62366-1, IEC 62304 where applicable | Recognized standards; MSI recommendation to link |
Two rows catch teams off guard. First, dates are not on the Clause 7.3.2 list, so a plan can conform without a schedule. Most teams add milestones anyway because the plan doubles as a project management tool, and MSI’s guide to project management quality measurement shows how to measure milestones without confusing schedule with quality.
Second, the link to risk management is not optional. Clause 7.1 requires documented risk management throughout product realization, and Clause 7.3.3 makes applicable risk management outputs a design input. MSI’s ISO 13485 risk management article covers how ISO 14971:2019 and its guidance document ISO/TR 24971 connect to the design file.
ISO Procedure Templates and Guides
Stop Writing the Rulebook From Scratch
Every ISO 13485 design and development plan inherits its rules from your procedures: design control, risk management, document control, purchasing. MSI’s ISO Procedure Templates and Guides library gives you editable, clause-mapped procedures built on one architecture for ISO 9001, ISO 13485, ISO 14001:2026, ISO 45001, and ISO 7101, written from 28 years of ISO consulting so every plan has something solid to point at.
Browse the ISO Procedure Template Library →
Need the risk piece first? The ISO 13485 Risk Management Procedure Template is written to Clause 7.1 and ISO 14971.
The Failure Patterns
Why Do Most ISO 13485 Design and Development Plans Fail?
Written. Filed. Forgotten.
Direct Answer
Most ISO 13485 design and development plan failures happen in practice, not on paper. The plan is frozen at kickoff, stages have no gates, verification is left as TBD, traceability is named but never designed, transfer is planned last, and risk, usability, and software work run on separate tracks the plan never references.
An ISO 13485 design and development plan rarely fails because a heading is missing. They fail when the project changes and the plan cannot answer the question the change raises. These six patterns account for most of what MSI sees in device design files.
1. The plan is frozen at kickoff
Clause 7.3.2 expects planning documents to be maintained and updated as the design progresses. If the ISO 13485 design and development plan shows Revision A only and the project is in verification, the plan is a historical document, not a control. The fix is procedural: make plan revision a required output of every stage-gate review, so updating the ISO 13485 design and development plan is part of closing a stage rather than a separate chore.
2. Stages without gates
A list of stages is not a plan for controlling them, and an ISO 13485 design and development plan without gates cannot control anything. Without written exit criteria, stages blur, design outputs get released before inputs are approved, and verification starts against a moving target. Give every stage a short exit test, such as “all inputs approved and reviewed for adequacy,” and name who confirms it.
3. Verification deferred to TBD
Writing “TBD” against verification at kickoff is reasonable. Leaving it there is not. Clause 7.3.6 requires verification plans with methods, acceptance criteria, and, as appropriate, sample-size rationale. When those decisions are made late, they tend to be made around the result rather than before it. MSI’s guide on optimizing the product design process shows how to pull these decisions forward without slowing the project.
4. Traceability named but never designed
This is the opening story. The ISO 13485 design and development plan says traceability will be maintained, but not how, by whom, or in which tool. The first design change exposes it, because nobody can say which verification records depend on the changed output. Pick the method in the plan, name the owner, and make trace review part of every design review agenda.
5. Transfer planned at the end
Design transfer appears in Clause 7.3.2 c) because transfer decisions shape outputs: tolerances production can hold, inspection methods, supplier capability. Clause 7.3.8 requires outputs to be verified as suitable for manufacturing before they become final production specifications. An ISO 13485 design and development plan that schedules transfer as the last box on the chart usually discovers manufacturing limits after the design is locked. MSI’s production and service provision procedure and purchasing and supplier control procedure articles cover the receiving side of that handoff.
6. Risk, usability, and software on separate tracks
The risk management file under ISO 14971, usability engineering under IEC 62366-1, and the software lifecycle under IEC 62304 each come with their own planning expectations where they apply. When those plans do not reference the ISO 13485 design and development plan, and the ISO 13485 design and development plan does not reference them, the project runs four schedules that disagree. MSI’s articles on human factors validation testing, medical device cybersecurity, and medical device threat modeling show what each track needs from the design plan.
“Having systems, acting on what the records are reporting, and never letting anyone deny the facts is what prevents good systems from deteriorating.”
— Diana Lynn, President and Principal ISO Consultant, MSI
A design plan is one of those records. When the plan says verification of an output is complete and the test report says otherwise, the plan has to change or the record has to be corrected. What cannot happen is a quiet agreement to look away. When the gap is systemic rather than a one-off, it belongs in your corrective action process, which MSI’s guide to CAPA under ISO 13485 explains.
The Template
Free ISO 13485 design and development plan Template: Six Sections
Copy. Complete. Control.
Direct Answer
This free ISO 13485 design and development plan template has six sections, one for each Clause 7.3.2 item, plus a header and a revision log. Copy it into your document control system, complete one per design project, and revise it at every stage-gate review so it stays a control rather than a record of intentions.
Start with a header that ties the ISO 13485 design and development plan to the device and to the rest of your system. Then complete the six sections below. The example entries are illustrations only; replace every one with your project’s real decisions.
Plan header
| Header field | What to enter |
|---|---|
| Project and device | Project name, device name, short intended-use statement |
| Classification and markets | Device class and target markets (for example, US, EU, MDSAP jurisdictions) |
| Plan identity | Plan number, revision, effective date |
| Governing procedure | Your design and development procedure number and revision |
| Design and development file | Location of the file required by Clause 7.3.10 |
| Owner and approver | Plan owner, and the person with authority to approve the plan |
The six sections
| Section | Clause | What to complete | Example entry |
|---|---|---|---|
| 1. Stages and gates | 7.3.2 a) | Each stage with entry criteria, exit criteria, and deliverables | Stage 3, Design Output: exit when all outputs are approved and the trace matrix shows every input covered |
| 2. Design reviews | 7.3.2 b), 7.3.5 | Review per stage: timing, functions required, additional experts, where records are kept | DR-3 at the end of Stage 3: R&D, quality, regulatory, manufacturing, plus a reviewer from outside the project |
| 3. Verification, validation, transfer | 7.3.2 c), 7.3.6 to 7.3.8 | Activities per stage, method, acceptance criteria reference, sample-size rationale, representative product, transfer activities | Pull-strength verification per protocol VP-012, sample size justified in VP-012; pilot-lot units used for validation |
| 4. Responsibilities and authorities | 7.3.2 d) | Roles, named owners, approval authority at each gate, risk acceptance authority | Stage exits approved by the program lead and quality; residual risk accepted per the risk management plan |
| 5. Traceability method | 7.3.2 e) | Tool or matrix, identifier convention, owner, and how changes trigger a trace review | Trace matrix TM-004: inputs DI-xxx, outputs DO-xxx, verification VR-xxx; reviewed at every design review |
| 6. Resources and competence | 7.3.2 f), 6.2 | People, competence required and where evidence is kept, equipment, labs, key suppliers | Usability engineer: competence evidence in training file HR-217; external test lab qualified per purchasing procedure |
Revision log
| Rev | Date | Stage | What changed and why | Approved by |
|---|---|---|---|---|
| A | Kickoff date | Planning | Initial plan | Plan approver |
| B | Gate date | Design input | Verification methods added for approved inputs | Plan approver |
How to size the template
A new platform device uses every row of the ISO 13485 design and development plan template in full. A design change that your procedure classifies as significant can use the same six sections with shorter entries, and many teams mark a section “not applicable” with a one-line rationale instead of deleting it. The rationale matters: a blank section reads as forgotten, while a justified one reads as decided. If you want to test the plan against the rest of your design process before you rely on it, the free Design and Development Maturity Check scores eight elements in under five minutes and covers ISO 13485.
Three mistakes to avoid with any template
- Keeping the example entries. Copied examples are the fastest way to show that a plan was never thought through.
- Treating the template as the procedure. The ISO 13485 design and development plan applies your procedure; it does not replace it.
- Filing it after approval. The template only works if the revision log keeps moving with the project.
ISO 13485 Design and Development Procedure Template
Give Every Plan a Procedure Worth Following
A plan template is only as consistent as the procedure behind it. MSI’s ISO 13485 Design and Development Procedure Template is written to Clause 7.3 (planning, inputs, outputs, reviews, verification, validation, transfer, changes, and the design and development file) in editable Word, so every project team plans the same way and every plan can be audited the same way.
Get the ISO 13485 D&D Procedure Template →
Running ISO 9001 and ISO 13485 in one system? See how MSI builds an integrated ISO 9001 and ISO 13485 system.
The Regulatory Picture
How Does the FDA QMSR Change Design Planning?
Incorporated. Inspected. Enforced.
The FDA’s Quality Management System Regulation took effect on February 2, 2026. It incorporates ISO 13485:2016 by reference, together with clause 3 of ISO 9000:2015, under 21 CFR Part 820. Where an ISO 13485 clause conflicts with the FD&C Act or FDA regulations, the Act and regulations control. For US manufacturers subject to Part 820, Clause 7.3 is now the design control requirement, and the ISO 13485 design and development plan is the planning record FDA expects to find.
FDA’s QMSR page also makes a point early-stage teams often miss: devices made under an investigational device exemption are not exempt from the design and development requirements of 21 CFR 820.10(c) and ISO 13485 Clause 7. Planning does not wait for clinical work to finish. It starts before. The final rule in the Federal Register and FDA’s QMSR frequently asked questions explain the transition in detail, and MSI’s FDA QMSR article walks through what changed for ISO 13485 systems.
On the same date, FDA retired its QSIT inspection technique and began inspecting under Compliance Program 7382.850, listed among the CDRH compliance programs. FDA’s 1997 Design Control Guidance for Medical Device Manufacturers remains a useful plain-language reference for how planning connects to reviews and verification, but the requirement text now lives in ISO 13485.
Outside the US, the same plan carries weight. The Medical Device Single Audit Program (MDSAP) audits against ISO 13485 plus the requirements of participating regulators, and the EU Medical Device Regulation 2017/745 requires manufacturers to run a quality management system that covers product realization, including design. The International Medical Device Regulators Forum (IMDRF) continues to push regulators toward these shared foundations. One well-built plan serves every market.
As of October 2026, ISO 13485:2016 remains the current edition. ISO confirmed it after systematic review on October 31, 2025, and certification body TÜV NORD reports that it will remain valid without revision until April 2030. Plans written to Clause 7.3 today will not need re-basing for a new edition any time soon.
The Audit
How Do Internal Auditors Test an ISO 13485 design and development plan?
Pick. Trace. Verify.
Direct Answer
Internal auditors test an ISO 13485 design and development plan by tracing, not reading. They pick one design output, trace it back to its approved input and forward to its verification record, then confirm that the reviews, approvals, and revisions the plan promised happened on the dates and with the people the plan named.
An ISO 13485 design and development plan can be perfectly formatted and still fail in practice. The only way to know is to test it the way the project used it. ISO 19011:2026, the auditing guidance published May 27, 2026, describes the evidence-based approach in Clause 4.7 and the risk-based approach in Clause 4.8, and points auditors to sampling in Annex A.6. Applied to design control, that means sampling a handful of outputs and following each one through the file rather than checking that every heading exists. MSI’s ISO 19011:2026 internal audit procedure article shows how to build that into your audit procedure.
Frequency matters as much as method. Registrars across the industry expect every requirement of the standard to be internally audited annually, and Clause 7.3 is no exception. An ISO 13485 design and development plan that has never been audited is an assumption, not a control. Many device companies follow their procedures carefully and assume that makes them compliant. It does not, if design control has gone a year without an internal audit.
“If you are not doing internal audits on an annual basis, you are not compliant.”
— Diana Lynn, President and Principal ISO Consultant, MSI
The Plan Trace Test
Use this self-check, built for this article, to run the same test an internal auditor would on your current ISO 13485 design and development plan. Score each item 0 for no evidence, 1 for partial evidence, or 2 for complete, objective evidence.
| # | Test | Clause | Score (0 to 2) |
|---|---|---|---|
| 1 | The current plan revision matches the project’s current stage | 7.3.2 | |
| 2 | Every stage has written exit criteria, and each stage exit was approved by the authority the plan names | 7.3.2 a), d) | |
| 3 | Every planned design review happened, included the functions the plan required, and has records of the design, participants, and date | 7.3.5 | |
| 4 | One sampled output traces to an approved input and to a verification record whose acceptance criteria were met | 7.3.2 e), 7.3.6 | |
| 5 | Verification sample sizes carry a documented rationale wherever statistical techniques are used | 7.3.6 | |
| 6 | Validation was planned on representative product, with the choice justified | 7.3.7 | |
| 7 | Transfer activities were planned before outputs became final production specifications | 7.3.2 c), 7.3.8 | |
| 8 | People named as resources have competence evidence for the work assigned | 7.3.2 f), 6.2 |
| Total score | What it means | Next move |
|---|---|---|
| 14 to 16 | The plan is in control | Keep it on the annual internal audit schedule |
| 9 to 13 | The plan is drifting | Fix the lowest-scoring items before the next stage gate |
| 0 to 8 | The plan has become shelfware | Re-baseline the plan now and review the procedure behind it |
If your ISO 13485 design and development plan scored below 14, the fix is rarely a new template. It is auditors who know how to read design evidence and an audit program that reaches design control every year. MSI’s articles on internal audit planning and internal audit mistakes cover both sides, and the free Internal Audit Maturity Check scores where your program stands today.
For Your Internal Audit Team
Train Internal Auditors Who Can Read a Design File
Most internal auditors were trained to confirm that procedures exist. Design control needs auditors who can pick an output, follow the trace, and recognize when a plan has stopped controlling the project. MSI’s ISO 13485 2-Day Internal Auditing course trains your team to audit every requirement of ISO 13485, Clause 7.3 included, against medical device realities: design files, risk management, complaints, and regulatory reporting. It ends with a hands-on sample audit and a Certificate of Completion, and it is built from 28 years of ISO consulting, 200+ audits attended, and 600+ professionals trained.
Enroll Your Auditors in ISO 13485 Internal Auditing →
Compare formats on MSI’s ISO internal auditor training page, or choose the combined ISO 9001 and ISO 13485 2-day course if you run one QMS against both standards. Prefer an independent audit? MSI’s internal audit services cover ISO 13485 design control too.
Leadership’s View
How Does Design Plan Health Reach Management Review?
Report. Decide. Resource.
Design plans do not stop at engineering. ISO 13485 Clause 5.6.2 lists the inputs to management review, and several of them carry design plan health upward: audit results, monitoring and measurement of processes, changes that could affect the quality management system, and applicable new or revised regulatory requirements. When the Plan Trace Test shows plans drifting across projects, the fix usually needs resources only top management can provide, which is exactly what management review is for. MSI’s ISO 13485 management review guide shows how to turn those inputs into decisions.
A practical habit: report one number per active project at each review, the latest Plan Trace Test score for its ISO 13485 design and development plan, alongside the audit findings on design control. Leadership sees which projects are in control without reading a single design file, and the record shows that management acted on what the audits reported.
ISO Management Review Tool Kits
Put Design Control on the Review Agenda, With Data
MSI’s ISO Management Review Tool Kits give you the agenda, input templates, and minutes structure to turn audit results on design into decisions leadership can act on and records that show it. Choose the ISO 13485 edition, or the combined ISO 9001/13485 kit already updated to ISO 9001:2026.
Find Your Management Review Tool Kit →
Not ready to buy? Start with the free guide, 5 Steps to a Decision-Ready ISO Management Review.
Dual-Certified Organizations
How Does ISO 9001:2026 Clause 8.3.2 Compare?
Consider. Document. Align.
ISO 9001:2026 was published on September 16, 2026. Its Clause 8.3.2 asks the organization to consider ten factors when determining the stages and controls for design and development, from the nature, duration, and complexity of the work to the need to control interfaces between people, the involvement of customers and other relevant interested parties, and the documented information needed as evidence. ISO 13485 asks for six documented items. The practical difference is simple: ISO 9001 tells you what to think about, and ISO 13485 tells you what to write down.
One ISO 13485 design and development plan template can satisfy both. Document the six ISO 13485 items, then add fields for interfaces, interested-party involvement, requirements for subsequent provision, and the level of control customers expect. ISO 9001:2026 Clause 8.3.1 also carries a NOTE that design and development can include iterative cycles of review, verification, validation, and feedback. Like every ISO NOTE, it is guidance for consideration and creates no obligation. MSI’s advanced ISO 9001 design and development article and its summary of ISO 9001:2026 changes cover the quality-side detail.
Common Questions
ISO 13485 design and development plan: Frequently Asked Questions
Ask. Answer. Act.
Is an ISO 13485 design and development plan mandatory?
Yes, whenever your organization performs design and development. Clause 7.3.2 requires an ISO 13485 design and development plan documenting the stages, reviews, verification, validation and transfer activities, responsibilities and authorities, traceability methods, and resources. Organizations that do no design may exclude Clause 7.3 where regulatory requirements allow, with the justification recorded in the quality manual.
What is the difference between an ISO 13485 design and development plan and a design and development procedure?
The procedure, required by Clause 7.3.1, sets the system-level rules every design project follows. The ISO 13485 design and development plan, required by Clause 7.3.2, applies those rules to one project, with named people, specific verification methods, and a revision history kept in the design and development file.
How often should an ISO 13485 design and development plan be updated?
Clause 7.3.2 requires the ISO 13485 design and development plan to be maintained and updated, as appropriate, as the design progresses. MSI recommends revising it at every stage-gate review and whenever a design change your procedure classifies as significant alters stages, activities, responsibilities, or resources.
Can one ISO 13485 design and development plan cover a device family?
It can, when the family is designed as one project with shared stages and reviews. Clause 7.3.10 allows a design and development file per device type or family. The ISO 13485 design and development plan must still identify which verification and validation activities apply to which family members.
Does the FDA QMSR require an ISO 13485 design and development plan?
Yes. Since February 2, 2026, the QMSR incorporates ISO 13485:2016 by reference, so Clause 7.3.2 applies to manufacturers subject to 21 CFR Part 820. An ISO 13485 design and development plan is the planning record investigators expect, including for devices made under an investigational device exemption.
Who should approve an ISO 13485 design and development plan?
Clause 7.3.2 d) requires the ISO 13485 design and development plan to document responsibilities and authorities, so your procedure should name the approver. Most organizations require approval by the design project lead and quality, with regulatory affairs involved where submissions depend on the plan.
Your Next Step
Want a Second Set of Eyes on Your Design Plans?
Review. Prioritize. Improve.
An ISO 13485 design and development plan that works in practice is one your team opens every week, your auditors can trace in an hour, and your leadership can read in a single number. If yours is not there yet, you do not need a bigger document. You need the right six sections, a procedure behind them, and auditors who test them every year.
Planning Session
Find Out Which Plan Elements Your Projects Are Missing
In one planning session, MSI reviews your design and development procedure and one current ISO 13485 design and development plan, runs the Plan Trace Test with your team, and gives you a prioritized list of fixes, whether or not MSI does the work. It draws on 28 years of ISO consulting and 80+ certifications supported.
Prefer to call? Reach MSI at 760-434-9141. Building a device QMS from the ground up? Explore SurePath for turnkey certification, SureResults for year-round maintenance, MSI’s ISO consulting services, or the ISO 13485 Launch Mastery course for new teams.
Keep reading in the medical device cluster: ISO 13485 medical device standard services, ISO 13485 for startups, how ISO 13485 can make or break a device launch, and building a medical device QMS.
References and Sources
- ISO 13485:2016 Medical devices: Quality management systems
- ISO 14971:2019 Application of risk management to medical devices
- ISO/TR 24971:2020 Guidance on the application of ISO 14971
- IEC 62366-1:2015 Application of usability engineering to medical devices
- IEC 62304:2006 Medical device software: Software life cycle processes
- ISO 19011:2026 Guidelines for auditing management systems
- ISO 9001:2026 Quality management systems: Requirements
- FDA: Quality Management System Regulation (QMSR)
- FDA: QMSR Frequently Asked Questions
- eCFR: 21 CFR Part 820
- Federal Register: Medical Devices; Quality System Regulation Amendments (final rule)
- FDA: Design Control Guidance for Medical Device Manufacturers (1997)
- FDA: CDRH Compliance Programs
- FDA: Medical Device Single Audit Program (MDSAP)
- EUR-Lex: Regulation (EU) 2017/745 on medical devices
- International Medical Device Regulators Forum (IMDRF)
- TÜV NORD: ISO 13485:2016 reconfirmed
About Management Systems International (MSI)
Diana Lynn, President and Principal ISO Consultant at Management Systems International (MSI), a consulting firm she co-founded in 1998. With 28 years of experience including extensive AS9100 work in MSI’s early years, MSI’s track record includes 80+ certifications supported, 200+ audits attended, and 600+ professionals trained across manufacturing, technology, medical device, government, healthcare, and other regulated industries. Today MSI implements ISO 9001, ISO 13485, ISO 14001, and ISO 45001, with an expanding focus on ISO 7101 healthcare quality.
Veteran-owned and female-owned. About MSI · msi-international.com · 760-434-9141
