Validation needs to match the risk
Computer system validation, or CSV, is the documented process used to show that a GxP system is fit for its intended use. Both problems often start in the same place: not matching the validation effort to the actual risk.
The lifecycle
Validation follows the system through its life.
Planning
Defines the scope, the approach, and the acceptance criteria in a validation plan.
Specification
Captures what the system must do, in a user requirements specification, and how it does it, in functional and design specifications.
Verification
Tests the system against those specifications — installed correctly, functioning as specified, performing in the real process.
Reporting and operation
Summarizes the evidence in a validation summary report. The system then enters operation under change control, with periodic review to confirm it remains validated.
The V model is the traditional way of illustrating this: specifications on the left, tests on the right, each level of test verifying the matching level of specification. Verification traditionally runs as installation qualification, operational qualification, and performance qualification.
Risk based validation
GAMP 5 categorizes software by how much of it is custom. Infrastructure and off the shelf software used as supplied needs less. Configured products need validation of the configuration. Custom developed software needs the most. Within any system, a risk assessment identifies which functions affect patient safety, product quality, or data integrity and directs the validation depth there.
The goal is not to do less validation. It is to have a clear reason for the level of validation chosen.
Computer Software Assurance
FDA's guidance moves the emphasis from documentation to critical thinking. It encourages using vendor testing, unscripted testing, and automated assurance where appropriate, and reserving formal scripted testing for high risk functions.
It can reduce validation effort without weakening control, but only if the underlying risk assessment is sound.
Common problems
Validating everything equally, which burns effort on low risk functions and starves high risk ones.
Validating once and never again, which leaves the system out of compliance after its first change.
Validation documents that do not match the system as built, usually because the documents were written to a plan that the implementation departed from.
Traceability gaps, where a requirement cannot be followed to the evidence it was met.
SequoiaAT supports computer system validation in life sciences as part of its regulatory and validation practice, with test automation providing the verification evidence.
Regulated documents moved from AODocs to Veeva Vault for a biotech running clinical studies, with a trial migration first, every file hash checked and zero data loss.
Read the case study →