ISO 13485: Software Tool Validation

In a previous blog, we had a look at challenges and pitfalls relating to ISO 13485. One of the challenges manufacturers of medical devices encounter in their daily work, and a favourite topic for auditors, is the software tool validation as required by ISO 13485 in the chapters 4.1.6, 7.5.6 and 7.6. This blog takes a closer look at software tool validation and describes possible solutions to prove the suitability of software tools.

It’s all about the risk

ISO 13485 requires adjusting the rigor of the software tool validation to the risks associated with the software tool. Therefore, it is legitimate to have different validation approaches for different types of software, depending on their intended purpose. The validation of COTS (commercial of the shelf) software may require less effort than validation of MOTS (modifiable of the shelf) software or a self-written software.

The software validation activities should start with an overview list of all used software tools and a short description of the intended purpose. Risks that, in the event of a software tool failure, could lead to a product failure should also be included or referenced in this overview. These risks are the basis for the decision whether or not validation is required.

Based on criteria for validation defined in a SOP (standard operating procedure) or validation policy, the decision if a validation of the software tool is necessary, is documented in this overview list.

Establish criteria for validation and re-validation

Validation is only required if a malfunction of the tool can contribute to a risk for patients, users and third parties when using the manufactured medical device. To enable tool owners to make a decision about validation, criteria must be defined in the quality management system.

ISO 13485 itself provides the first indication of which criteria are eligible. The standard requires validation of software tools that influence product quality (e.g., version management systems, tools for continuous integration), that measure and monitor the manufacture of medical devices (e.g., unit test tools, static code analysis tools) and that are used within the quality management system (e.g., ticket system for error management, software used for document and record control). Further criteria can be found in the ISO TR 80002-2, but these criteria basically do not go beyond the requirements of ISO 13485.

When establishing the criteria for validation, also the criteria for re-validation should be documented. Revalidation is necessary if the intended use changes or additional requirements for application are added. An update that only fixes existing bugs or improves performance does not require re-validation. In any case, the responsibilities for revalidation must be defined to ensure that re- validation is done when necessary.

Define requirements

To be able to carry out a validation, requirements for the software tool are needed. In the best case, these requirements are defined before the tool is purchased. In practice, the requirements are often only created after the purchase and adapted to the tool. The requirements should have the same properties as any other product requirement and should be specific, measurable, attainable, realistic, and traceable.

The requirements for the software tool should focus not only on functionality, but also on meta data of the software tools, such as the time of availability of the tool, the user base and community or the frequency of updates and patches. The position of the manufacturer in the market (reliability) and the availability of support should also be considered.

Requirements management is an integral part of most of our training courses. If you want to learn more about the requirements, visit our training course website.

Take the first step towards mastering ISO 13485 by contacting our experienced consultants: Let us take your skills to the next level!

Learn more

Perform validation

One approach to perform software validation is to determine the importance of a requirement on a scale of one to ten and the fulfilment of this requirement by the software tool on a scale from one to ten and multiply the two numbers. The product of the multiplication is compared to a pre-defined threshold value. This validation approach is acceptable for COTS and MOTS software, but bespoke software should be validated in more detail.

For the validation of bespoke software, the GAMP 5 standard may be applied. The standard is originally intended for the pharmaceutical industry, but also medical device manufacturers refer to this standard for software tool validation. The standard also requires the tool owner to determine the requirements and to derive test cases for design qualification (DQ), installation qualification (IQ), operation qualification (OQ) and performance qualification (PQ). The execution of DQ, IQ, OQ and PQ are verification activities to gain trust in the software tool.

The GAMP 5 standard introduces four categories of software (software 1, software 3, software 4 and software 5) and determines test requirements for each category.

Category 3 can be compared to COTS software and category 4 to MOTS software. GAMP 5 suggests performing IQ, OQ and PQ for these software types but the manufacturer determines whether this is necessary for the validation of his software tool or if the above- described approach is sufficient.


Regardless of the method chosen for the validation, the validation must be planned in a validation plan and documented in a validation report. The report should contain a conclusion as to whether the software tool may be used for its intended purpose.


The regulatory framework does not provide a recipe for conducting validation, but it requires the manufacturers to gain trust in the used software tools used for medical device development. The aim of software tool validation is to ensure that no software tool contributes to a risk for patients, users and third- parties. ISO 13485 auditors are usually satisfied when they see that a manufacturer has a list of used software tools and has (documented) thoughts about the suitability of these software tools.

If you would like to go in more detail on software tool validation, visit our website with a wide range of training and consulting services.

By Verena Wieser, Medical Device Consultant

To learn more about ISO 13485 in our training course, feel free to reach out to us at Don’t hesitate to get in touch with us for further information.



We look forward to hearing from you.

    Show privacy policy