Software is everywhere in medical device manufacturing — from the firmware embedded in your device to the ERP system managing your production records. And yet, software validation remains one of the most consistently misunderstood, and most frequently cited, areas in ISO 13485 audits.
I've spent 8+ years and more than 200 client engagements helping medical device companies build quality management systems that hold up under scrutiny. If there's one area where I see otherwise well-prepared organizations stumble, it's at the intersection of ISO 13485 software validation requirements, IEC 62304, and computer system validation (CSV). In this guide, I'll untangle all three — explain exactly what's required, how they relate to each other, and how to build a defensible, audit-ready validation program.
What ISO 13485 Actually Requires for Software Validation
ISO 13485:2016 addresses software in two distinct contexts, and confusing them is a common source of noncompliance.
Clause 4.1.6 requires that when computer software is used in the quality management system — think document control platforms, CAPA systems, ERP software, or calibration management tools — the organization must validate that software for its intended use prior to initial use and, as appropriate, after changes to the software or its application.
Clause 7.5.6 addresses software used as part of production and service provision — including automated testing equipment, manufacturing execution systems (MES), and software-controlled manufacturing processes. This clause requires validation before use and revalidation when changes occur.
Clause 7.3 (Design and Development) is where software as the medical device — or software as a component of a medical device — enters scope. Here, the internationally recognized harmonized standard is IEC 62304:2006+AMD1:2015, which provides a full software development lifecycle (SDLC) framework for medical device software.
Citation hook: ISO 13485:2016 clause 4.1.6 mandates validation of quality management system software prior to initial use and revalidation after any changes affecting intended use — a requirement that applies regardless of whether the software is purchased off-the-shelf or developed in-house.
IEC 62304: The SDLC Standard You Cannot Ignore
IEC 62304:2006+AMD1:2015 is the harmonized standard for medical device software lifecycle processes. It is harmonized under the EU MDR/IVDR and recognized by the FDA, making compliance with it the clearest path to demonstrating that your software development and maintenance practices meet regulatory expectations.
Software Safety Classifications Under IEC 62304
IEC 62304 requires that all medical device software be classified by safety class, which drives the rigor of the development lifecycle required:
| Safety Class | Definition | Key Lifecycle Requirements |
|---|---|---|
| Class A | No injury or damage to health possible | Basic software development plan, configuration management, problem resolution |
| Class B | Non-serious injury possible | All Class A requirements + software requirements analysis, architectural design, detailed design, software unit testing, integration testing |
| Class C | Death or serious injury possible | All Class B requirements + formal software unit verification, complete traceability from requirements through testing |
Citation hook: Under IEC 62304, approximately 80–90% of medical device software products in practice fall into Class B or Class C, meaning organizations must implement a full software development lifecycle with documented requirements, architecture, detailed design, and multi-level testing.
The safety class assignment must be documented and justified. Misclassifying software at Class A when it should be Class B or C is one of the most common findings during notified body reviews and FDA inspections.
The Five Core IEC 62304 Lifecycle Processes
IEC 62304 defines five software lifecycle processes your QMS must address:
- Software Development Planning — Define your SDLC model, deliverables, and risk management integration
- Software Requirements Analysis — Capture functional, performance, interface, and safety requirements
- Software Architectural Design — Document the software items, interfaces, and segregation of safety-critical components
- Software Construction — Coding standards, code review, and unit implementation
- Software Integration and Testing — Integration testing, system testing, and regression testing tied back to requirements
Additionally, IEC 62304 requires ongoing software maintenance processes, a software configuration management system, and a software problem resolution process — all of which must be documented within or referenced by your QMS.
Computer System Validation (CSV): What It Is and When It Applies
Computer System Validation is the process of establishing documentary evidence that a software system does what it is intended to do in a consistent, reliable, reproducible manner. CSV applies primarily to the quality and operational systems that support your QMS — the Clause 4.1.6 and 7.5.6 territory — rather than to the medical device software itself (which is governed by IEC 62304).
The GAMP 5 Framework: Industry's Most Cited CSV Model
The GAMP 5 (Good Automated Manufacturing Practice) framework, published by ISPE, remains the most widely adopted CSV methodology in the medical device and pharmaceutical industries. GAMP 5 categorizes software into five types that determine validation rigor:
| GAMP Category | Software Type | Examples | Validation Approach |
|---|---|---|---|
| Category 1 | Infrastructure software | OS, middleware, network software | Configuration records, vendor qualification |
| Category 3 | Non-configured standard software | Word processors, spreadsheet templates | Limited testing, standard operating procedures |
| Category 4 | Configured software | ERP, LIMS, EQMS, MES platforms | Full IQ/OQ/PQ with configuration specifications |
| Category 5 | Custom/bespoke software | In-house developed applications | Full SDLC validation + IQ/OQ/PQ |
(Note: GAMP 5 retired Category 2 in its second edition.)
The IQ/OQ/PQ Validation Protocol Sequence
The classic CSV validation protocol structure — Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) — remains the audit-expected framework for demonstrating system validation:
- IQ (Installation Qualification): Verifies the system is installed correctly per vendor specifications — hardware, software version, network environment, security settings
- OQ (Operational Qualification): Tests that the system functions as specified across its normal and worst-case operating parameters — typically executed against a formal test script
- PQ (Performance Qualification): Demonstrates that the system consistently performs as intended in its actual production environment using real or representative data
Citation hook: A computer system validation package for a GAMP Category 4 system typically requires a minimum of seven core documents: a validation plan, user requirements specification (URS), functional specification, risk assessment, IQ protocol and report, OQ protocol and report, and PQ protocol and report — with all documents reviewed and approved prior to system go-live.
How ISO 13485, IEC 62304, and CSV Fit Together
One of the most common questions I receive from clients is: "Do we need IEC 62304 and CSV, or is one enough?" The answer depends on what the software does and where it sits in your product and quality ecosystem.
Here's a practical decision framework:
| Software Type | Applicable Standard/Approach | Governing ISO 13485 Clause |
|---|---|---|
| Software as a medical device (SaMD) | IEC 62304 full SDLC | Clause 7.3 (Design & Development) |
| Software in a medical device (embedded firmware) | IEC 62304 full SDLC | Clause 7.3 (Design & Development) |
| Software used in manufacturing/production | CSV (IQ/OQ/PQ, GAMP 5) | Clause 7.5.6 |
| Software used in the QMS (eQMS, document control, CAPA) | CSV (IQ/OQ/PQ, GAMP 5) | Clause 4.1.6 |
| Off-the-shelf software used as a QMS tool | Vendor qualification + limited CSV | Clause 4.1.6 |
In many organizations, there is a third category of software that often falls through the cracks: software used in quality control and testing, such as automated inspection software or statistical analysis tools. These typically require CSV treatment under Clause 7.5.6 and may require additional consideration under Clause 7.6 (monitoring and measuring equipment).
Building a Compliant Software Validation Program: 8 Practical Steps
Whether you're building your program from scratch or remediating gaps ahead of a surveillance audit, here's the approach I use with clients at Certify Consulting:
Step 1: Conduct a Software Inventory
Identify every piece of software in your QMS and production environment. This inventory should capture: software name and version, vendor, purpose/intended use, applicable clause (4.1.6, 7.5.6, or 7.3), GAMP category (if CSV applies), and IEC 62304 safety class (if SaMD/embedded).
Step 2: Assign Risk-Based Classification
Use your risk management procedure to classify each system by potential impact on product quality and patient safety. Higher-risk systems warrant more rigorous validation.
Step 3: Establish a Validation Master Plan (VMP)
The VMP is the overarching document that defines your validation philosophy, scope, organizational responsibilities, standard formats for validation documents, and change control procedures. It is the document auditors ask for first.
Step 4: Write User Requirements Specifications (URS)
For every system undergoing CSV, the URS captures what the system must do — written from the user's perspective, not the vendor's. Tie each URS requirement to a test case. This traceability is your audit lifeline.
Step 5: Execute Vendor Qualification
For commercial off-the-shelf (COTS) software, evaluate the vendor's development practices, validation documentation, and quality system. A strong vendor audit or questionnaire can reduce the scope of your own testing — regulators explicitly recognize the concept of "leveraging vendor testing."
Step 6: Execute and Document IQ/OQ/PQ Protocols
For GAMP Category 4 and 5 systems, execute formal installation, operational, and performance qualification protocols. Every test step should include an expected result, actual result, pass/fail determination, and tester signature with date.
Step 7: Establish Change Control for Validated Systems
Once validated, changes to the system — including software updates, configuration changes, and hardware changes — must go through a formal change control process that assesses whether revalidation is required. This is where many organizations have gaps: they validate once and then allow IT to apply patches without re-evaluation.
Step 8: Maintain Validation Status
Periodic review of validated systems (typically annual) should confirm that the system remains in a validated state and that no undocumented changes have occurred. This is your validated system requalification or periodic review.
What FDA Expects: 21 CFR Part 11 and Software Validation
For U.S.-regulated medical device manufacturers, software validation requirements extend beyond ISO 13485 and IEC 62304 to include 21 CFR Part 820.70(i) (QSR/Quality System Regulation) and, for electronic records and signatures, 21 CFR Part 11.
Under the FDA's own guidance document "General Principles of Software Validation" (2002, still in effect), the FDA affirms that software validation is a risk-based activity and that the level of documentation and testing should be commensurate with the risk the software poses to the finished device and to the patient.
Additionally, FDA's updated Quality Management System Regulation (QMSR), effective February 2026, aligns 21 CFR Part 820 more closely with ISO 13485:2016, meaning that ISO 13485-aligned validation documentation increasingly satisfies FDA expectations as well.
The 5 Most Common Software Validation Audit Findings
In my experience supporting clients through ISO 13485 certification audits, FDA inspections, and notified body reviews, these are the recurring software validation findings:
- No software inventory — The organization cannot demonstrate they know which software systems are in scope for validation
- Missing revalidation after updates — Software updates (including vendor-pushed patches) applied without change control assessment or revalidation
- Inadequate URS-to-test traceability — Test scripts that don't map back to specific user requirements
- IEC 62304 safety class undocumented — SaMD or embedded software with no documented safety classification rationale
- Spreadsheet validation gaps — Excel/Google Sheets used for quality records without documented validation of formulas, macros, and access controls (a perennially overlooked Clause 4.1.6 gap)
Frequently Asked Questions: ISO 13485 Software Validation
Does ISO 13485 require IEC 62304 compliance?
ISO 13485:2016 does not explicitly mandate IEC 62304 compliance; however, IEC 62304 is harmonized under EU MDR/IVDR and referenced in FDA guidance, making it the industry-accepted standard for satisfying software lifecycle requirements under Clause 7.3. Most notified bodies and FDA investigators expect IEC 62304 documentation for any software that is or contains a medical device function.
What is the difference between software verification and software validation in ISO 13485?
Verification confirms that software outputs meet specified requirements at each development phase ("did we build it right?"), while validation confirms that the final software meets its intended use and user needs ("did we build the right thing?"). ISO 13485 and IEC 62304 require both: verification activities at each lifecycle stage and a final validation before release.
Do off-the-shelf QMS software platforms like Veeva or MasterControl need to be validated?
Yes. Any software used to manage QMS records — including commercial EQMS platforms — must be validated under ISO 13485 clause 4.1.6. The validation scope can be reduced by leveraging vendor qualification and vendor-supplied validation documentation, but the user organization retains ultimate responsibility for demonstrating the system is fit for its intended use.
How long should software validation documentation be retained?
ISO 13485:2016 clause 4.2.5 requires that records be retained for a period at least equal to the lifetime of the medical device, but not less than 2 years from the date of release of the medical device. Many organizations apply a minimum 5–10 year retention period for validation records, particularly for systems used in design and manufacturing.
What triggers revalidation of a validated software system?
Revalidation is triggered by changes to the software itself (version upgrades, patches, configuration changes), changes to the hardware environment, changes to the intended use or business processes the system supports, and periodic reviews that identify undocumented changes or performance issues. Your change control SOP should define explicit revalidation triggers and an impact assessment process.
Summary: A Defensible Software Validation Strategy
Building a software validation program that satisfies ISO 13485, IEC 62304, GAMP 5, and FDA expectations isn't about generating paper for its own sake. It's about systematically demonstrating that every software system touching your product quality or patient safety is fit for its intended purpose and remains so over time.
The framework is straightforward: - IEC 62304 governs software in or as your medical device (Clause 7.3) - CSV / GAMP 5 governs software supporting your QMS and production (Clauses 4.1.6 and 7.5.6) - A software inventory + risk classification ensures nothing falls through the cracks - Change control keeps validated systems in a validated state
If you're preparing for an initial certification audit, a surveillance audit, or an FDA inspection, I recommend starting with the software inventory and working your way through the classification exercise. That single activity typically surfaces 80% of your gaps.
For organizations that need expert guidance building or remediating a software validation program, the team at Certify Consulting has helped 200+ medical device companies achieve and maintain ISO 13485 certification — with a 100% first-time audit pass rate.
Related reading: Understanding ISO 13485 Design Controls and IEC 62304 Integration | How to Build an ISO 13485 Risk Management Program Under ISO 14971
Last updated: 2026-03-17
Jared Clark
Certification Consultant
Jared Clark is the founder of Certify Consulting and helps organizations achieve and maintain compliance with international standards and regulatory requirements.