Validation of Computerized Systems.
Any computerized system that supports a GxP-relevant process must be validated. That obligation follows from the GxP assessment of the process and applies to every system used in that process. EU GMP Annex 11 states this obligation explicitly. 21 CFR Part 11 presupposes a validated system so that electronic records and signatures can be trusted. What is validated is not the software, but its application in the process. The measure is the intended use. We deliver that evidence from the operator's perspective, driven by the risks to patient safety, product quality and data integrity, with a test strategy based on Computer Software Assurance (CSA). In everyday usage it is also called computer validation or CSV validation.
What exactly is validated?
What is validated is the computerized system as a whole, against the intended use. It comprises the technology, the process in which it is used and the people within that process. The process is the starting point. It defines the system's purpose, and requirements, risks and the scope of evidence follow from that purpose. Each layer of the system is demonstrated in its own way:
| Layer | How the evidence is established |
|---|---|
| Hardware and infrastructure | are qualified. Once demonstrated, the qualified state holds under controlled conditions |
| Software layers, configuration, models | are verified continuously against the specification |
| The whole system in its process | is validated against the intended use. The result is the validated state |
The market speaks in shorthand such as "validating the software" or "qualifying the tools." Anyone who understands how the pieces fit together tacitly translates such shorthand into the correct form of evidence. What matters is not the label on a piece of evidence but its clearly named object: what exactly is being demonstrated, and what claim does that evidence support? Computer Software Assurance follows the same logic.
From process to validated state.
Validation follows a documented lifecycle. Each specification step defines what will later have to be demonstrated. The methodological foundation comes from GAMP 5 validation. Release completes implementation, not the lifecycle. The validated state holds for the demonstrated configuration and is maintained in operation. The draft revision of Annex 11 provides for a review program of its own for this operational phase.
- 1
Process understanding & intended use
Everything starts with the process: what is the system meant to do in the business process? The intended use is the measure for every step that follows.
- 2
Validation planning
The review of the existing QMS comes first. Building on it, the validation plan sets out scope, roles, responsibilities and acceptance criteria and defines the risk-based approach that the later steps follow.
- 3
Requirements & risk assessment
In the requirements analysis, the intended use is translated into system requirements. In the risk assessment, systems and functions are weighted by the risks they pose to patient safety, product quality and data integrity.
- 4
Test strategy & specification
The risk-based test strategy following CSA defines which evidence is delivered at what depth: the types of testing, the test depth and the extent of documentation for each function.
- 5
Testing, report & release
The relevant functions are tested against approved test cases. Execution, result and deviations are documented for each test so that coverage of the requirements remains traceable. The validation report and the release for GxP operation conclude the step.
- 6
Operation: maintaining the state
Under change control, every change is checked for whether it affects the validated state. Where necessary, a re-examination is triggered. Continuous monitoring and periodic reviews bring previously unnoticed changes to light. With incident management, security, support and training, the operator keeps the validated state intact through operation.
The foundation under the application follows its own path of evidence: the application is validated, the IT infrastructure beneath it is qualified. How the controlled state of that infrastructure is established is covered by IT Infrastructure Qualification, from your own data center to the cloud. Where systems sit directly in manufacturing, process and system evidence interlock. What that interplay looks like is the subject of Qualification and Validation of Production Systems.
From paper protocol to structured record.
The steps of the lifecycle are increasingly carried out digitally rather than on paper. Our page on digital transformation in the GxP environment covers this shift in more depth.
How CSA changes testing.
Software verification and the validation of the computerized system are two different forms of evidence. The software is part of the system. Its evidence is called verification, even if it is often misleadingly referred to as software validation. Computer Software Assurance addresses exactly this evidence, the risk-based verification of application software in production and in the quality management system. The final FDA guidance appeared in September 2025. The version revised in February 2026 is the one that applies.
CSA does not establish a new discipline. The guidance follows the risk-based thinking of ICH Q9 and describes, at its core, good testing applied consistently. The difference is not between two methods, but between cumbersome and effective testing, from the trigger through the depth of testing into operation:
| Dimension | Cumbersome testing | Risk-based testing (CSA) |
|---|---|---|
| Testing trigger | everything gets tested, by reflex toward the regulations and out of uncertainty ahead of the audit | testing follows the intended use and the actual risk |
| Test depth | every function tested to the same depth | test depth scales with the risk of each function |
| Evidence | extensive documentation for its own sake | effective testing, with documentation pared back to what is needed |
| Changes in operation | blanket retesting after every change | re-examination assessed by risk, the demonstrated state deliberately maintained |
| Effort vs. assurance | high effort, often with little to show for it | effort spent where it protects patient safety and product quality |
The guidance explicitly excludes infrastructure software not specific to production or the QMS, such as software for networking, user authentication or backup and restore. That software belongs to the IT infrastructure, which is qualified under Annex 11. And the validation of the whole system in its process remains the operator's task: software verification is one building block within it.
Validation, supported end to end.
Across the entire lifecycle, we support operators with the services that establish the validated state and preserve it in operation. What that looks like in practice is shown by the Drug Safety Implementation case study: a risk-based validation under GAMP 5 for an international CRO. Internal QA found no deficiencies.
Through every shift in system validation since 2004, from Part 11 to AI.
Each shift raised the same question all over again: Can electronic data and systems be trusted, and how do you demonstrate it?
Part 11 asked about records, ICH Q9 about risk, the data integrity wave about the behavior of the people working with the system, the cloud about control over third-party infrastructure. AI asks about the controllability of non-determinism.
We were presenting on cloud computing in 2011, while the market was still debating whether it was permissible. We were running agile validation projects in GxP as early as 2013, years before the approach was formalized.
The GCP story goes back furthest: in the clinical world the data are the product, and in 2008 there was no dedicated European guideline for the systems that generate them, only ICH E6 and scattered inspection requirements. That gap was our cue: we initiated the GAMP working group for GCP systems (work began in 2009; later absorbed into the ISPE GAMP R&D and Clinical Systems SIG). In 2014 we trained Europe's GCP inspectors at the EMA GCP Inspectors Working Group workshop. Here the audience was not the market but the inspectors themselves.
And when the industry caught up, we contributed to the answers: on the Core Team of the GAMP 5 2nd Edition and on the Good Practice Guide "Enabling Innovation." Critical Thinking, which GAMP 5 puts front and center, is the signature of our test strategies.
Frequently asked questions about computerized system validation.
No. Validation applies to systems used in GxP-relevant processes. The causal chain decides: does the system influence data, product and therefore the patient, even indirectly? Where it does, the scope and depth of evidence follow the risk. Where it does not, the company's good IT practices are sufficient.
Yes. Computer validation, CSV validation and validation of computerized systems all describe the same evidence. CSV stands for Computerized System Validation. What is examined is the application of the software in its GxP process, measured against the intended use.
Validation is the operator's job. Only the operator knows the process and its intended use. The software provider does not validate. It assures the quality of its product against defined standards; the operator assesses and audits it on that basis. The case is different for the software manufacturer whose software is itself the regulated product, for instance a medical device. There, validation is a discipline of its own.
Yes. There, too, what is validated is the application in the operator's process. The provider verifies its product against its own specification and runs the platform. The operator assesses the provider, bases its own evidence on that groundwork, scaled by risk, and remains responsible for fitness for purpose in its own process, including configuration, release cycles and data migration on exit. The infrastructure underneath must be qualified under Annex 11.
As deep as the risk demands. Test depth and the extent of documentation scale with the risk each function poses to the patient, the product and data integrity. The system's range of functionality is not the measure.
Last updated:
Validate by risk, not by range of functionality.
In an initial consultation, we review your QMS and your system landscape. From that we outline how your evidence will be built: from the intended use through a CSA-based test strategy to the validated state in operation. Free of charge, about 30 minutes.
Book an intro call
