Validation of Computerized Systems.
Any computerized system that supports a GxP-relevant process must be validated - as 21 CFR Part 11 and EU GMP Annex 11 require. It is commonly known as Computer System Validation, or CSV. 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 per Computer Software Assurance (CSA).
What exactly is validated?
Validation covers the whole computerized system - the technology, the process it supports and the people who work in it - against the intended use. 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 carries its own form of evidence:
| Layer | Form of evidence |
|---|---|
| Hardware and infrastructure | is qualified - demonstrated once, the state remains reliable 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 - "validating the software", "qualifying the tools". Anyone familiar with the connections silently translates these phrases 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 does that evidence assert? 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 - its methodical foundation is GAMP 5 validation. Release is an endpoint, not a conclusion: the validated state holds for the configuration it was demonstrated for - and is maintained in operation.
- 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 precondition and the measure for every step that follows.
- 2
Validation planning
We review the existing QMS and draw up the validation plan - scope, roles, responsibilities and acceptance criteria; the plan sets the risk-based approach the later steps follow.
- 3
Requirements & risk assessment
The requirements translate the intended use into system requirements; the risk assessment weighs systems and functions against the risk to patients, product and data integrity.
- 4
Test strategy & specification
The risk-based test strategy per CSA defines which evidence is delivered at what depth - here we lay down what the testing will later redeem.
- 5
Testing, report & release
Documented testing of the relevant functions with demonstrable coverage of the requirements, the validation report, and release for GxP operation.
- 6
Operation: maintaining the state
Change control assesses every change for its impact on the validated state and triggers the re-examination it requires; continuous monitoring and periodic review surface what changes unnoticed. Incident management, security, support and training keep the system inspection-ready at all times.
The foundation underneath follows its own path of evidence: the application is validated, the supporting IT infrastructure is qualified. How its controlled state comes about - from your own data center to the cloud - is covered by IT Infrastructure Qualification.
From paper protocol to structured record.
The way the lifecycle is executed is changing fundamentally: from paper-based to digital validation. How this shift succeeds is covered by 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 loosely referred to as software validation. Computer Software Assurance addresses exactly this: the risk-based verification of application software in production and the quality management system - first published as final FDA guidance in September 2025, current in the February 2026 edition.
CSA invents no new discipline: it is the risk-based decision-making of ICH Q9 - good testing, applied consistently. The difference is not between two methods, but between cumbersome and effective testing - in the trigger, the depth of testing, and operation:
| Dimension | Flawed testing | Risk-based testing (CSA) |
|---|---|---|
| Testing trigger | everything gets tested - because it is regulated and for fear 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 to patients, product and data integrity |
| Evidence | extensive documentation for its own sake | effective testing, with documentation pared back to what matters |
| Changes in operation | blanket retesting after every change | re-examination assessed by risk, the validated 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 |
Operating systems and IT infrastructure are explicitly excluded from the guidance - infrastructure software such as networking, user authentication, or backup and restore is qualified. 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 make a system inspection-ready - and keep it in its validated state.
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 prove it?
Part 11 asked about records, ICH Q9 about risk, the data integrity wave about behavior, the cloud about control over third-party infrastructure - AI asks how you keep non-determinism under control.
We were presenting on cloud in 2011, while the market was still debating whether cloud was even permissible; we were running agile validation projects in GxP as early as 2013 - years before the industry formalized the approach.
The GCP thread runs deepest: 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 expectations. Into that gap we initiated the GAMP working group for GCP systems in 2008 (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 regulators.
And when the industry caught up, we helped write 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 our signature in every test strategy.
Frequently asked questions about computerized system validation.
No - validation applies to systems that support GxP-relevant processes. The causal chain is decisive: does the system influence, even indirectly, data, product and therefore the patient? 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 System Validation (CSV) and validation of computerized systems describe the same evidence. We use the precise term throughout: what is tested is not the software alone, but its application in the GxP process 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 - providers assure the quality of their product against defined standards and are assessed and audited for it by their regulated customers. Software validation at the manufacturer - where the software itself is the product, for instance as a medical device - is a discipline of its own.
Yes - there, too, what gets validated is the application in its process, against 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, while the operator assesses the provider and, scaled by risk, builds its own case on that groundwork. Responsibility for fitness for purpose in the operator's own process stays with the operator - through configuration, release cycles, and how the data leaves at exit. The infrastructure underneath is qualified against the requirements that apply to it.
When documented evidence shows that, in its process, it is suited to its 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 - not with the system's number of features. What counts is effective testing, documented to the extent the evidence genuinely needs.
Validate on a risk basis, not by default.
In an initial consultation, we review your QMS and your system landscape and define how the evidence will be delivered - 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
