Validation of Computerized Systems.
Any computerized system that supports a GxP-relevant process must be validated. That is what 21 CFR Part 11 and EU GMP Annex 11 require. What is validated is not the software, but its application in the process, against the intended use. We deliver that evidence from the operator's perspective: risk-based, driven by the risk to patients, product 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 it supports and the people within that process. The process is the starting point: it defines the system's purpose; requirements, risks and the scope of evidence follow from it. 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 in which every 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 configuration it was demonstrated for and is maintained in operation. The draft revision of Annex 11 requires 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
The requirements analysis translates the intended use into system requirements; the risk assessment weighs systems and functions by the risk they carry for patients, product 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 and documented, with demonstrable coverage of the requirements; the validation report and the release for GxP operation conclude the step.
- 6
Operation: maintaining the state
Change control assesses whether a change affects the validated state and triggers the re-examination it requires; continuous monitoring and periodic review bring to light whatever is changing unnoticed. Incident management, security, support and training keep the validated state intact through operation.
The foundation under the application follows its own path of evidence: the application is validated, the supporting IT infrastructure 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.
How the lifecycle is carried out is changing fundamentally: paper-based validation is becoming digital. This shift is explored in depth in digital transformation in the GxP environment.
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, and its evidence is properly called verification, even if it is often misleadingly referred to as software validation. Computer Software Assurance addresses exactly this: the risk-based verification of application software in production and in the quality management system. The final FDA guidance first appeared in September 2025; the version in force is the February 2026 revision.
CSA does not invent a new discipline; it follows the same risk-based thinking as ICH Q9: 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, out of regulatory reflex and 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 actual 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 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 Second 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 that support 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 scale with 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. Software validation at the manufacturer is a discipline of its own: there, the software itself is the product, for instance a medical device.
Yes. There, too, what is validated is the application in its process, aligned with the operator's intended use. SaaS is the application layer, not the infrastructure. What shifts is the burden of evidence: the provider verifies its product against its own specification and runs the platform. The operator assesses the provider and bases its own evidence on that groundwork, scaled by risk. Responsibility for fitness for purpose in the operator's own process stays with the operator. It extends to configuration, release cycles and what happens to the data on exit. The supporting infrastructure underneath must be qualified under Annex 11.
When documented evidence shows that, in its process, it is fit for the intended use. Release marks the point where that state is reached. It holds, however, only for the configuration it was demonstrated for: every change is assessed through change control so that the validated state is maintained across the lifecycle.
As deep as the risk demands. Test depth and the extent of documentation scale with the risk each function carries for patients, product and data integrity. The system's range of functionality is not the measure.
Validate by risk, not by range of functionality.
In an initial consultation, we review your QMS and your system landscape. From that we sketch the path of your evidence: 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
