---
title: MDR Design and Development Planning: Using ISO 13485 Section 7.3 to Comply
description: EN ISO 13485 clause 7.3.2 requires design and development planning. Here is what to include and how to keep it proportionate in a startup.
authors: Tibor Zechmeister, Felix Lenhard
category: Quality Management Under MDR
primary_keyword: MDR design development planning ISO 13485
canonical_url: https://zechmeister-solutions.com/en/blog/mdr-design-development-planning
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR Design and Development Planning: Using ISO 13485 Section 7.3 to Comply

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Design and development planning under the MDR is the first sub-clause of the design controls chapter of EN ISO 13485:2016+A11:2021. Clause 7.3.2 requires a documented plan for every medical device design project that identifies the stages of the project, the review, verification, validation and transfer activities at each stage, the responsibilities and authorities, the methods for traceability, and the resources needed. The plan is a living document that is updated as the project progresses and the updates are controlled. The legal hook in the MDR is Article 10(9), which requires a QMS covering product realisation including design and development. Clause 7.3.2 is the practical structure that provides presumption of conformity with that part of the obligation. A one-page honest plan written in week one of regulated development beats a twenty-page reconstructed plan written the week before the audit, every single time.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- MDR design and development planning is governed by clause 7.3.2 of EN ISO 13485:2016+A11:2021, under the general design and development procedures required by clause 7.3.1, all traceable to MDR Article 10(9).
- The plan must identify project stages, the review/verification/validation/transfer activities at each stage, responsibilities and authorities, traceability methods, and resource needs.
- The plan is a living document. Clause 7.3.2 explicitly requires that the plan be maintained and updated as the design progresses, with changes controlled.
- The design plan is also where risk management under EN ISO 14971:2019+A11:2021 is hooked into the design process, because risk management activities belong at planned stages.
- Proportionality matters. A three-person Class I team and a fifty-person Class III team both need a clause 7.3.2 plan — but the plans look nothing alike. Sizing the plan to the device is the discipline.
- The fastest startups write a one-page plan in week one, update it deliberately, and never reconstruct it retrospectively. The slowest ones skip planning and pay for it at audit.

---

## Two plans, two outcomes

A three-person startup in Lower Austria built a Class IIa device and walked into its first MDR audit with a design and development plan that was four pages long. Not forty. Four. The plan had been written in the first week of regulated development. It listed the project stages, the reviews and verification activities at each stage, who was responsible for what, how traceability would be maintained between inputs, outputs, risk, and test results, and what resources the project needed. It had been updated roughly once a quarter — five times in total — with each update under document control and signed off by the same named person. The auditor opened the plan, asked who the design owner was, and asked to see the most recent update. Answered in a minute. The plan was a credible governance artefact because it actually governed the project.

A different team, based in Graz, built their plan the opposite way. They had no plan for the first eighteen months of development. When the first pre-audit gap analysis flagged this, they reconstructed a plan from memory, back-dated sections so that the "history" looked plausible, and added every possible activity to make the plan look thorough. Forty-seven pages. Every conceivable review. Every possible gate. When the auditor asked who was responsible for a specific decision in month eight of the project, the answer was a confused pause — because nobody had actually been running the project against that plan. The plan was fiction described as history. The auditor noticed in roughly two questions.

Same clause. Same standard. Two completely different relationships with it.

This post is about writing the first kind of plan.

## What clause 7.3.2 actually requires

Clause 7.3 of EN ISO 13485:2016+A11:2021 is the design and development section of the standard, and the first two sub-clauses establish the procedural ground. Clause 7.3.1 (General) requires the organisation to document procedures for design and development and to apply them. Clause 7.3.2 (Design and development planning) requires, for each design project, a plan that addresses a specific and non-negotiable list of items.

The list, in the plain language of a startup running against it:

- **The stages of the design and development project.** A concrete breakdown of the phases the project will move through — from feasibility to concept to detailed design to verification to validation to transfer. The number and names of stages are the team's decision, within reason. What is not optional is that stages are defined.
- **The review, verification, validation and transfer activities appropriate at each stage.** For every stage the team identifies, the plan states which reviews will happen, which verification work will be done, which validation activities belong there, and when transfer activities take place. This is the backbone that later feeds clauses 7.3.5 (reviews), 7.3.6 (verification), 7.3.7 (validation), and 7.3.8 (transfer). If the plan does not say when these activities occur, the team cannot later show that they happened at the right time.
- **Responsibilities and authorities for design and development.** Every activity in the plan has a named owner, or at minimum a named role. The auditor will ask "who signs this off?" and the plan must answer without a meeting.
- **The methods to ensure traceability of design and development outputs to design and development inputs.** This is the traceability matrix obligation — not as an add-on, but as a planned discipline from day one. The plan states how the team will maintain traceability (the tool, the format, the cadence), not just that they intend to.
- **The resources needed, including necessary competence of personnel.** What people, skills, facilities, test equipment, and time the project requires. For a startup this is a short list. For a large manufacturer it is a long one. Both are plans.

Clause 7.3.2 also says, plainly, that the organisation shall manage the interfaces between different groups involved in design and development to ensure effective communication and clear assignment of responsibility, and that the planning output shall be documented and updated as appropriate as the design progresses. The plan is not a one-time artefact. It is maintained.

## Stages, reviews, verification, validation, transfer — planning the activities

The substantive core of clause 7.3.2 is the obligation to plan, for each stage, which activities happen and where. A useful planning move is to list the stages down one axis and the activity types across the other, and fill in the cells.

A lean startup plan for a Class IIa software-as-a-medical-device might have four or five stages: feasibility, concept and inputs, detailed design and implementation, verification, and validation plus transfer. At the concept and inputs stage, the plan schedules a design review of the inputs themselves — because clause 7.3.3 requires inputs to be reviewed for adequacy before detailed design proceeds. At the detailed design stage, the plan schedules architectural reviews, module-level verification against specifications, and an integration review. At the verification stage, the plan schedules full verification against the input set and the final design review before validation starts. At the validation and transfer stage, the plan schedules validation on production-representative device, the design transfer activities (clause 7.3.8), and the final release review.

Nothing in this is improvised on the day. Every review, verification activity, validation activity, and transfer activity has been anticipated in the plan, assigned to a stage, assigned to an owner, and given a resource estimate. When the activity happens, the record it produces slots into its planned place in the design and development file (clause 7.3.10, covered in post 298 on the Design History File under MDR).

The point is not that the plan predicts the future perfectly. The point is that the plan makes the choices explicit. When reality diverges — and it always does — the plan is updated, the update is controlled, and the reason for the update is captured. That is clause 7.3.2 working as intended.

## Responsibilities and authorities

Every activity in the plan has a named owner. In a three-person company, the temptation is to leave owners implicit because "obviously it is me." Clause 7.3.2 does not care about obvious. It requires responsibilities and authorities to be assigned.

Assigning responsibility does two things simultaneously. First, it tells the auditor who decides. Second, it tells the team itself who decides, which is often the more valuable effect in a small company where decision rights are fluid. Writing "design review sign-off: CTO" in the plan is a tiny intervention that prevents a common failure mode where no review ever formally happens because nobody was explicitly on the hook.

Authorities matter alongside responsibilities. The plan states not just who does the work but who has the authority to approve inputs, outputs, changes, and reviews. In larger teams, authorities often separate from responsibilities — the engineer does the work, the design lead approves it. In small teams they collapse together. Either is fine. Both must be written down.

Independence of reviewers is an additional requirement, carried in clause 7.3.5. The plan is the right place to pre-commit to independent reviewers, naming who will play that role for each planned review. In a three-person company, "independent" often means an engineer from a different functional area or an external advisor brought in explicitly for the review. In a larger company it means someone outside the reporting line of the project. The plan captures which option applies for each review.

## The risk management interface

Clause 7.3 does not exist in isolation. The design and development process runs in parallel with, and is fed by, the risk management process required under EN ISO 14971:2019+A11:2021, which is itself the harmonised standard supporting the risk management aspects of MDR Annex I General Safety and Performance Requirements.

Clause 7.3.2 is where this interface is planned. The plan identifies where in the design process the risk management activities hook in — typically, risk management activities feed the design input review (initial hazard identification and requirements on design inputs), feed the output review (risk control measures become design outputs), feed verification (design outputs that implement risk controls must be verified), feed validation (residual risk acceptability is part of the validation case), and feed change control (every design change is evaluated for risk impact).

In practical terms this means the plan reserves specific gates at which the risk file is updated and reviewed alongside the design work. A lean version is: risk file review at inputs sign-off, risk file review at final design review, risk file review at validation entry, risk file review before transfer. Each review is named in the plan, assigned to an owner, and dated by stage. This is how clause 7.3 and EN ISO 14971:2019+A11:2021 stop being two separate standards a startup has to run in parallel and become one integrated process running against one timeline.

The risk file drives design inputs; the design process drives risk controls; verification confirms the controls were implemented; validation confirms the residual risk profile in real use. Every handshake between the two processes is planned in clause 7.3.2, not improvised later.

## How it scales with team size

A common worry from small teams is that clause 7.3.2 sounds like enterprise governance that cannot possibly apply to a company with three people in a shared office. The worry is misplaced. Clause 7.3.2 scales with the project — and proportionality is built into MDR Article 10(9) as a matter of law.

For a three-person company building a Class IIa device, the plan can realistically fit on two to four pages. Five stages, three columns of activities, a short owners table, one paragraph on traceability tooling, a resource list, and a change log. The plan is updated maybe five or six times across a two-year project. Each update takes thirty minutes. The total effort is small — and the effort saved at audit time, where the auditor can see the whole history in one place, is large.

For a fifty-person company building a Class III implantable, the plan is dozens of pages, with detailed stage definitions, multi-level ownership, interface management between engineering disciplines, subcontractor management, and planned coordination with clinical investigations. The effort is substantial. The Regulation and the risk justify it.

In both cases the clause is the same. In both cases the obligation is the same. What differs is the depth, which is exactly what MDR Article 10(9) requires through its "proportionate to the risk class and type of device" language. A plan that is too heavy for the project wastes runway. A plan that is too light leaves the team unable to show how the project was governed. Both mistakes are audit-visible.

## Common mistakes

- **Skipping the plan entirely in the first months of regulated development** and reconstructing it retrospectively before audit. Reconstructed plans are detectable within minutes by any competent auditor.
- **Writing a plan once and never updating it.** A plan from month one that has not changed by month twenty is not a plan, it is a historical artefact. Clause 7.3.2 requires the plan to be maintained as the project progresses.
- **Listing stages without listing the activities at each stage.** A plan that says "Stage 3: detailed design" without specifying which reviews, verification, and validation activities happen there fails the core requirement of 7.3.2.
- **Responsibilities assigned to a role that no one holds.** "Design lead signs off" is useless if there is no design lead. Either assign a real person or assign a role that a named person actually occupies.
- **Traceability left as an intention.** "Traceability will be maintained" is not a method. "Traceability will be maintained in [specific tool] with weekly update cadence, owned by [name]" is a method.
- **Ignoring the risk management interface.** A plan that does not reserve explicit gates for risk file review alongside the design reviews is forcing the team to do risk management as a parallel track, which always drifts.
- **Over-planning.** Forty-seven pages of speculative stages that never run is worse than four pages of honest stages that do run. Every page must earn its place.

## The Subtract to Ship angle on design planning

Subtract to Ship (post 065) applied to clause 7.3.2 is straightforward in principle. Every element in the plan must serve clause 7.3.2 itself — stages, activities, responsibilities, traceability, resources — and through it, MDR Article 10(9) product realisation. Every element that is there only because "plans usually have one" is cut.

The move that produces the biggest return is the one the Lower Austria team applied: write the plan in the first week of regulated development, before anything is at stake, while the choices are still cheap. A one-page honest plan at the start is the fastest and least expensive version of this work. It gets updated as the project grows. The updates are under document control. By audit time, the plan and the update history together tell the design story accurately — not because the team engineered it, but because the plan kept up with reality.

The Graz over-documentation pattern (post 298) is the opposite move: no plan for months, then a large reconstructed plan that does not match what happened. The reconstructed plan is more work and less credible. Subtraction here is not about removing required content. It is about not inventing content that was never lived.

## Reality Check — Where do you stand?

1. Does your project have a written design and development plan that was created in the first weeks of regulated development and has been updated deliberately since?
2. Can you point to the plan and name the project stages, the activities at each stage, the responsible owners, the traceability method, and the resources required — or is any of this implicit?
3. Is every review, verification, validation, and transfer activity in the plan assigned to a specific stage and a named owner?
4. Does the plan include explicit gates where the risk management file is reviewed alongside the design work, integrated with EN ISO 14971:2019+A11:2021?
5. When was the plan last updated, what changed, and who approved the update? Is the update under document control?
6. Could an auditor open the plan today and, in two minutes, work out who is responsible for the next design review and when it is scheduled?
7. Is your plan sized for your real project, or is it either a skeleton that leaves out required content or an overweight document that nobody actually runs the project against?
8. If you stopped updating the plan for six months, would anyone on the team notice — because they were using it — or would nothing change in the daily work?

Any "not yet" answer is a place to do the work before the next audit window.

## Frequently Asked Questions

**Does the MDR itself require a design and development plan?**
The MDR does not use the phrase "design and development plan" in its text. MDR Article 10(9) requires a quality management system covering product realisation, including design and development, proportionate to the risk class and type of device. The harmonised standard EN ISO 13485:2016+A11:2021 gives presumption of conformity with that obligation, and clause 7.3.2 of that standard specifies the design and development planning requirement. In practice, manufacturers certifying under MDR build the clause 7.3.2 plan.

**How detailed does the design plan need to be for a small startup?**
As detailed as the project and its risk class require, and no more. For a lean Class IIa startup, a two- to four-page plan that names the stages, the activities at each stage, the responsibilities, the traceability method, and the resources is usually adequate. The test is whether a reviewer can see how the project is governed from the plan alone. A Class III implantable will need far more depth. Proportionality is written into Article 10(9) as a legal concept, not a style preference.

**How often should the plan be updated?**
Whenever the project changes in a way that affects the items clause 7.3.2 requires the plan to cover — new stages, new activities, changed responsibilities, new resources, changed traceability approach. In practice that usually means a handful of controlled updates across a multi-year project, each approved under the document control procedure. A plan that never changes over a long project is almost certainly not being used.

**Who should own the design and development plan?**
Clause 7.3.2 requires responsibilities and authorities to be assigned, but it does not prescribe a specific role. In a small startup the plan is usually owned by the technical lead or the person acting as design owner, with approval from top management. In a larger company the plan is owned by a design programme manager or equivalent. The key is that ownership is explicit, named, and documented.

**Does the design plan belong in the technical documentation under Annex II?**
The plan itself lives in the design and development file (clause 7.3.10 of EN ISO 13485:2016+A11:2021). The technical documentation required under MDR Annex II draws from the outputs the plan produces — verification records, validation records, transfer records, and the traceability between inputs, outputs, and GSPR items. The plan is upstream of Annex II. See post 298 for how the clause 7.3 outputs feed Annex II.

**What is the relationship between clause 7.3.2 and risk management?**
Clause 7.3.2 requires the plan to cover the activities at each stage. The risk management activities required under EN ISO 14971:2019+A11:2021 happen at planned stages of the design process — during input definition, during output review, during verification, during validation, and at every change. The plan is where these handshakes are anticipated and timed, so risk management runs with the design rather than alongside it.

## Related reading

- [What Is a Quality Management System for Medical Devices?](/blog/what-is-quality-management-system-medical-devices) — the pillar post for the Quality Management Under MDR cluster and the home of the MDR Article 10(9) obligation this post sits inside.
- [MDR Article 10(9) and Annex IX QMS Requirements in Detail](/blog/mdr-article-10-9-annex-ix-qms-requirements) — the article that governs the entire design controls chapter from the MDR side.
- [How to Build a Lean QMS for an MDR Startup](/blog/build-lean-qms-mdr-startup) — the broader QMS context this design-controls cluster sits inside.
- [Design Inputs Under MDR](/blog/design-inputs-mdr) — deep dive on clause 7.3.3 and how inputs are reviewed for adequacy before detailed design proceeds.
- [Design Outputs Under MDR](/blog/design-outputs-mdr) — deep dive on clause 7.3.4 and how outputs trace back to the inputs planned in 7.3.2.
- [Design Reviews Under MDR](/blog/design-reviews-mdr) — deep dive on clause 7.3.5 and on independent reviewer requirements the plan anticipates.
- [Design Verification Under MDR](/blog/design-verification-mdr) — deep dive on clause 7.3.6.
- [Design Validation Under MDR](/blog/design-validation-mdr) — deep dive on clause 7.3.7.
- [Design Transfer Under MDR](/blog/design-transfer-mdr) — deep dive on clause 7.3.8 and how the plan reserves the transfer activities.
- [Design Change Control Under MDR](/blog/design-change-control-mdr) — deep dive on clause 7.3.9.
- [The Design History File (DHF): Documenting Your Development Story Under MDR](/blog/design-history-file-mdr) — how the clause 7.3.10 design and development file collects the outputs the plan anticipates.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology the planning discipline in this post applies.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(9) (quality management system obligation, including product realisation and design and development), Annex II (technical documentation), Annex I (General Safety and Performance Requirements). Official Journal L 117, 5.5.2017.
2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clauses 7.3.1 (General design and development procedures), 7.3.2 (Design and development planning), and 7.3.3 (Design and development inputs). The harmonised standard providing presumption of conformity with the design and development portion of MDR Article 10(9).
3. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices. The harmonised standard for the risk management interface that clause 7.3.2 plans around.

---

*This post is part of the Quality Management Under MDR cluster in the Subtract to Ship: MDR blog, linking up to the QMS pillar at post 276. Authored by Tibor Zechmeister and Felix Lenhard. The MDR is the North Star. EN ISO 13485:2016+A11:2021 is the tool. Clause 7.3.2 is where a startup decides whether its design project will be governed or merely documented — and that decision shows up at audit.*

---

*This post is part of the [Quality Management Under MDR](https://zechmeister-solutions.com/en/blog/category/quality-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*