SOP: Validation of Computer Software Used in the QMS

Template — QMS Nordic T1. Adopt this as your own SOP. It is written to be usable as-is: replace the bracketed fields, delete this box, and put it through your document control.

This SOP is about your whole toolset, not just QMS Nordic. §4.1.6 covers every piece of software that touches your quality system — your eQMS, a spreadsheet that calculates a specification limit, a training tracker, a label printer's driver. Auditors ask for the procedure first and the individual validations second. Most non-conformities under this clause are "no documented procedure", not "insufficient testing".

Effort: replace the fields, agree the risk categories, approve. Once.

---

1. Purpose

To define how [COMPANY] validates the application of computer software used in its quality management system, before initial use and after changes, in a manner proportionate to the risk associated with its use, and how records of that validation are maintained.

2. Scope

All software that supports a QMS process, records QMS data, or whose failure could affect the safety or performance of a device. This includes software we buy, software we configure, and spreadsheets or scripts we build ourselves.

It excludes software embedded in our devices (validated under design controls) and general office software not used to create or control quality records.

Judgement call — decide and record it. A spreadsheet that calculates a release criterion IS in scope. The same spreadsheet used to plan a meeting is not. When unclear, include it: the cost of validating something unnecessarily is small; the cost of an auditor finding an uncontrolled tool holding quality data is not.

3. References

4. Responsibilities

5. Procedure

5.1 Identify and register

Every tool in scope is entered in the Software Register (§8) with its intended use, process owner, supplier and risk category.

5.2 Categorise by risk

Risk is the product of what the software does and what happens if it does it wrong. Categorise before deciding effort — the category determines the depth, which is what "proportionate to risk" means in practice.

Worked examples. An eQMS holding controlled documents and electronic signatures is High. An audit-scheduling tool whose failure means a missed reminder someone would notice is Medium. A meeting-room booking system is out of scope entirely.

5.3 Define intended use

State what we use the tool for, in our processes — not what the vendor says it does. This is the single most-cited gap in audits of this clause: a vendor's description of their product is not a statement of our intended use.

Where a supplier provides a proposed intended-use statement, we may adopt it, but we review it against our actual configuration and processes and record any difference. Anything we rely on that the supplier's statement does not cover becomes our own validation deliverable.

5.4 Leverage supplier evidence

Where a supplier provides validation evidence, we assess and use it. It reduces our testing; it does not replace our validation. We record what we relied on and why we considered it adequate — supplier quality system, evidence of controlled development, testing evidence per release.

Supplier evidence is never sufficient on its own. It cannot demonstrate that the tool, as we configured and use it, meets our intended use.

5.5 Test

Testing is scaled to the risk category and concentrates on the functions we actually rely on. Each test records: what was done, the expected result, the observed result, pass or fail, who performed it, and when.

Failures are recorded, not quietly re-run. A failed test with a documented resolution is evidence of a working process; an absent failure record in a system that clearly had problems is evidence of the opposite.

5.6 Report and release

A validation report summarises intended use, risk category, supplier evidence relied upon, testing performed, deviations, and a conclusion that the software is fit for its intended use. It is approved by [Quality Manager] before the tool is used for live quality records.

5.7 Revalidate on change

Changes that trigger review: supplier releases affecting a function we rely on; a change to our configuration, process or intended use; a defect affecting record integrity.

We assess every supplier release note. Most require no action, and recording "assessed, no impact" is itself the evidence that we are watching. Where impact exists, we test the affected functions and re-approve.

Revalidation is also triggered by [annual] periodic review, whichever comes first.

5.8 Retire

On decommissioning, records held in the tool are exported or migrated so they remain legible and retrievable for their retention period, and the retirement is recorded in the register.

5.9 Part 11 obligations that are not about the software

(US market, electronic signatures. Skip if neither applies.)

Validating the software satisfies part of 21 CFR Part 11 and not the rest. These four are organisational obligations — no vendor can discharge them, and no amount of supplier evidence covers them. They are listed here because the first is a recurring inspection finding and is easy to miss when the validation work looks finished.

§11.100(c) is not a software control and is not evidenced by testing. It is a letter. Inspectors ask for it, and a validation file that is otherwise complete does not substitute. If you rely on electronic signature in the US market and have not sent one, that is the action this row exists to surface.

6. Records

7. Definitions

Validation — documented evidence that software consistently fulfils its intended use in our processes. Intended use — what we use the tool for, as we have configured it. Supplier evidence — validation material provided by a vendor; an input to our validation, not a substitute for it.

8. Software Register

---