---
title: Computer System Validation (CSV) for Medical Device Manufacturing Software
description: Computer System Validation under EN ISO 13485:2016+A11:2021 clauses 4.1.6 and 7.5.6. Risk-based CSV for startups, with a label printer worked example.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: computer system validation manufacturing software medical device
canonical_url: https://zechmeister-solutions.com/en/blog/csv-manufacturing-software-medical-device
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Computer System Validation (CSV) for Medical Device Manufacturing Software

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Computer System Validation is the documented, risk-based process of proving that a piece of software used in your QMS or in your production process does what you need it to do, reliably, for its intended use. Under EN ISO 13485:2016+A11:2021 it is mandatory in two places: clause 4.1.6 for software used in the quality management system, and clause 7.5.6 for software used in production and service provision. The validation effort must be proportionate to the risk the software creates for product conformity or patient safety — not uniform across every tool.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- EN ISO 13485:2016+A11:2021 clause 4.1.6 requires validation of any software used in the QMS, and clause 7.5.6 requires validation of any software used in production or service provision that can affect product conformity.
- Both clauses explicitly allow the validation effort to be proportionate to the risk the software creates, including its effect on the ability of the product to conform to specifications. Risk is the dial.
- Validation is not a single activity. It is a documented package: intended use, risk assessment, requirements, installation and configuration evidence, functional testing, and a release decision by a named person.
- The classical IQ/OQ/PQ structure from pharma CSV works for MedTech, but most startup tools need only a lean version with installation, operational, and intended-use testing recorded on a few pages.
- A label printer driven by an ERP or a homemade script is the single most common validation gap Tibor finds at first audits. Mislabelled devices are a safety hazard, a market withdrawal risk, and a reliable source of major non-conformities.
- CSV is a living obligation. Revalidation is required after significant changes to the software, its configuration, or the process it supports.

---

## Why this matters for your startup

A QA manager at a 12-person cardiovascular startup sent Tibor a panicked message the day before a Stage 2 audit. The notified body had asked in advance for the validation file of the label printer software. She went looking and found nothing — not because nobody had thought about it, but because everyone had assumed "the printer just prints labels." Labels contain the UDI, the lot number, the expiry date, the symbols, the manufacturer name. If the printer drops a character, prints a wrong lot, or silently fails to encode the UDI barcode, a non-conforming product ships. That is a patient safety issue and a recall trigger.

She had 18 hours to close the gap. The audit went fine — not because they faked a validation file, but because the printer setup was genuinely simple, the risk was well understood once she sat with it for an hour, and a focused three-page validation summary with real screenshots, a real test run, and a real release signature was enough. The auditor's issue was never the length of the document. It was the absence of one. This post is the document you wish you had written six months before the audit.

## What the standard actually says

EN ISO 13485:2016+A11:2021 contains two distinct validation obligations for software that is not the medical device itself.

**Clause 4.1.6 — Software used in the quality management system.**

> *"The organization 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 software validation and revalidation shall be proportionate to the risk associated with the use of the software, including the effect on the ability of the product to conform to specifications."*
> — EN ISO 13485:2016, clause 4.1.6.

This covers the tools that run your QMS: your eQMS, your document control system, your training record software, your CAPA and complaint handling database, your internal audit tracker, your risk management tooling, your spreadsheet that lists approved suppliers, your eLearning platform. If it holds QMS records or enforces QMS workflow, it falls under 4.1.6.

**Clause 7.5.6 — Software used in production and service provision.**

> *"The organization shall document procedures for the validation of the application of computer software used in production and service provision. 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 software validation and revalidation shall be proportionate to the risk associated with the use of the software, including the effect on the ability of the product to conform to specifications."*
> — EN ISO 13485:2016, clause 7.5.6.

This covers the tools that run your production process: label printers, barcode scanners, ERP modules that release finished goods, automated test equipment with firmware, PLCs on manufacturing lines, a Python script that calculates a critical dimension, a spreadsheet that decides whether a batch passes inspection.

Both clauses carry the identical proportionality language. That is the load-bearing word. Proportionality means risk drives depth. Low risk, lean file. High risk, full file.

The validation obligation maps back to MDR Article 10(9), which requires manufacturers to operate a QMS proportionate to the risk class and type of device. If your QMS runs on software, and the software is not validated, your QMS is not compliant with Article 10(9) via clauses 4.1.6 or 7.5.6.

## Risk-based validation in practice

Risk-based does not mean skipping validation on cheap or familiar tools. It means matching the evidence depth to what can go wrong.

For every piece of in-scope software, ask three questions and write down the answers.

1. **What is the intended use?** One sentence. "This ERP prints product labels with UDI and lot number for finished devices." "This spreadsheet tracks supplier qualification status and drives the approved supplier list." Be specific — a vague intended use produces a vague validation.
2. **What can go wrong, and what is the effect on the product or on QMS integrity?** This is an EN ISO 14971:2019+A11:2021-style hazard analysis applied to the software, not to the device. Wrong label content leading to mis-identification. Dropped CAPA record leading to an unclosed safety signal. Silent calculation error leading to a batch released out of specification. Note the failure mode and its downstream effect.
3. **What controls does the software already have, and what do you need to add?** Vendor validation, audit trails, access controls, configuration baselining, input checks, backup/restore, change management. Some controls come from the vendor. Some you have to build.

A tool that only handles non-critical records at low risk (a training log for internal staff training) might warrant a one-page validation summary. A tool that controls product identity, release decisions, or safety-critical calculations needs a multi-section validation file with documented test runs.

## IQ/OQ/PQ, translated for MedTech startups

The IQ/OQ/PQ pattern — Installation Qualification, Operational Qualification, Performance Qualification — comes from pharmaceutical CSV and is overkill for many MedTech startup tools. But the underlying concept is useful as a structural checklist.

- **Installation Qualification (IQ):** The software is installed in the right environment, on the right infrastructure, with the right configuration, and the installation is documented. For a SaaS eQMS this is a tenant setup record with the vendor. For a local tool this is a screenshot of the version and configuration.
- **Operational Qualification (OQ):** The software's functions work as specified under normal and boundary conditions. This is your functional test. The tests have to match the intended use from step 1 above.
- **Performance Qualification (PQ):** The software does what you need it to do in your actual process, with your actual data, operated by your actual users. This is the test that closes the loop between software function and process outcome.

For a three-person startup with a cloud eQMS, IQ/OQ/PQ often collapses into a single validation summary of roughly three to eight pages: intended use, risk assessment, vendor information and vendor validation leverage, the installation and configuration record, a short functional test of the features you actually use, a performance test using realistic data, and a release decision signed by the process owner. That is a complete validation file. It is not a pharma-factory PQ protocol, and it does not need to be.

## Worked example: validating a label printer

A cardiovascular startup in Styria uses a desktop thermal transfer printer driven by a SaaS ERP to print product labels for a Class IIa device. The label contains the device name, the UDI-DI and UDI-PI, the lot number, the manufacturing date, the expiry date, the CE mark with the notified body number, and the required symbols per EN ISO 15223-1 (referenced by MDR Annex I). A wrong label is a non-conforming product.

The validation file, built lean and honest, contains:

1. **Intended use.** "The ERP label print function, via the connected thermal transfer printer, prints product labels for finished devices of model X at the manufacturing site. It is used for every production lot."
2. **Risk assessment.** Hazards identified: wrong UDI-DI, wrong UDI-PI (lot), wrong expiry date, missing symbol, printer drop-out mid-batch, barcode unreadable by scanner. Each mapped to its effect on product conformity and patient safety, and to existing or added controls (ERP input validation, end-of-line scanner verification of the printed UDI, printer self-test on startup, monthly print-quality check, lot reconciliation at end of run).
3. **Installation record.** ERP version, printer model and firmware version, driver version, label template version, screenshot of the printer configuration screen, date, installer name.
4. **Functional test (OQ equivalent).** A test print for each label variant the company uses. A test of the input validation — tries to print with missing lot, expects an error. A test of the scanner verification loop — scans a correct barcode and a deliberately damaged barcode, expects a pass and a fail respectively.
5. **Performance test (PQ equivalent).** A small production lot of 20 units labelled end-to-end, with each label verified against the batch record, signed off by production and QA.
6. **Release decision.** The QA manager signs the validation summary, stating the system is released for use for its intended use, with the listed configuration, until a change triggers revalidation.

Total page count: roughly four to six pages plus screenshots and test records. A notified body auditor who reads this can see exactly what is validated, against what risk, with what evidence, released by whom. That is what clause 7.5.6 asks for.

## The Subtract to Ship CSV playbook

Applied to computer system validation, Subtract to Ship gives a rule and a checklist.

**The rule:** every validation document must earn its place by pointing to the risk it controls. If the document does not map to a real hazard from a real piece of software used in your real QMS or production, it comes out.

**The checklist for a lean startup CSV program:**

1. Maintain a single inventory of all software used in the QMS (clause 4.1.6 scope) and in production and service provision (clause 7.5.6 scope). One spreadsheet is enough. Every line has an owner.
2. For each entry, run the three-question risk screen. Classify the software as low, medium, or high risk based on its effect on product conformity or QMS integrity.
3. For each entry, produce a validation file proportionate to the risk rating. Low risk: a one- to two-page summary. Medium risk: a three- to eight-page summary with real test records. High risk: a full structured validation with formal protocol and report.
4. For each entry, define the revalidation triggers: vendor version upgrade past a configurable threshold, configuration change, workflow change, a change in intended use, a failure or incident, or a scheduled periodic review.
5. Hold the validation files in the same document control system that holds the rest of the QMS. They are controlled documents. They have versions, approvers, and effective dates.
6. When a notified body auditor asks for the validation of your eQMS, your label printer, or your release-decision spreadsheet, you hand over the file within a minute. That is the test.

Nothing in this playbook requires buying a CSV platform or hiring a CSV specialist. It requires discipline and the honest three-question risk screen.

## Reality Check — Where do you stand?

Answer these honestly before your next audit.

1. Can you produce, in under 60 seconds, a single inventory of every piece of software used in your QMS and in your production process, with its risk classification and its validation status?
2. For your eQMS — or your equivalent document and record control tool — is there a validation file signed and released before the tool was first used for live QMS records?
3. For every software tool that influences product identity (label printers, UDI encoders, barcode generators, ERP release decisions), can you show the validation file right now?
4. For every spreadsheet or script that performs a calculation whose output drives a release or inspection decision, is there a validation record and a change log?
5. Do you have documented revalidation triggers, and has any tool in your inventory actually been revalidated since first use — or are all the files dated the day you started the QMS?
6. If an auditor asked, "show me the validation of the cloud tool your CAPA system runs on," could you answer in one minute with a document, not with an explanation?

A no on any of these is a 4.1.6 or 7.5.6 finding waiting to happen.

## Frequently Asked Questions

**Does EN ISO 13485:2016+A11:2021 require me to validate my cloud-based eQMS?**
Yes. Clause 4.1.6 applies to any software used in the QMS, including SaaS eQMS platforms. You may leverage the vendor's own validation and quality documentation, but you still need a documented validation file for how the tool is configured and used in your specific QMS, signed off before first use.

**What is the difference between clause 4.1.6 and clause 7.5.6?**
Clause 4.1.6 covers software used in the quality management system itself — your eQMS, document control, training, CAPA tooling. Clause 7.5.6 covers software used in production and service provision — your ERP label printer driver, your automated test equipment, your release-decision spreadsheet. The validation requirements and the proportionality language are effectively identical; the scope is what differs.

**Do I really have to validate a spreadsheet?**
If a spreadsheet holds QMS records, enforces QMS workflow, or drives a production or release decision, yes. A spreadsheet that tracks the holiday calendar does not need validation. A spreadsheet that calculates whether a batch passes an inspection limit does. Risk is the dial.

**How detailed does a startup validation file really need to be?**
Proportionate to the risk the software creates. A low-risk training log can be a one-page summary. A label printer with UDI encoding needs a multi-section file with real test runs. A safety-critical release calculation needs a full validation with protocol and report. There is no fixed page count — there is a fixed expectation that the evidence is sufficient for the risk.

**Can I leverage the vendor's validation documentation?**
Yes, partially. Vendor documentation — ISO 27001 reports, SOC 2 reports, the vendor's own software validation package — can reduce your workload, but it does not replace your own validation. You still have to document the intended use in your process, your configuration, your users, and your own functional and performance tests. The vendor validates the product; you validate the application of the product in your QMS.

**When do I have to revalidate?**
After significant changes. That covers software upgrades beyond your defined threshold, configuration changes, workflow changes that alter how the tool is used, changes in intended use, and any failure or incident involving the tool. It is also good practice to define a periodic review cadence for higher-risk tools, even without a change trigger.

## Related reading

- [eQMS Platforms for MedTech Startups in 2026](eqms-platforms-startups-2026) — the sibling post on choosing the eQMS that you will then validate under clause 4.1.6.
- [Process Validation Under MDR and EN ISO 13485](process-validation-mdr-iso-13485) — the process-side companion to this post, covering validation of production processes themselves, not just the software that runs them.
- [Validating QMS Software Tools Under the MDR](validating-qms-software-tools-mdr) — the deep-dive walkthrough of a clause 4.1.6 validation package for an eQMS.
- [The Minimum Viable QMS: What You Need Before Your First Audit](minimum-viable-qms) — the QMS context this CSV obligation sits inside.
- [Common QMS Audit Non-Conformities](common-qms-audit-nonconformities) — missing or thin CSV is a recurring entry on this list.
- [AI Medical Devices and the MDR Regulatory Landscape](ai-medical-devices-mdr-regulatory-landscape) — the SaMD cluster pillar this post sits under.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices. Consolidated text on EUR-Lex. Article 10, paragraph 9.
2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clauses 4.1.6 and 7.5.6. Current harmonised edition.
3. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices. Current harmonised edition. Referenced as the risk management method underpinning the risk-based validation approach.

---

*This post is part of the SaMD Under MDR series in the Subtract to Ship: MDR blog. Authored by Tibor Zechmeister and Felix Lenhard. If the complexity of your CSV program exceeds what a blog post can cover — and for anything beyond the basics it will, because every software stack is different — Zechmeister Strategic Solutions has walked 50+ companies through clause 4.1.6 and 7.5.6 audits.*

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*