ISO 13485 clause 7.1: what to plan before development begins

Turn a product concept into a workable plan

When a new medical-device concept is agreed, setting a prototype date alone can leave important work invisible.
Test facilities, material-handling conditions or specialist skills may only be discovered later.
Early planning connects what the product must achieve with the processes and resources needed to implement and assess it.

ISO 13485:2016 clause 7.1 concerns planning the processes needed for product realization, consistently with the other processes of the quality management system.
Its scope extends beyond the development schedule.
This article applies that perspective to a fictional project kickoff.
Clause 7.1 does not prescribe one universal first business activity or require every detailed specification to be frozen before an exploratory prototype can be built.[1][2]

The central connection is between objectives and requirements, processes and resources, assessment activities and acceptance criteria, and the records that will provide evidence.
Risk management informs that connection throughout.
The four groups below are an editorial explanation, not a reproduction of the standard or a mandatory form.

1. Define quality objectives and product requirements

Imagine a team developing a portable measuring device.
“Accurate and easy to use” does not yet provide enough information to select a sensor or prepare a test.
The team needs to establish the intended measurement, purpose, environment and performance conditions.

A product requirement states a condition to be met.
A quality objective states a quality-related goal to be achieved.
Reducing both to “pass testing” obscures what the team is aiming for and what it will evaluate.
Numerical limits need a basis in intended use, applicable regulations and standards, risk and technical evidence.
No accuracy limit or universal acceptance value is invented here.

In the fictional kickoff, the team can start by describing the conditions under which the measurement must remain valid.
An unconfirmed environmental condition can be recorded as an open issue, with an owner and a date for obtaining the information needed by the next activity.
That management approach is MedQraft's practical suggestion.

2. Connect the processes, documents and resources

The team considers the processes needed to implement the requirements and the people and equipment needed to perform them.
Product-specific infrastructure and work-environment needs also belong in this review.
Having a development team does not, by itself, explain whether the necessary skills, space and facilities will be available.

If temperature could affect the fictional device, the team might consider facilities for reproducing relevant conditions, a suitable comparison method and the competence needed to conduct the work.
Where these cannot be provided internally, external capacity and preparation time can be investigated.
This example does not prescribe a particular temperature test for every measuring device.

The review also identifies which existing procedures apply and where additional product-specific instructions are needed.
Referencing the relevant controlled documents can be more useful than copying all procedures into one planning document.

3. Plan assessment activities with acceptance criteria

Clause 7.1 addresses the appropriate product-specific verification, validation, monitoring, measurement, inspection and test activities, together with product acceptance criteria.
This does not mean creating a new test for every term in that list.
Activities need to be selected for the product's requirements and risks, with a clear purpose for each.[2]

For the fictional device, “performance testing planned” leaves the method, conditions and decision unresolved.
The plan can connect the performance to be assessed with the proposed method, conditions and resources.
Detailed methods and values may be developed in subsequent design and test planning.
Acceptance criteria should not be chosen after seeing the results merely to obtain a favorable verdict.

This is an example planning aid.
Detailed verification and validation requirements must also be considered under the relevant clauses, including 7.3, and product-specific rules.

4. Connect risk management and records from the outset

Risk management is not a final checkbox added after planning.
Documented risk-management processes and maintained records support decisions throughout product realization.
Identified risks can influence the selected processes, resources and assessment activities.[2]

If an inaccurate measurement could affect a user's decision, the fictional team needs more than an entry reading “accuracy test.”
It can investigate conditions that could produce an inaccurate result and connect the findings with design responses and the activities needed to assess them.
No particular alarm or control is presented as a universal answer.

Planning also addresses the records needed to demonstrate that product-realization processes and the resulting product meet requirements.
A plan describes intended work; a record provides evidence of what was actually performed.
Preparing an empty test form is different from completing a test and recording its results.
At the planning stage, identify the records and their relationships; during execution, retain the actual evidence.

Early planning does not mean fixing every detail immediately

An early plan contains both known conditions and questions still to be resolved.
The problem is not simply that something is undecided.
It is that an unresolved condition may disappear from the schedule and resource plan while still affecting the work.

Using owners and follow-up dates is MedQraft's implementation suggestion, not a requirement for this particular table format.
Planning outputs can be organized to suit the organization's operations.
Clearly linked existing documents may form part of that approach.

Distinguish clause 7.1 from clause 7.3.2

Clause 7.1 takes a product-realization perspective across the necessary processes and conditions.
Clause 7.3.2 focuses on planning design and development stages and controls.
A development kickoff is the setting used here to explain 7.1; it does not reduce the clause's scope to an R&D timetable.

The useful outcome of the fictional meeting is a visible connection: a product requirement has processes and resources beside it, followed by assessment activities, criteria and evidence records.
That connection is the purpose of filling in the planning board.

Sources and scope

1. ISO 13485:2016, official publication information, third edition, 2016.
   ISO reports review and confirmation in 2025 and identifies this version as current.
2. MDSAP Audit Approach, MDSAP AU P0002.009, published by FDA, August 6, 2024.
   Relevant discussion: risk-management planning under Management, product-realization planning under Production and Service Controls, and planning under Purchasing.

Checked October 25, 2026.
This practical explanation does not replace the standard.
The public MDSAP document supports the relationship between ISO requirements and operational activities; its historical US regulatory citations are not used here to describe current US law.
The measuring-device scenario, tables and diagrams are original fictional explanations, not actual performance data or certification evidence.

Related reading

• Intended purpose, operating principle and performance
• Medical-device risk management and its evidence chain