How to Make Software Validation Easier for Compliance with ISO 13485 and Pharma Regulations

By John Lafferty

Software Validation just got a whole lot easier.

The effort required comply with the software validation requirements of ISO 13485:2016 and 21 CFR Part 820 has been greatly reduced due to recent changes in regulations and guidance. Under the latest guidance, software validation can be completed faster, for less cost and using less documentation whilst resulting in improved software performance.

In this blog, John Lafferty, our Life Sciences Programme Director, explains how to use the latest guidance to validate software used in the manufacturing and testing of medical devices and in Medical Device Quality Management Systems.

Note: This article does not apply to Software in a Medical Device (SiMD) or Software as a Medical Device (SaMD)

Meeting the Software Validation Requirements of ISO 13485 for Medical Device Manufacturing: Key Takeaways

Software Validation is easier because;
The FDA have adopted ISO 13485:2016 as the basis for their QMSR and
Two guidance documents were issued
– the new FDA guidance on computer software assurance (CSA), and an updated edition of GAMP 5.

The FDA has clarified what is meant by validation in proportion to risk
The FDA has categorised risk into High-Process-Risk (High-Risk) and Not High-Process (Not High-Risk) Risk Software
To meet the requirements of ISO 13485:2016 and 21 CFR Part 820
- First understand the requirements, the output documentation and the templates required (shown below)
- Carry out ‘Critical Thinking’ around the intended use of your software
- Perform a Software Risk Assessment
- Categorise the Software using GAMP 5 Ed. 2
- Develop a Validation Strategy based on the GAMP Category and Risk Level
- Document this strategy in your Master Validation Plan
Software Validation used in Outsourced Processes is also Required

Topics covered in this blog:

Why has Software Validation become easier?
How does the FDA define High-Risk and Not High-Risk software?
How to meet the Software Validation Requirements of ISO 13485:2016 and 21 CFR Part 820
Documenting risk within the Master Validation Plan – a suggested layout
How to Categorise the Software Used at your Medical Device company
How to Develop a Validation Strategy based on GAMP Category and Risk
Examples of risk-based approaches to Testing and Documentation
Software Validation of Outsourced Processes
Software Validation Training

1) Why has Software Validation for Medical Devices Manufacturing become easier?

There are two reasons software validation became easier;

The FDA have adopted ISO 13485:2016 as the basis for their Quality Management System Regulation (QMSR) 21 CFR Part 820. This means that software validation requirements for Medical Device manufacturing/testing and Quality Management Systems worldwide are now based on the wording of ISO 13485:2016. This article references the applicable requirements of ISO 13485:2016 by clause number. Corresponding requirements are available in the updated 21 CFR Part 820 (QMSR) published on eCFR.gov. The QMSR will be enforced by the FDA from 2^nd February 2026 onwards. This means that companies that are already in compliance with the software validation requirements of ISO 13485:2016 will be in compliance with the requirements of the QMSR.
Two guidance documents which are designed to make software validation less burdensome and more effective have been published; these were GAMP 5 Edition 2 (published in July 2022 by ISPE.org) and the FDA Guidance on Computer Software Assurance for Production and Quality System Software (published in September 2025).

Note: The FDA Guidance – General Principles of Software Validation 2002 remains current and only Section 6 of that guidance has been superseded by the latest (2025) CSA guidance.

The FDA and ISPE (GAMP) Guidance Documents are Mutually Compatible.

The development of these two guidance documents involved extensive collaboration between the FDA and ISPE which means that they are mutually compatible. Both documents promote a focus on software quality assurance over software testing. Both documents promote a focus on good software engineering over documentation and give detail on how validation activities can be carried out in proportion to risk.

Clarity on the practical application of the concept of software validation in proportion to risk

For the first time, we have real clarity on the practical application of the concept of software validation in proportion to risk. The FDA CSA Guidance divides applications into two types;

High-Risk: Software where a malfunction could directly lead to harm to humans.
Not High-Risk: Software where a malfunction could not directly lead to harm to humans.

The word ‘directly’ is very important when distinguishing between the two types of software application. It should be noted that the thinking outlined in both the above guidance documents has been available for some time in ISO TR 80002-2:2017 “Medical device software — Part 2: Validation of software for medical device quality systems”. This guidance document can be used to support the validation approach for devices sold in regions outside of the US. In the experience of the author, this ISO guidance has not been widely used up to now; the reasons for this are not entirely clear.

2) How does the FDA define High-Risk and Not High-Risk Software?

The FDA CSA Guidance states ‘To determine whether the requirement for validation applies, manufacturers must determine whether the software is or will be used as part of production or the quality system (whether directly or to support production or the quality system)’. Software that is used directly is regarded as High-Risk software, and software that is not used directly is regarded as Not High-Risk software. Not High-Risk software may be further classified as Moderate (Medium) or Low Risk.

High-Risk software includes ‘Software intended for automating production processes, inspection, testing, or the collection and processing of production data; and software intended for automating quality system processes, collection and processing of quality system data, or maintaining a quality record established under applicable quality system regulations’.

Examples of High, Moderate and Low risk software applications, given in the FDA CSA Guidance 2025, are shown in Figure 1 below.

Figure 1: Examples of High, Moderate and Low Risk software applications

We can see from the above examples that the FDA CSA Guidance provides real clarity on software systems that should be considered as High-Risk and those that should be considered as Not High-Risk. In fact, the recommended approach in the guidance represents a significant departure from past thinking, where systems such as CAPA and Document Control systems may have been regarded as High-Risk.

The new approach which considers those systems to be Not-High risk, is based on the fact that any risk to product safety is an indirect risk. For a system to be considered indirect means that there must be other systems and/or human interventions in place, which have the potential to mitigate any risks. The guidance given in GAMP 5 Ed. 2: 2022 is in line with the FDA CSA Guidance. In the opinion of the author, the FDA CSA Guidance gives even greater clarity than GAMP 5 in this respect.

It is very important, at this point, to note two things;

Not High-Risk systems must still be validated, but the validation effort can be reduced.
Guidance from the FDA, WHO and MHRA contain specific recommendations on Data Integrity. These guidance documents must be considered when developing a validation strategy for any systems that contain critical data.

3) Examples of risk-based approaches to Validation Testing and Documentation

Examples of risk-based approaches to documentation (Figure 2) and testing (Figure 3) are shown below.

Figure 2: Example of a Risk-based approach to Software System Requirements Documentation

Figure 3: Example of a Risk-based approach to Software System Testing

4) How to meet the Software Validation Requirements of ISO 13485:2016 / 21 CFR Part 820

Extract from ISO 13485:2016
ISO 13485:2016 Section 4.1.6 “Quality management system, General requirements” and 7.5.6 “Validation of processes for production and service provision” state the following “The organisation shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application. The specific approach and activities associated with the software validation and revalidation shall be proportionate to the risk associated with the use of the software. Records of such activities shall be maintained”.

In a nutshell, what does the industry need to do?

Meeting the Requirements of ISO 13485:2016 – 3 Key Elements

The author, John Lafferty, has broken down the requirements into three elements, as shown in Figure 5 below:

Software Validation Requirements for ISO 13485:2016

Output Documentation
Templates Required

Figure 4: Software Validation – 3 Key Elements

5) Documenting Risk within the Master Validation Plan – suggested layout

In Figure 5 below, the author offers a suggested layout for documenting risk within the Master Validation Plan or Master register.

Figure 5: Suggested layout for documenting risk within the Master Validation Plan or Master register

The Risk Rating shown above could be binary – High-Risk or Not High-Risk, or High, Medium or Low risk.

According to both the FDA CSA Guidance 2025 and GAMP 5 Ed. 2, developing a validation strategy begins with ‘Critical Thinking’.

What is Critical Thinking?

Critical Thinking involves taking a step back and asking fundamental questions such as;

What does the software do?
Has that function a potential, direct impact on safety?
What can go wrong? (as opposed to how likely is something to go wrong)
What other controls are in place?

The output of critical thinking will determine if the overall system and specific elements of the system are High-Risk or Not High-Risk. Critical thinking should be performed using a cross-functional team. Clinical input may be required if clinical matters are being discussed.

Record Keeping of the Critical Thinking

It is advisable to keep records of Critical Thinking outcomes; these will provide part of the rationale for the chosen validation approach.

Perform a Software Risk Assessment

Critical Thinking should be followed by performing a more detailed risk assessment of the system. Auditing bodies often regard the software risk assessment as the most important element of the validation. Another valuable input to determining the validation strategy is the GAMP Category of the system.

6) How to Categorise the Software used at your Medical Device Company

The GAMP 5 guideline is the easiest model to follow to categorise the software. The tables shown in Figure 6 below outline the GAMP 5 classification of software and the associated validation effort required:

Figure 6: GAMP 5 classification of software and validation effort required

7) How to Develop a Validation Strategy based on GAMP Category and Risk

A combination of the risk level and the GAMP Category can be used to develop a validation strategy for the software, as shown in the table below. It should be noted that the validation options shown below are an example of a possible validation strategy only, and should not be considered definitive.

Figure 7: Example of a Validation Strategy

8) Software Validation of Outsourced Processes ISO 13485: 2016

Another aspect to consider, in relation to the software validation requirements of ISO 13485:2016, is software validation of outsourced processes. It has been noted at regulatory audits that auditors are more frequently requesting the reference numbers of the software validations of any critical processes that are outsourced by the organisation.
For example, if an organisation chooses to outsource a process, e.g. sterilisation, auditors may require the device manufacturer to maintain a record of the reference numbers of the software validation (if applicable) of that outsources sterilisation process.

This requirement is tied in with section 4.1.5 of ISO 13485:2016 as follows; “When the organization chooses to outsource any process that affects product conformity to requirements, it shall monitor and ensure control over such processes. The organisation shall retain responsibility of conformity to this international standard and to customer and application regulatory requirements for outsourced processes. The controls shall be proportionate to the risk involved and the ability of the external party to meet the requirements in accordance with 7.4. The controls shall include written quality agreements”

9) Software Validation Medical Devices Training Courses

We deliver training courses in Software Validation, you can learn more and book dates here. We also provide company-specific training tailored to your individual needs – contact us for a quote anytime.

Explanation of Abbreviations Used in this Article:

AFAP: As-far-as-possible
Annex 11: EU GMPs Vol 4 Annex 11 Computerised Systems
ALARP: As-low-as-reasonably-practicable
CFR: Code of Federal Regulations (US Federal Law)
COTS: Commercial-off-the-shelf (systems)
CSA: Computer Software Assurance
CSV: Computerised Systems Validation
dFMEA: Design Failure Modes and Effects Analysis
DQ: Design Qualification
DS: Design Specification
ERES: Electronic Records and Electronic Signatures
FAT: Factory Acceptance Testing
FDS: Functional Design Specification
FMEA: Failure Modes and Effects Analysis
FMECA: Failure Modes Effects and Criticality Analysis
FRS: Functional Requirements Specification
FS: Functional Specification
GAMP: Good Automated Manufacturing Practice
HDS: Hardware Design Specification
IQ: Installation Qualification
LTPD: Lot Tolerance Percent Defective
OQ: Operational Qualification
Part 11: 21 CFR Part 11 Electronic Records and Electronic Signatures
PQ: Performance Qualification
pFMEA:: Process Failure Modes and Effects Analysis
PHA: Preliminary Hazard Analysis
RTM: Requirements Traceability Matrix
SAT: Site Acceptance Testing
SDS: Software Design Specification
SV: Software Validation
UAT: User Acceptance Testing
URS: User Requirements Specification