Computer Software Validation (CSV and CSA) for Medical Device Manufacturers

Computer software validation (CSV) is the discipline of proving that software used in your quality system or production does what you intend, reliably and with trustworthy records. FDA’s move towards Computer Software Assurance (CSA) has changed how much documentation teams produce, but not the underlying duty. This guide explains what needs validating, how a risk-based approach works, and how to document it without drowning in paperwork.

What software needs validation?

This guide is about software you use to make or control the device and its records, not software inside the device. Software that is part of a device (embedded software or software as a medical device) follows a lifecycle standard such as IEC 62304; see our SaMD training and SOUP guide.

Examples of software that usually needs validation include:

• Electronic quality management systems for document control, CAPA, complaints, training and change control.
• ERP and MRP systems that control inventory, lot traceability and release.
• Manufacturing execution systems, test equipment software, and programmable logic controllers on production equipment.
• Inspection and measurement software, statistical tools and spreadsheets that support release decisions.
• Complaint, PMS and vigilance databases.

The regulatory basis

ISO 13485:2016 requires the organisation to document procedures for validating the application of computer software used in the quality management system (clause 4.1.6) and for software used in production and service provision (clause 7.5.6), and in monitoring and measurement (clause 7.6). The validation must be proportionate to the risk and carried out before first use, with records kept. FDA incorporates ISO 13485 through the QMSR, effective 2 February 2026. For electronic records and signatures, 21 CFR Part 11 applies where records are required by FDA rules and are kept electronically.

FDA published its final guidance Computer Software Assurance for Production and Quality System Software in September 2025. It describes a risk-based approach that focuses effort on software whose failure could compromise product quality or patient safety. Confirm the current version on FDA’s website, as guidance can be revised.

CSV versus CSA: what actually changed

Topic	Traditional CSV habit	Risk-based CSA approach
Focus	Documenting every test	Assuring software is fit for its intended use
Test depth	Same scripted testing for all features	Rigour matched to the risk of each function
Test methods	Mostly fully scripted, with screenshots	Scripted, unscripted, exploratory and error-guessing methods as appropriate
Records	Large volumes of evidence	Enough evidence to show what was done, the result and the conclusion
Vendor evidence	Often repeated	Leverage supplier testing where credible

The change is in emphasis. You still need an intended use statement, a risk assessment, testing and a conclusion. You may produce less low-value paper.

A practical risk-based workflow

1. Define intended use. What does the software do, which records or decisions does it affect and who uses it?
2. Assess risk. Ask whether a failure of each function could cause a product quality or patient safety problem, or compromise a regulated record. Classify functions as high process risk or not high.
3. Assess the supplier. Review the vendor’s quality system, release testing and track record. For configurable or cloud systems, understand how updates are delivered and communicated.
4. Plan assurance activities. Choose methods by risk. High-risk functions get scripted testing with objective evidence. Lower-risk functions may rely on unscripted testing, vendor evidence or ad hoc testing, with a brief record.
5. Execute and record. Capture what was tested, the result, any deviations and who approved. Resolve anomalies and re-test.
6. Release for use. Approve the system with a summary conclusion, training and a procedure for operation.
7. Maintain the validated state. Control changes, patches and upgrades with a documented impact assessment, and periodically review access, backups and audit trails.

Electronic records, signatures and data integrity

Where Part 11 applies, you need access controls, unique user accounts, secure audit trails, controlled signatures that link to the record, and backup and archive arrangements. Data integrity expectations (often summarised as ALCOA+: attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring and available) apply to all quality records regardless of format. Spreadsheets used for calculations should be locked, version-controlled and verified.

Common findings

• No intended use statement, so the testing scope cannot be justified.
• The vendor’s validation accepted without review of whether it covers your configuration.
• Patches installed automatically with no impact assessment.
• Spreadsheets used for release decisions with unlocked formulas and no verification.
• Shared logins that defeat the audit trail.
• Validation done at go-live and never reviewed again.

Software used in production also links to process validation, and cybersecurity of connected systems is covered in our medical device cybersecurity guide.

Frequently asked questions

Is CSA a replacement for CSV?

CSA is a risk-based way of meeting the same validation obligation. You still need to show software is fit for its intended use. The difference is that effort and documentation follow risk rather than a uniform checklist.

Do cloud and SaaS tools need validation?

Yes, when they are used in the quality system or production. You validate the application for your intended use and assess the supplier, including how changes to the service are managed.

Do I need to validate Excel spreadsheets?

If a spreadsheet supports a quality or release decision, it should be verified, protected from unintended change and controlled. The depth depends on the risk of an error.

Is IEC 62304 the same as CSV?

No. IEC 62304 governs the software lifecycle of software that is part of a medical device. CSV applies to software used to make the device or run the quality system.

Confirm the current text of ISO 13485, 21 CFR Part 11 and FDA guidance before writing them into procedures.

Talk to the AptSkill team

Want help scoping validation for your eQMS or production software? Send us a message.