Better Insights For ISO 13485: 2016 Software Validation Requirements
ISO 13485 software validation is the documented process of demonstrating that software used in a medical device manufacturer’s quality management system or production processes is suitable for its intended use and performs consistently as required.
The validation approach should be risk-based and proportionate to the software’s intended use and potential impact on product quality, safety, regulatory compliance, and data integrity. Depending on the software, validation activities can include requirements definition, risk assessment, supplier evaluation, testing, approval, change control, validation records, and revalidation.
For manufacturers supplying the US market, this topic has become particularly important because the FDA’s Quality Management System Regulation (QMSR) became effective on February 2, 2026, incorporating ISO 13485:2016 by reference into 21 CFR Part 820.
Talk to our experts
What Is Software Validation in ISO 13485?
Software validation is the documented process used to establish confidence that software performs its intended functions consistently and reliably.
In a medical device quality system, software can support activities such as:
- Quality management and document control
- Electronic quality management systems (eQMS)
- Enterprise resource planning (ERP)
- Laboratory information management systems (LIMS)
- Complaint management
- Supplier quality management
- Training and records management
- Production and process control
- Inspection and testing
- Data collection and reporting
The validation requirement is not simply about confirming that software works. The manufacturer needs to establish that the software is appropriate for its intended use within its specific processes and configuration.
Why Is QMS Software Validation Important?
Medical device manufacturers increasingly depend on software to manage quality records, production activities, design information, complaints, supplier data, and regulatory documentation.
If software performs incorrectly, it can affect the reliability of records or decisions that influence product quality and regulatory compliance.
A properly planned validation process can help manufacturers:
- Demonstrate that software performs as intended
- Reduce risks associated with incorrect or lost data
- Maintain reliable electronic records
- Support regulatory inspections
- Establish objective evidence of testing
- Control software changes
- Identify failures before they affect quality processes
- Maintain confidence in critical QMS functions
For manufacturers supplying the United States, FDA’s current QMSR framework incorporates ISO 13485:2016 and became effective on February 2, 2026.
What Software Needs to Be Validated?
Not every software application requires the same level of validation effort.
The key question is whether software is used in a process covered by the quality management system or production activities and whether its failure could affect product quality, safety, compliance, or data integrity.
Examples can include:
| Software | Possible Application |
|---|---|
| eQMS | Document control, CAPA, training, audits |
| ERP | Purchasing, inventory and production processes |
| LIMS | Laboratory testing and quality records |
| Complaint management software | Complaint investigation and reporting |
| Calibration software | Equipment and measurement records |
| Production software | Manufacturing and process control |
| Electronic records systems | Controlled quality records |
| Spreadsheet tools | Calculations, analysis or quality decisions |
The validation effort should be determined according to the software’s intended use and associated risks rather than applying exactly the same testing approach to every application.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
ISO 13485 Software Validation Requirements
A practical ISO 13485 software validation program should address several key areas.
1. Define the Intended Use
Start by clearly documenting what the software is expected to do.
The intended use should identify the processes supported by the software, users, important functions, interfaces, records generated, and potential consequences if the software fails.
2. Perform a Risk Assessment
Assess the potential impact of software failure.
Higher-risk functions may require greater testing depth and stronger objective evidence. For example, software used to control critical production parameters may require more rigorous validation than software used for a lower-risk administrative activity.
3. Establish User and Functional Requirements
Document what the software needs to accomplish.
Requirements can address:
- Functional performance
- Data entry and calculations
- User access controls
- Electronic records
- Audit trails
- Interfaces
- Reporting
- Data retention
- Security
- Backup and recovery
These requirements provide a foundation for subsequent testing.
4. Evaluate the Software Supplier
For commercial or cloud-based software, evaluate the supplier according to the risk and intended use.
Supplier information, specifications, testing evidence, release controls, support arrangements, and change-management practices can help inform the manufacturer’s validation strategy.
However, supplier testing does not automatically replace the manufacturer’s responsibility to demonstrate that the software is suitable for its intended use in its own environment.
5. Develop a Validation Plan
A validation plan should define the scope, responsibilities, acceptance criteria, testing approach, required documentation, and approval process.
The plan should be appropriate to the risk associated with the software.
6. Conduct Verification and Validation Testing
Testing should demonstrate that the software meets defined requirements.
Depending on the application, activities can include:
- Installation qualification or equivalent installation checks
- Functional testing
- User acceptance testing
- Interface testing
- Data integrity testing
- Access control testing
- Backup and recovery testing
- Error and exception testing
- Performance testing where applicable
The specific activities should be determined according to intended use and risk.
7. Maintain Validation Records
Maintain objective evidence showing what was tested, how it was tested, the results obtained, deviations identified, corrective actions taken, and final approval.
Validation documentation may include:
- User requirements
- Risk assessment
- Validation plan
- Test protocols
- Test results
- Deviations
- Traceability records
- Validation report
- Approval records
- Change-control records
Schedule a Compliance Consultation
Accelerate Market Access with End-to-End Regulatory Guidance
What Is Revalidation?
Revalidation is the assessment performed when changes could affect the validated state of the software.
Revalidation may be necessary following:
- Major software upgrades
- Changes to intended use
- Significant configuration changes
- New integrations
- Changes to critical workflows
- Changes affecting data integrity
- Changes required by regulatory or quality requirements
Not every software update automatically requires complete revalidation. The appropriate response should be determined through documented change control and risk assessment.
ISO 13485 Software Validation and FDA QMSR in 2026
The US regulatory environment has an important update for medical device manufacturers.
The FDA QMSR became effective on February 2, 2026 and incorporates ISO 13485:2016 into 21 CFR Part 820. FDA also issued its final Computer Software Assurance for Production and Quality Management System Software guidance in February 2026.
The FDA guidance describes a risk-based approach for establishing confidence in software used for production and quality management systems. It also discusses different testing methods and the level of rigor that may be appropriate based on risk.
This means manufacturers supplying the US market should consider their software validation and assurance processes as part of their overall QMS compliance strategy.
Software Validation vs Medical Device Software Validation
It is important to distinguish between two different situations.
QMS or production software supports the manufacturer’s processes, such as an eQMS, ERP or production system.
Medical device software is software that itself performs a medical device function or forms part of a medical device.
The regulatory expectations and documentation can differ. Device software may involve additional design, development, verification, validation, risk management, cybersecurity, and premarket documentation requirements.
Therefore, manufacturers should first determine the role and intended use of the software before defining the validation strategy.
How Operon Strategist Can Help
Operon Strategist supports medical device manufacturers with ISO 13485 consulting, QMS implementation, regulatory compliance, documentation, and quality system activities.
Our support can include:
- ISO 13485 QMS implementation
- Software validation planning
- QMS documentation
- Risk-based validation approaches
- Validation protocols and records
- Change-control procedures
- Regulatory compliance support
- Medical device regulatory consulting
- FDA and international market-entry support
A properly structured software validation process can help manufacturers maintain reliable QMS processes and demonstrate objective evidence of compliance.
Ensure Seamless Regulatory Compliance for Your Device
Get Your Medical Device Market-Ready with Expert Regulatory Support
FAQ's
Is software validation required under ISO 13485?
Software used in the quality management system or production processes should be evaluated and controlled according to its intended use and risk. The validation approach should be appropriate to the software’s impact on the QMS and medical device quality.
Does an eQMS need to be validated?
An eQMS may require validation when it is used to support quality management processes. The scope and depth of validation should be based on intended use and risk.
Does the software vendor's testing replace validation?
Not necessarily. Vendor testing can provide useful evidence, but the manufacturer should establish that the software is suitable for its intended use in the manufacturer’s own environment and configuration.
When is revalidation required?
Revalidation should be considered when changes to software, configuration, intended use, interfaces, or critical functions could affect the validated state. A documented change-control and risk assessment process should determine the appropriate action.
Is ISO 13485 software validation the same as medical device software validation?
No. Software used to support manufacturing or QMS activities is different from software that is itself a medical device or part of a medical device. The applicable regulatory and validation requirements can therefore differ.