ISO 13485 7.3.9 design changes: impact assessment, evidence and implementation
Assess design-change impacts and the applicability of existing test evidence.
Connect requests, impact assessments, verification, validation, approval and production records.
Design change control connects a proposed modification to the requirements, risks, evidence and production information it may affect.
A previous passing test establishes evidence for the configuration that was tested.
Before relying on that result for a modified design, explain why its conditions and conclusions remain applicable.
This article uses ISO 13485:2016 clause 7.3.9 as its reference point and proposes a practical way to connect a change request to implementation.
The thermometer, document names, identifiers and role assignments below are fictional working examples, not mandatory templates or actual test results.
1. A small sensor movement can raise a wider question
Consider a contact thermometer whose sensor is proposed to move farther from the skin-contact surface to make assembly easier.
The reason for the change is manufacturing convenience, but the assessment should also consider whether the altered heat-transfer path affects the relevance of existing evidence for measured values and response time.
This is a question for assessment, not a claim that performance has changed.
Keeping the same sensor part number does not necessarily preserve the configuration of the complete device.
Position, surrounding materials, fixation and assembly variation may affect the conditions represented by earlier evaluations.
Neither automatically discarding every prior result nor assuming that no further evaluation is needed is a useful starting point.
Compare what is unchanged with what the proposal changes.
| Item to compare | Locate in the previous evidence | Question for the proposed design |
|---|---|---|
| Sensor relative to contact surface | Test-device drawing, position and surrounding structure | Does the heat-transfer path or assembly variation change? |
| Measurement performance | Requirement, conditions, results and tested configuration | Does the previous result represent the proposed structure? |
| Use sequence | Completion indication and use scenario | Could a change in measurement time affect user actions? |
| Manufacturing and inspection | Fixture, instructions and inspection location | Can the new position be implemented and inspected consistently? |
This fictional concept illustrates why the applicability of previous evidence needs assessment.
2. Turn change control into a traceable decision
The public MDSAP audit approach links controlled changes, pre-implementation evaluation and approval, risk assessment, and effects on previously made or delivered devices to ISO 13485:2016 clause 7.3.9. Jurisdiction-specific regulatory submissions require a separate applicability assessment.
MDSAP Audit Approach, Chapter 5 Tasks 13 and 15
In a working system, connect the reason for the change, the impact assessment, supporting evidence and implementation decision.
Approving a convenience improvement and immediately issuing a drawing can leave an important gap: who evaluated the implications for measurement performance, and on what basis? A single change identifier can help reviewers find that decision and its supporting material.
Use the organization's change procedure when approved inputs or outputs are modified during development as well as after transfer.
In this example, the modification is still a proposal awaiting evaluation for production use.
Permission to build experimental samples should not be confused with authorization to manufacture the changed device for sale.
3. Documents, timing and responsibilities
The following is a suggested arrangement for an organization with design, production engineering, quality and regulatory functions.
Smaller organizations may combine documents or roles.
The organization defines actual responsibilities and approval authority; a particular department name or number of forms is not the objective.
| Example document or record | When and why it is prepared | Information to include | Example roles |
|---|---|---|---|
| Change request | When the proposal arises, to identify its scope and reason | Model, current and proposed revisions, before/after drawings, reason and proposed application | Proposer prepares; design checks technical description; assigned owner decides the review route |
| Impact assessment | Before finalizing evaluation plans | Affected requirements, risks, documents, parts and devices; evidence retained and rationale; regulatory questions | Design coordinates; relevant production, quality and regulatory functions review |
| Verification or validation plan | Before the relevant evaluation | Purpose, configuration, method, predefined criteria and their source, sample rationale, decision responsibilities | Evaluation owner prepares; relevant functions review; authorized role approves |
| Execution records and results report | During execution and when evaluating results | Actual configuration and conditions, source data, criteria-based results, deviations and actions | Operator records; assigned reviewer checks data and judgments |
| Change approval record | Before authorizing production implementation | Evidence references, unresolved issues, authorized scope, conditions, decision-maker and date | Change owner assembles evidence; relevant functions review; authorized person approves |
| Implementation and closure record | During implementation and completion review | Issued revisions, instructions, tools and inspection updates, training, stock/work-in-progress disposition and effective point | Assigned functions implement; change owner or reviewer checks completion |
A checked “no impact” box is less informative than a short explanation of what was compared.
For example, “packaging is unchanged” does not by itself explain whether device dimensions and protection conditions also remain represented by the packaging evidence.
Use a more specific conclusion only when the comparison supports it.
4. Decide which evidence remains applicable
Connect the assessment to requirements before turning it into a test list.
Naming an activity “sensor-position test” may hide the relationship to performance or use.
The following entries illustrate planning decisions, not passing results.
| Affected topic | Example assessment of existing evidence | Evidence to prepare next |
|---|---|---|
| Measured values and response time | Earlier samples used the original position and do not directly demonstrate the proposed structure | Verification plan and results tied to changed configuration and requirements |
| Completion indication and user actions | Determine whether a performance change also affects use | Intended-use/scenario impact assessment and rationale for any validation activities |
| Purchased sensor specification | Same part number still requires comparison of supplier specification and application conditions | Configuration comparison and rationale for retaining the existing evidence |
| Instructions and inspection method | Instructions and fixtures may assume the original position | Revised information and production-application assessment |
Link verification to the changed design's relevant input requirements and validation to the requirements of the specified application or intended use.
This does not mean conducting a new user study for every change.
Define the needed scope and, when reusing evidence, explain why it remains applicable after the change.
Link acceptance criteria to their source before execution.
This example does not prescribe numerical limits, sample quantities or test conditions.
Those depend on product requirements, applicable test standards, risk and evaluation purpose.
If the actual method or conditions depart from the plan, retain the difference and assess its implications for the conclusion.
5. Follow one change through its records
Suppose fictional change CHG-01 moves the sensor between drawing revisions DWG-01 Rev.A and Rev.B, and requirement PERF-01 needs further verification.
The identifiers below are illustrative, not real device records.
| Connection | Example reference | What the reader can establish |
|---|---|---|
| Change to configuration | CHG-01 → DWG-01 Rev.A/Rev.B | What changes and why |
| Impact to requirement | IA-01 → PERF-01 and risk item R-01 | Which requirement and risk need assessment |
| Plan to execution | VP-01 → sample configuration and VR-01 | What was actually evaluated and against which criteria |
| Result to decision | VR-01 → relevant item in CR-01 | Whether evidence is sufficient and what remains unresolved |
| Approval to implementation | CR-01 → revised WI-01 and implementation record | Who authorized which scope and whether it was implemented |
Separate “evaluation performed” from “requirement met.”
Execution may have finished while a deviation prevents use of the result, or while evidence for part of the requirement is still missing.
The approval decision should reflect that condition.
Do not label every issue resolved merely because a report has been issued.
6. Define the boundary for existing devices
An effective date alone may not identify which units contain the revised design.
Unused components, partly assembled devices, finished stock and service parts can remain in different states.
A practical implementation record connects document revision to the relevant models, lots, serial numbers or other suitable product identifiers.
Assessing existing devices does not automatically mean modifying or recalling them.
The questions differ when a change improves convenience, corrects a known problem, or affects compatibility between new parts and older devices.
Record the rationale and necessary actions, and evaluate any regulatory consequences for the applicable market.
| Example population | Decision to document |
|---|---|
| Unused parts | Whether previous parts remain usable and how the transition is controlled |
| Work in progress | Whether to complete the original configuration or transition, with the required checks |
| Finished stock | Whether the reason for change affects existing finished devices and their disposition |
| Delivered devices and service parts | Compatibility, safety or performance implications and any follow-up |
7. Connect clauses to document and record management
The clause map below helps locate the relevant control topics.
It does not make these example document names mandatory.
The edition verified on the ISO information page is ISO 13485:2016, third edition, confirmed in 2025.
ISO official information
| Clause or topic | Working material to connect |
|---|---|
| 7.3.9, design and development changes | Change description, impact judgment, evaluation, approval and action records |
| 7.3.6 and 7.3.7, verification and validation | Plans, criteria, evidence and conclusions needed for the assessed impact |
| 7.3.8, transfer | Evidence connecting revised design to production instructions, inspection and conditions |
| 4.2.4, documents | Identification, review, approval and point-of-use revisions for drawings, instructions and plans |
| 4.2.5, records | Identification, preservation, retrieval, protection and traceability of actual execution and decisions |
| 4.2.3 and 7.3.10, files | Controlled references to product information and design-change evidence |
A useful operational distinction is to control the instructions that will be used while preserving evidence of what was actually used.
Revising an instruction to Rev.B does not change an earlier execution record that used Rev.A.
When a record error needs correction, make the original and corrected information, author and timing traceable under the organization's procedure.
The blank change-request form can be a controlled document, while a completed approved change becomes a record.
File extensions or titles alone do not determine the distinction.
For an electronic system, consider access rights, source-data links, retrieval, backup and recovery, and traceability of record changes as part of the working design.
The medical device file can reference current drawings, specifications and manufacturing/inspection information.
The design and development file can reference the impact assessment, plans, results and approval basis.
If the material resides in another system, keep its identifier, revision and location consistent.
Duplicating files in several folders is not a substitute for controlled references.
Do not assign one retention period to these example titles.
Determine retention through applicable regulatory and standard requirements, device lifetime and the organization's procedure.
Link risk management, usability or software change controls where relevant; a sensor-position proposal does not by itself justify a blanket demand to repeat every evaluation under every related standard.
8. Describe what completion means
A closure statement is more useful when it explains the evidence and authorized configuration than when it says only “drawing updated.”
A possible structure is: “The evidence and open items for CHG-01 were reviewed; implementation was authorized for the identified configuration and production scope; the relevant instructions were confirmed at the point of use.”
This is a suggested writing structure, not an actual approval.
The reason for change, evaluation evidence, authorized scope and actual implementation should remain connected.
That connection makes the decision understandable when the next modification is proposed.
Sources and scope
- ISO 13485:2016 official information: third edition, published in 2016 and confirmed in 2025.
Edition checked 4 November 2026. - MDSAP AU P0002.011, Audit Approach: revision 3 August 2026.
Chapter 5 Tasks 13 and 15 support the public audit perspective on change control and existing-device impact.
This guidance does not replace the standard.
Checked 4 November 2026.
Document structures and scenarios are MedQraft practical suggestions.
Determine market-specific submissions and product-specific evaluation details from the applicable regulations and standards.
Related reading
- Design verification: evidence and document connections
- Design validation: intended use, plans, records and reports
- Design transfer: production specifications and methods
- QMS insights and ISO 13485 clause guide
Continue through ISO 13485 clauses
Compare clause purposes and supporting evidence
- 7.3.2 Design and development planning
- 7.1 Planning of product realization
- 7.2 Customer-related processes
- 7.3.3 Design and development inputs
- 7.3.4 Design and development outputs
- 7.3.5 Design and development reviews
- 7.3.6 Design and development verification
- 7.3.7 Design and development validation
- 7.3.8 Design and development transfer
- 7.3.10 Design and development files
- 7.4.1 Supplier evaluation
- 7.4.2 Purchasing information
- 7.5.6 Validation of production and service processes
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 ↗