CSV vs CSA: Which Validation Approach Should UK Pharma Companies Follow?

For pharmaceutical companies operating in the UK, the question of how to validate computerised systems used in GMP, GDP, and GvP environments has become more complex and more consequential in recent years. Two frameworks now sit side by side in the regulatory landscape: the traditional Computer System Validation approach that has governed pharmaceutical computerised system compliance for decades, and the newer Computer Software Assurance methodology introduced by the FDA as a modernised, risk-based alternative to traditional validation.

Understanding the difference between these two approaches, which one applies in your regulatory context, and how to build a validation programme that satisfies both UK and international regulatory expectations is now a practical necessity for UK pharmaceutical quality and IT teams. Getting this wrong does not simply mean producing more documentation than necessary. It can mean investing significant resource in validation activities that do not actually reduce risk, while leaving genuine compliance gaps unaddressed.

This guide explains what CSV and CSA each require, where they agree and where they diverge, what the MHRA and other authorities expect from UK pharma companies in 2026, and how to build a validation strategy that is both regulatory compliant and operationally sustainable.

Read More: GMP Consultant vs Full-Time Quality Manager: Which Is Better for SMEs?

The Origins of Computer System Validation

Computer System Validation has its regulatory roots in FDA guidance dating back to the 1980s and 1990s, formalised most significantly in the FDA’s 21 CFR Part 11 regulations on electronic records and electronic signatures published in 1997 and the accompanying guidance documents that followed. In the EU and UK context, CSV requirements are embedded in EU GMP Annex 11 on computerised systems, which was revised in 2011 and remains the primary regulatory framework for computerised system requirements in GMP environments in Europe and Great Britain.

The traditional CSV approach is characterised by:

• A lifecycle model that spans system selection, specification, development or configuration, testing, and retirement
• A heavily documentation-driven methodology requiring user requirements specifications, functional specifications, design specifications, validation plans, installation qualification, operational qualification, performance qualification, and validation summary reports
• A test-script based approach where anticipated system behaviours are scripted in advance and testers execute and record the results of each scripted test
• A change control framework that requires formal revalidation assessment for any change to a validated system
• Retrospective validation requirements for legacy systems that were implemented before formal validation was required

The CSV approach emerged from a regulatory environment where computerised systems in pharmaceutical manufacturing were relatively simple, where the primary concern was ensuring that custom-developed software performed as specified, and where the documentation of testing activities was seen as the primary evidence of system reliability. For systems developed specifically for pharmaceutical use, where software behaviour was directly controlled by the manufacturer, this approach was logical and effective.

The challenge that has accumulated over decades of CSV practice is that the pharmaceutical industry now uses an extraordinarily diverse range of computerised systems, the majority of which are commercial off-the-shelf software products developed by technology vendors with no specific pharmaceutical focus. Applying the full traditional CSV documentation framework to a commercial enterprise resource planning system, a cloud-based laboratory information management system, or a validated SaaS platform designed and maintained by a technology vendor introduces enormous documentation burden without proportionate risk reduction.

What Computer Software Assurance Actually Is

Computer Software Assurance is a methodology introduced by the FDA through a draft guidance document published in 2022. It represents a fundamental reframing of how pharmaceutical companies should think about and demonstrate computerised system reliability, shifting the emphasis from documentation production to critical thinking and risk-based testing.

The CSA methodology is built on several core principles that distinguish it from traditional CSV:

• Risk-based scope determination: Not all software functions used in a GMP context carry the same risk to product quality or patient safety. CSA requires organisations to assess the risk associated with each software function and to direct testing effort toward the functions that carry the highest risk, rather than applying uniform validation effort across all system functions regardless of their risk profile.
• Thinking over documentation: The FDA’s CSA guidance explicitly states that documentation is not the goal of assurance activities. The goal is confidence that the software performs as intended in the GMP context in which it is used. Documentation should capture the thinking and testing that builds this confidence, not substitute for it.
• Vendor and tool leverage: CSA encourages pharmaceutical companies to leverage the testing, quality assurance, and reliability evidence provided by software vendors rather than repeating tests that the vendor has already performed. Where a vendor can demonstrate that their development and testing processes are robust, the pharmaceutical company’s assurance activities can focus on the specific configuration and use of the system in their GMP context rather than on testing generic software functionality.
• Scripted versus unscripted testing: Traditional CSV relies almost exclusively on scripted testing where every test step is defined in advance. CSA recognises that unscripted exploratory testing, where a knowledgeable tester explores system behaviour without a predefined script, is often more effective at identifying real-world system weaknesses than executing a predetermined test script. CSA permits and encourages a mix of scripted and unscripted testing selected based on the nature of the system and the risk profile of its functions.
• Continuous assurance: Rather than treating validation as a point-in-time event that produces a validated status, CSA frames assurance as a continuous activity that evolves throughout the system lifecycle, with the level of assurance activity proportionate to changes in the system and its GMP context.

How CSV and CSA Differ in Practice

Understanding the theoretical distinction between CSV and CSA is useful but understanding how the two approaches differ in everyday validation practice is more directly relevant to pharmaceutical QA and IT teams making decisions about their validation programmes.

The most significant practical differences include:

• Documentation volume: Traditional CSV typically generates substantially more documentation per system than a CSA approach applied to the same system. The difference is most pronounced for commercial off-the-shelf systems where traditional CSV requires full URS, FS, DS, IQ, OQ, and PQ documentation regardless of the system’s risk profile, while CSA permits a streamlined documentation approach focused on risk-assessed functions.
• Testing approach: Traditional CSV requires pre-scripted test protocols executed by testers who follow the script precisely and record pass or fail against each step. CSA permits unscripted exploratory testing for lower-risk functions and focuses scripted testing on the highest-risk GMP-critical functions. This does not mean less testing overall but it means more intelligent testing directed at the areas where failures would have the most significant consequences.
• Vendor audit and assessment: CSA places greater emphasis on assessing and leveraging the vendor’s own quality and development processes. A pharmaceutical company applying CSA principles to a tier one laboratory informatics platform from a reputable vendor can draw on the vendor’s development quality assurance, regulatory compliance certifications, and track record of regulatory inspection outcomes to reduce the amount of independent testing required. Traditional CSV does not prevent this but its documentation requirements often drive organisations toward repeating vendor testing regardless of vendor quality.
• Treatment of agile and cloud systems: Traditional CSV was designed for systems with defined requirements specified before development begins, which maps well to bespoke pharmaceutical software development but maps poorly to modern SaaS platforms updated by vendors on continuous delivery cycles. CSA provides a more workable framework for managing assurance of cloud-based systems where the software is updated by the vendor independently of the pharmaceutical company’s validation cycle.
• Resource allocation: Traditional CSV often results in validation resource being consumed disproportionately by documentation production for lower-risk systems, leaving less resource for thorough testing and critical thinking about higher-risk systems. CSA’s explicit goal is to redirect this resource toward risk-proportionate activities that deliver genuine quality assurance rather than regulatory documentation compliance.

What the MHRA Expects From UK Pharma Companies in 2026

For UK pharmaceutical companies, the primary regulatory framework for computerised system requirements remains EU GMP Annex 11, which the MHRA retained as part of its post-Brexit regulatory framework. The MHRA has not published a separate UK-specific equivalent of the FDA’s CSA draft guidance, and the expectation of UK regulatory inspectors is that computerised systems used in GMP, GDP, and GvP environments are validated in a manner consistent with Annex 11 requirements.

This does not mean that UK pharmaceutical companies must rigidly follow traditional CSV methodology for every system. EU GMP Annex 11 is itself a risk-based framework that requires:

• A risk assessment to determine the scope and extent of validation activities for each system
• Validation documentation proportionate to the risk and complexity of the system
• Supplier assessment as part of the validation process for commercial software
• Change control procedures for validated systems
• Data integrity controls consistent with the ALCOA++ principles discussed elsewhere in this blog series

What MHRA inspectors examine is not whether a company has followed a specific named methodology but whether the computerised systems used in their GMP environment are demonstrably fit for purpose, whether their behaviour is understood and documented, whether changes are controlled, and whether the data integrity of GMP records held in those systems is maintained. A company that can demonstrate all of these things using a CSA-informed risk-based approach is unlikely to face regulatory challenge on the grounds that it did not produce a full traditional CSV documentation set, provided the risk assessment justifying the reduced documentation scope is credible and well-documented.

The practical position for UK pharma companies in 2026 is therefore:

• The mandatory framework is EU GMP Annex 11 as retained in UK law post-Brexit
• The MHRA expects risk-based validation proportionate to the GMP impact and complexity of each system
• The FDA’s CSA methodology is not a UK regulatory requirement but its risk-based principles are consistent with Annex 11 and can inform a more intelligent and efficient validation programme
• UK companies that also supply the US market must satisfy FDA expectations, making familiarity with CSA principles practically necessary regardless of their primary regulatory framework
• The MHRA’s own data integrity guidance and Annex 11 together set expectations for audit trail completeness, access control, and electronic record integrity that any validation approach must address

Which Approach Is Right for Your Organisation

The answer to whether a UK pharma company should follow CSV or CSA is not a binary choice. The most effective computerised system assurance programmes in 2026 draw on the strengths of both approaches, applying traditional CSV rigour where the risk profile justifies it and CSA-informed efficiency where it does not.

A practical framework for making this determination for individual systems involves working through the following considerations:

System risk classification should drive the approach. Systems that directly control or record GMP-critical data, where a failure would have direct consequences for product quality or patient safety, warrant a more thorough and documented validation approach regardless of whether that approach is labelled CSV or CSA. Systems with indirect or low GMP impact can be managed with a lighter-touch assurance programme that still demonstrates fitness for purpose without generating the full traditional CSV documentation set.

The categories of systems that typically warrant the most thorough validation approach include:

• Manufacturing execution systems that control or record production parameters for critical processes
• Laboratory information management systems used for release testing and stability data management
• Pharmacovigilance safety databases used for ICSR management and signal detection
• Chromatography data systems where raw analytical data integrity is directly dependent on system behaviour
• Environmental monitoring systems for controlled and sterile manufacturing environments
• Electronic batch record systems where the integrity of GMP records is maintained entirely within the electronic system

The categories of systems that typically support a more risk-proportionate, CSA-informed approach include:

• Commercial enterprise resource planning systems used for inventory and supply chain management with indirect GMP relevance
• Document management systems for SOP and controlled document storage where the primary GMP obligation is access control and version management
• Training management systems where the GMP obligation is evidence of training completion rather than direct product quality impact
• Communication and collaboration platforms used to support GMP activities without directly controlling or recording GMP data
• Validated SaaS platforms from vendors with established pharmaceutical regulatory credentials and a track record of regulatory inspection outcomes

Vendor quality should influence the assurance approach. A commercial laboratory informatics platform from a vendor whose development processes are certified to ISO 9001, who has published IQ and OQ documentation, whose platform has been referenced in regulatory submissions without adverse comment, and who provides detailed audit trail and access control functionality as core platform features supports a more leveraged assurance approach than a custom-built system or a generic commercial software product repurposed for a GMP application.

The regulatory market portfolio should inform the framework choice. A UK company that also supplies the US market and is therefore subject to FDA inspection should build its validation programme around CSA principles from the outset, since FDA inspectors are increasingly applying CSA-consistent expectations in their inspection of computerised systems. A UK company whose regulatory exposure is exclusively MHRA and EMA has more flexibility to design its programme around Annex 11 requirements without specifically adopting the CSA framework, though the risk-based principles are compatible and complementary.

Building a Validation Programme That Works for Both Frameworks

For UK pharmaceutical companies who want a validation programme that satisfies MHRA expectations, is consistent with FDA CSA principles for those supplying the US market, and delivers genuine quality assurance rather than documentation production, the following structural elements are essential:

A computerised system inventory and risk classification process that systematically identifies all GMP-relevant systems in use at the site and assigns a risk tier to each based on their GMP function, the nature of the data they hold, and the consequences of system failure. This inventory is the foundation of the entire validation programme and without it, validation activities cannot be allocated proportionately.

A validation strategy document or computerised system assurance policy that defines the organisation’s approach to validation for each risk tier, specifies the documentation requirements for each tier, defines how vendor assessment will be conducted and leveraged, and establishes the change control requirements applicable to validated systems. This document should explicitly reference both EU GMP Annex 11 and, where relevant, FDA CSA principles.

A supplier assessment programme that evaluates the quality management systems and development practices of software vendors whose products are used in GMP-relevant applications. Supplier assessment evidence should be retained and referenced in the validation documentation for each relevant system.

A testing approach for each system that is proportionate to its risk classification, uses a mix of scripted and unscripted testing where the CSA framework is being applied, and focuses testing effort on the GMP-critical functions of the system rather than on generic software functionality that the vendor has already validated through their own quality processes.

A change control framework that requires a documented impact assessment for any change to a validated system, determines the revalidation or reassurance activities required based on the nature and risk of the change, and maintains the validated status of the system through a defined change management process.

A periodic review programme that reassesses the validated status of all GMP-relevant systems at defined intervals, confirms that the validation documentation remains current and accurately reflects the system as deployed, and identifies any changes that have occurred without going through the change control process.

Common Validation Programme Failures That Regulators Find

Across FDA warning letters, MHRA inspection reports, and EMA inspection findings relating to computerised systems, certain patterns of validation failure appear consistently regardless of whether the site follows a CSV or CSA framework. Understanding these failure modes helps quality teams prioritise their validation programme improvements:

• Computerised systems used in GMP-relevant activities that have never been formally validated or had a validation assessment conducted
• Validation documentation that describes the system as it was at the time of initial validation but does not reflect subsequent configuration changes or software updates
• Change control records that acknowledge system changes without documenting the impact assessment on validated status or the revalidation activities performed
• Audit trails that are technically present in the system but are not routinely reviewed as part of the quality oversight programme
• User access rights that have accumulated over time without periodic review and now grant individuals access to functions beyond those required for their role
• Validation packages for commercial off-the-shelf systems that consist entirely of vendor documentation without site-specific testing of the system’s configuration and GMP-relevant functions
• Computerised systems used as the primary record for GMP data where no backup, disaster recovery, or business continuity procedure has been validated

How Quality and Vigilance Supports Computerised System Validation and Assurance

At Quality and Vigilance we support pharmaceutical manufacturers, MAHs, contract laboratories, and medical device companies with computerised system validation and assurance programmes across EU GMP Annex 11, FDA 21 CFR Part 11, and FDA CSA frameworks. Our team brings practical experience of computerised system inspection findings across MHRA, FDA, EMA, and TGA inspections and understands how to build validation programmes that satisfy regulatory expectations without generating documentation burden that consumes resource without delivering compliance value.

Our computerised system services include:

• Computerised system inventory development and risk classification
• Validation strategy and CSA policy development
• Supplier and vendor assessment for GMP-relevant software platforms
• Validation documentation review and gap assessment against current regulatory expectations
• Audit trail review and data integrity assessment for GMP computerised systems
• Change control framework development for validated systems
• Mock inspection support with specific focus on computerised system and data integrity readiness
• Remediation support for organisations that have received computerised system findings during regulatory inspections

Contact Quality and Vigilance today to assess your computerised system validation programme and build a validation strategy that satisfies both MHRA and global regulatory expectations in 2026 and beyond.