ISO 13485 clause 7.3: assign owners and checks to each development stage
Use clause 7.3.2 to connect stage responsibilities with review, verification, validation and transfer.
A fictional development plan shows who assesses what and how the results reach the next activity.
Connect each development stage to an owner and a decision
A design and development plan should connect each stage with the people responsible for the work and the evidence needed to judge its outcome.
A schedule headed “design complete, prototype, testing” shows timing, but it does not explain who participates in a review or what they assess.
This article focuses on ISO 13485:2016 clause 7.3.2, design and development planning, within clause 7.3. It does not replace the full design and development requirements with a schedule.
The public MDSAP audit approach connects development stages with appropriate review, verification, validation and transfer activities, responsibilities, authority and interfaces between groups.[1][2]
Our earlier clause 7.1 article addressed objectives, processes, resources and assessment activities across product realization.
Here the focus is the design team's working arrangement: who performs an activity, who reviews it, what supports the decision, and who receives the outcome.
This also differs from the clause 7.2 decision to accept a particular customer order.
Extend a list of stages into a plan that connects people and checks.
The fields are a MedQraft practical suggestion, not a prescribed ISO form.
Where this discussion fits within clause 7.3
Clause 7.3.1 addresses documented design and development procedures; 7.3.2 addresses planning and control.
Inputs, outputs, review, verification, validation, transfer, changes and the design file connect the work.
This original guide indicates the scope of the discussion.
| Clause | Connection made in this article |
|---|---|
| 7.3.2 Planning | Plan stage activities and responsibilities and manage them as development progresses |
| 7.3.3 Inputs / 7.3.4 Outputs | Connect required conditions with the resulting design |
| 7.3.5 Review | Assess stage results and necessary actions with relevant functions |
| 7.3.6 Verification | Confirm that outputs meet input requirements |
| 7.3.7 Validation | Confirm suitability for the specified application or intended use |
| 7.3.8 Transfer | Confirm appropriate translation of design into manufacturing |
| 7.3.9 Changes / 7.3.10 Files | Connect change decisions and traceable development evidence |
Review, verification and validation answer different questions.
Transfer also involves more than emailing a drawing.[2] The table is not a universal sequence of activities performed only once.
Fictional example: a prototype date with no review owner
Consider a fictional team designing the enclosure of a portable measuring device.
The developer has proposed target dates for design, a prototype and transfer to manufacturing.
However, the plan does not name who will assess assembly feasibility, which requirement each test addresses, or who will evaluate suitability in the intended use environment.
The problem is not a lack of effort.
Different decisions have been placed under a single heading such as “testing” or “check.”
Each participant may therefore prepare only the part they assume is required.
The team could develop its plan as follows.
| Activity and related clause | Illustrative roles | Question to resolve | Examples of connected evidence |
|---|---|---|---|
| Design review before the prototype, 7.3.5 | Development and manufacturing representatives | Are the assembly method and working access appropriate for this drawing? | Drawing revision reviewed, assembly comments and open actions |
| Requirements verification, 7.3.6 | Competent test performer and designated results reviewer | Do results from the planned test meet the relevant design input? | Requirement reference, test plan, results and determination |
| Intended-use validation, 7.3.7 | People with the necessary use and evaluation expertise | Does the device perform its intended function for the defined user and environment? | Evaluation article and conditions, plan, observations and conclusion |
| Transfer to manufacturing, 7.3.8 | Development, manufacturing and other relevant functions | Do manufacturing information and readiness reflect the design intent? | Manufacturing specifications, work and inspection information, transfer review outcome |
These assignments and the device are fictional.
The standard does not prescribe these department names or four separate people.
Assign roles according to the product, organization, required competence and applicable requirements.
Include the relevant functions and expertise without treating a job title as evidence of competence.
Different activities in one development plan need different questions and contributions.
The role assignments are fictional, not an ISO organization chart or four mandatory one-time gates.
Make “owner: development team” actionable
MedQraft suggests reading one row of a plan through six fields: activity, performer, review or decision role, evidence, timing and result location.
A department name alone may not distinguish the person carrying out a test from the person reviewing its results or following up an unresolved action.
For the fictional assembly review, the developer could prepare the drawing revision and explanatory material.
The manufacturing representative could examine assembly order and tool access.
If they identify a problem, they can name the person responsible for addressing it and the condition for reviewing the revision.
This makes the intended effect on the next drawing clearer than recording attendance alone.
The test performer needs the relevant requirement, method and acceptance basis when preparing the work.
The reviewer can consider whether the drawing, sample and test conditions connect to the plan.
This article does not prescribe a test method or a numerical acceptance limit.
Those decisions depend on product requirements, risk and appropriate technical evidence.
For validation, the team can consider whether test-equipment skills alone cover the evaluation being planned.
Which expertise is needed to understand the device's users, environment and use tasks? In this example, putting a name under “expert review” is insufficient unless the plan also explains what that person will evaluate.
Define the state expected at transfer
A final schedule entry called “transfer to production” may mean drawing delivery to a developer and manufacturing readiness to the receiving team.
The two parties are then working toward different completion states.
The fictional team could connect the drawings, component information, work instructions and inspection information that will support its transfer review.
It could ask whether the assembly method used for the prototype is reflected in manufacturing information and which documents are affected by open design actions.
These are examples of aligning expectations, not a complete transfer checklist.
Also identify who needs the results of an activity.
If an assembly review leads to an enclosure change, the test performer needs to know whether a revised sample is required.
Names in a plan do not prevent testing against an older drawing if those connections are missing.
Revisit connected activities when the plan changes
Suppose prototype preparation is delayed.
Moving a date on a calendar may leave a test booking, the condition of the evaluation article and the material for a manufacturing review out of alignment.
Checking the affected people and deliverables together is a practical way to address that problem.
MDSAP recognizes that development plans can evolve and examines documentation and approval of plan changes.[1] The following diagram is an original practical way to connect that principle to daily work.
Communicate more than a changed date.
Consider roles, evidence and dependent activities, and apply the organization's change and approval procedures.
Take one stage and follow three questions: who performs the work, who reviews which evidence, and who receives the result? Filling the breaks in that chain can make a plan more useful as a basis for collaboration.
The point of this clause 7.3.2 discussion is to connect stage responsibilities and assessment questions in the same development plan.
Sources and scope
- MDSAP Audit Approach, MDSAP AU P0002.011, revised 3 August 2026.
Chapter 5, Task 3: planning, responsibilities, interfaces and plan changes.
Official document page. - FDA MDSAP Design and Development Process training material, Tasks 3, 7, 10, 14 and 16, for the relationship between activities and ISO clauses.
Historical US regulatory references in the slides are not used as current US law. - ISO 13485:2016 official publication information.
Third edition, 2016, shown as current after confirmation in 2025.
Checked 27 October 2026.
This is not a reproduction or official translation of the standard.
Public-source explanations are distinguished from MedQraft's fictional examples and practical suggestions.
Determine applicability and jurisdiction-specific requirements for the product and organization against the original sources.
Related reading
- Clause 7.1: planning product realization
- Clause 7.2: review requirements and capability before accepting an order
- QMS topics and the ISO 13485 clause guide
Continue through ISO 13485 clauses
Let's talk
Apply what you have read
to your product.
Tell us your product's current stage and the questions you need to review.
Discuss your questions ↗