Computer system validation (CSV) for small labs

Part 11 asks for validation in one line. It is the first of the controls a closed-system user must have:

The sentence names four things the evidence has to show. Read each as a test you can run on your own system, not as a property the vendor can promise for you:

Part 11 never defines validation. FDA's software validation guidance (2002) does: “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.” Two phrases carry the weight: “objective evidence” (records an inspector can read) and “intended uses” (yours, not the product's full feature list). EU GMP Annex 11 puts it in one sentence: “The application should be validated; IT infrastructure should be qualified.”

Whether § 11.10(a) reaches a given system at all depends on its records. The Part 11 applicability checker answers that in three questions, and the Part 11 requirements, section by section sets (a) beside the other controls a validation has to cover.

The same guidance gives the low end of the scale: “validation would not be important for a word processor used only to generate SOPs.” Risk decides how much evidence a system needs; it never decides that a GxP records system needs none.

A ten-person lab does not write its LIMS, ELN or eQMS. It buys a product, configures it and, more and more often, rents it as a service. That changes who does which part of the work, but not who signs for the result. The vendor tests its product; you validate your use of it.

Assess the supplier, then lean on its work

Annex 11 asks for this directly. “The supplier should be assessed appropriately” (§ 4.5), “The need for an audit should be based on a risk assessment” (§ 3.2), and documentation supplied with off-the-shelf products “should be reviewed by regulated users to check that user requirements are fulfilled” (§ 3.3). Where a third party hosts, configures or maintains the system, “formal agreements must exist” that state its responsibilities (§ 3.1).

FDA's computer software assurance guidance, written for device makers, lists what such an assessment can draw on, and accepts that an onsite audit may not be feasible. It works as a checklist for any small lab:

• an onsite audit of the vendor, where one is feasible;
• the vendor's accreditations and certifications, such as Service Organization Controls (SOC) reports and ISO certifications;
• its practices and documents for software development, quality assurance and cybersecurity;
• its data integrity controls: retaining records and producing accurate, complete copies; audit trails; access, signature and authorization checks.

The same guidance says a manufacturer can take the developer's own testing and validation work “as the starting point and determine what additional activities may be needed”, and that for some lower-risk functions “this may be all the assurance that is needed”. That is the saving for a small lab: a good supplier file shrinks your own test set. A poor one, or a vendor who will not share, grows it.

What SaaS adds

With software as a service you do not control the servers, the database or the release date. Three things move into your validation: the agreement (who backs up, who restores, how long your records stay retrievable, how you get them back if you leave), a tested export and restore of your own records, and a release procedure that reads each set of release notes against your validated functions. The guide to Part 11 for cloud and SaaS systems covers the questions to put to the vendor, and the comparison of paperless validation software covers tools that run the test execution itself.

Size comes from two questions asked function by function: what do we use this for, and what happens to a result, a batch or a patient if it is wrong? A function that only stores a reading someone checks later needs little of your own testing. A function that calculates a reportable result, decides pass or fail, or applies a signature needs scripted evidence.

FDA's computer software assurance guidance gives the clearest example. Spreadsheet software used only for “documenting readings” of a curing process poses a low process risk, and vendor assessment plus installation and configuration “may be sufficient”. Add a custom formula that calculates time and temperature statistics used to monitor the process, and “additional validation by the manufacturer might be necessary.” Same product, two intended uses, two answers. Spreadsheets are a case of their own; see Excel spreadsheets under Part 11.

The CSA validation scope planner walks that decision for each feature and writes down the assurance activity and the record to keep, which is the risk assessment Annex 11 § 1 asks to be “justified and documented”.

GAMP 5: industry guidance, not law

Most validation teams speak GAMP. GAMP 5 is a guide from ISPE, an industry body; the current edition is GAMP 5 Second Edition, published in 2022-07. No regulation requires it, though FDA's CSA guidance names it as a resource on testing methods and validation approaches. GAMP sorts software into categories by how much of it is configured or custom-built. The second edition names them as below; the examples and the third column are ours.

ISPE's own 2026 article warns that categorization “is not a validation checklist”: a category tells you how the software was built, and you still need the risk of each function and an assessment of the supplier. What GAMP 5 is covers the categories and the lifecycle in more depth.

Where CSA fits

FDA's guidance “Computer Software Assurance for Production and Quality System Software” became final on 2025-09-24, three years after the 2022-09-13 draft. FDA reissued it on 2026-02-03 as “Computer Software Assurance for Production and Quality Management System Software”, which is the current version. It comes from CDRH and CBER and covers software used in production or the quality management system of medical device makers. It supplements FDA's 2002 software validation guidance and supersedes only that guidance's Section 6. It does not remove Part 11.

Annex 11 § 4.1 asks that validation documents “cover the relevant steps of the life cycle” and that you can justify your standards, protocols and acceptance criteria “based on their risk assessment”. For a bought, configured system at a small lab, the relevant steps are these.

A contract lab of ten people (four analysts, a reviewer, a QA lead, the rest admin and sales) replaces paper worksheets and a shared spreadsheet with a cloud LIMS. Its results support customers' drug CGMP batch release, so the records are required by a predicate rule and Part 11 applies. The QA lead owns the validation; the vendor supplies a validation summary, its SOC report and a release calendar.

The URS runs to 40 numbered requirements. The risk assessment rates 15 of them high, because they decide or sign a reportable result. Those get scripted tests; the rest get unscripted tests, a configuration record or reliance on the vendor's file. An excerpt of the resulting traceability matrix:

Read the matrix from right to left and it tells an inspector the story of the validation in one sheet: every high-risk requirement has a scripted test with its own ID, the low-risk ones say why they needed less, and the one requirement the lab cannot test alone (the restore) is tested with the vendor's help on a copy. Build yours in the traceability matrix template, and size the risk column first with the validation scope planner.

Validation describes the system on the day of the report. Everything after that is about keeping the description true. Annex 11 § 10: “Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.” Part 11 adds that the system's own documentation needs revision and change control with an audit trail (§ 11.10(k)(2)).

What sends you back to testing

• a new release or patch that touches a validated function (read every set of release notes, not only the major ones);
• a configuration change: a new role, a workflow step, a calculation, a report template;
• a new intended use, such as a new test method or a new customer whose records the system will now hold;
• an interface added or changed, or data migrated in from another system;
• a deviation or incident that shows the system did not do what the URS says.

Each change gets an impact assessment that names the requirements it touches, then retests only those, recorded in the traceability matrix against the new release. With SaaS the vendor sets the calendar, so the release-notes review is a standing task with an owner, not a project. Change control software for regulated teams compares tools that carry the impact assessment and the signed approval in one record.

Periodic review

Annex 11 § 11 asks that systems be “periodically evaluated to confirm that they remain in a valid state and are compliant with GMP”, looking where appropriate at “the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports.” Neither Annex 11 nor Part 11 sets an interval; your plan does, by risk, and the review report records what was read and what was found. User access is a good thing to add: a list of active accounts checked against the staff list catches the leaver who still has approval rights.

Day-to-day audit trail review, which Annex 11 § 9 says should be done “regularly”, is a separate task; the periodic review checks that the trail is still switched on and complete. The guide to audit trails covers both.

Retirement

A system leaves service before its records do. § 11.10(c) asks for “accurate and ready retrieval throughout the records retention period”, and the retention period comes from the predicate rule, not from Part 11. Before switching off, or ending a SaaS contract, export the records with their audit trails and signatures, check the export against the originals, and write down where they now live.

Regulation text quoted from the eCFR and EudraLex; guidance quoted from FDA and ISPE. General information, not regulatory advice.

1. 21 CFR Part 11, Electronic Records; Electronic Signatures, eCFRread 2026-10-22
2. Part 11, Electronic Records; Electronic Signatures: Scope and Application (2003), FDAread 2026-10-22
3. General Principles of Software Validation (2002), FDAread 2026-10-22
4. Computer Software Assurance for Production and Quality Management System Software (2026-02-03), FDAread 2026-10-22
5. CSA final guidance notice of availability, 90 FR 45945 (2025-09-24), Federal Registerread 2026-10-22
6. CSA draft guidance notice of availability, 87 FR 56059 (2022-09-13), Federal Registerread 2026-10-22
7. EudraLex Volume 4, Annex 11: Computerised Systems (2011), European Commissionread 2026-10-22
8. 21 CFR Part 211, CGMP for Finished Pharmaceuticals, eCFRread 2026-10-22
9. 21 CFR Part 58, Good Laboratory Practice for Nonclinical Laboratory Studies, eCFRread 2026-10-22
10. 21 CFR Part 820, Quality Management System Regulation, eCFRread 2026-10-22
11. GAMP 5 Guide, 2nd Edition, ISPEread 2026-10-22
12. When Is a Category Not a Category? (Pharmaceutical Engineering, Jan/Feb 2026), ISPEread 2026-10-22