Computerised System Validation (CSV): A Risk-Based Approach, from CSV to CSA

In regulated industries — pharmaceuticals, biotechnology, medical devices — computerised systems now control manufacturing, capture quality data and release product. When a system fails or its data cannot be trusted, the consequences reach all the way to patient safety. Computerised System Validation (CSV) is the discipline that provides documented assurance that these systems consistently do what they are intended to do. But CSV has evolved. For years it drifted toward "validation by documentation" — thick binders of scripted tests that satisfied auditors but added little real assurance. Regulators noticed. Today, best practice is a risk-based, critical-thinking approach that focuses effort where it genuinely reduces risk. This article explains that modern approach as we apply it in practice. THE REGULATORY LANDSCAPE Three references anchor CSV today: - FDA 21 CFR Part 11 — governs electronic records and electronic signatures in the US. - EU GMP Annex 11 — the European expectation for computerised systems. - GAMP 5 (Second Edition, 2022) — ISPE's "A Risk-Based Approach to Compliant GxP Computerized Systems," the practical industry standard. Most recently, the FDA's draft guidance on Computer Software Assurance (CSA) has reframed the conversation — shifting the emphasis from producing documentation to actually assuring the software is fit for its intended use. Understanding this shift is now part of doing CSV well. WHY RISK-BASED IS THE STANDARD Not every system, and not every function within a system, carries the same risk. A system that dictates a sterilisation cycle demands far more scrutiny than one that stores non-critical reference documents. A risk-based approach directs validation effort in proportion to the impact on product quality, patient safety and data integrity — the core principle of GAMP 5. The practical starting question is always: does this system have GxP impact? If not, little or no validation is required. If it does, the depth of validation should scale with the risk. CLASSIFY THE SOFTWARE — GAMP 5 CATEGORIES GAMP 5 groups software to guide the appropriate level of effort: - Category 1 — Infrastructure (operating systems, databases): handled through infrastructure qualification. - Category 3 — Non-configured products used "out of the box": lighter validation. - Category 4 — Configured products tailored to your process: focus validation on the configuration. - Category 5 — Custom / bespoke applications: highest risk, deepest validation and testing. The higher the category, the greater the chance of error unique to your use — and the more rigorous the assurance required. ASSESS AND PRIORITISE RISK For each critical function, assess: - Severity — how serious is the impact if it fails? - Probability — how likely is that failure? - Detectability — would the failure be caught before it causes harm? High-severity, likely, hard-to-detect functions receive the most attention, the strongest controls and the deepest testing. Low-risk functions do not need the same treatment — and forcing them to only wastes resources. VALIDATE ACROSS THE LIFECYCLE Risk-based CSV follows a lifecycle, often shown as the V-model: - User Requirement Specification (URS) — what the system must do. Get this right; weak requirements undermine everything downstream. - Functional and Design Specifications — how it will do it. - Installation Qualification (IQ) — installed correctly. - Operational Qualification (OQ) — operates within defined limits. - Performance Qualification (PQ) — performs consistently under real conditions. A Requirement Traceability Matrix links every requirement to its test, giving auditors — and you — confidence that nothing critical was missed. THE SHIFT TO COMPUTER SOFTWARE ASSURANCE (CSA) CSA is the evolution of CSV, and understanding it separates modern practice from legacy habits. Its message is simple: assurance, not paperwork. In practice, CSA encourages you to: - Start from intended use and patient/product risk, not from a testing template. - Apply the least-burdensome testing that provides adequate assurance — reserving heavily scripted testing for the highest-risk functions. - Use unscripted and exploratory testing for lower-risk features, which often finds real issues that rigid scripts miss. - Leverage supplier and vendor testing rather than re-testing what has already been proven. - Keep records proportionate — enough to demonstrate assurance, not documentation for its own sake. Done well, CSA reduces effort and cost while actually improving confidence in the system. NEVER OVERLOOK DATA INTEGRITY Modern CSV lives and dies on data integrity, guided by the ALCOA+ principles: data must be Attributable, Legible, Contemporaneous, Original and Accurate — and also Complete, Consistent, Enduring and Available. Electronic records and signatures must meet 21 CFR Part 11 and Annex 11. Audit trails, access controls and secure, tamper-evident records are not optional extras; they are the foundation of trust. COMMON PITFALLS WE SEE From the field, the mistakes that repeatedly cause audit findings are: - Treating every system and function as equally critical. - Validating without a clear understanding of the system's intended use. - Vague or incomplete user requirements. - No traceability between requirements and testing. - Weak data-integrity controls and audit trails. - "Validate once and forget" — no change control, no periodic review. A system stays validated only if changes are controlled and its validated state is maintained. A PRACTICAL ROADMAP 1. Define intended use and confirm GxP impact. 2. Classify the software (GAMP category