Computer System Validation: What CSA Changed

Computer system validation (CSV) is documented evidence that a computerised system does what you rely on it to do, consistently, throughout its life.

It applies to any system whose failure could affect product quality, patient safety or record integrity: LIMS, MES, ERP where it holds batch data, chromatography data systems, electronic batch records, and the spreadsheet somebody built to calculate a release limit.

The scope question comes first

Validation effort belongs where failure matters. Two questions decide it:

Is the system GxP relevant? Does it create, modify, store or transmit a record you rely on for a regulatory decision?

What is the intended use? Not what the software can do, what you use it for. A system with fifty features and three you rely on is validated against those three.

Getting scope wrong in either direction is expensive. Too wide and you validate functions nobody uses. Too narrow and an unvalidated function turns out to sit under a batch release.

The traditional lifecycle

• User requirements (URS): what you need it to do.
• Functional and design specifications: how it will do that.
• IQ, OQ, PQ: installed correctly, operating as specified, performing in your process with your people.
• Traceability matrix: every requirement mapped to the test that proves it.
• Change control and periodic review thereafter.

Validation is not a one-off. A validated system that has been patched, upgraded and reconfigured for four years without change control is not validated.

What CSA changed

FDA's Computer Software Assurance (CSA) guidance is a deliberate correction. The observation behind it: the industry was producing enormous validation documentation and getting less assurance for it, because effort went into screenshots and signatures rather than into thinking about what could fail.

CSA asks for a risk-based approach:

• Establish intended use and whether the feature affects patient safety or product quality directly.
• For high-risk features, scripted testing with recorded evidence.
• For lower-risk features, unscripted or exploratory testing, ad hoc testing, and reliance on the vendor's own testing where justified.
• Record what happened, not a screenshot of every click.

This is not permission to validate less. It is direction to spend the same effort where the risk is, which for most systems means less documentation on routine functions and more analysis of the few that matter.

Data integrity is the point

A validated system that does not enforce ALCOA has not achieved anything. Validation should demonstrate that audit trails are enabled and cannot be turned off by the people generating data, that access rights match role, that the clock cannot be altered without a record, and that records can be retrieved for their retention period. 21 CFR Part 11 sets those requirements; validation is how you show they hold.