The FDA rewrote its software assurance guidance in February 2026. Most CSV guides on the first page of Google were written before it existed.
That's the trouble with Computer System Validation (CSV). The regulations move, the articles don't, and validation teams build documentation sets against expectations that expired eighteen months ago. That can be an expensive way to fail an inspection you were confident about.
What is computer system validation in pharma?
Computer system validation in pharma is the documented process of proving that a computerized system consistently performs as intended and meets GxP regulatory requirements. It runs from planning and defining intended use through risk assessment, verification and release, and continues for as long as the system is in service.
Key takeaways
This guide is for validation managers, QA professionals and IT teams. By the end you will know which systems need validating, what the documentation must prove, and where the effort is worth spending.
If you'd rather view the templates before the theory, our CSV Handbook has the validation plan, URS and traceability matrix. Otherwise, start here.
What does computer system validation actually ask you to prove?
Most definitions describe CSV as a process. That's accurate, but it doesn't explain what the process is ultimately intended to establish.
The core question CSV asks you to answer is: Can you demonstrate, with documented evidence, that the computerized system consistently performs as intended, supports the regulated process correctly, and maintains the integrity of the data it creates, processes, or stores?
What is CSV in simple terms?
Computer system validation is the work of establishing documented evidence that a computerized system will consistently do what you specified it should do, inside the process where you use it.
What does a validated state mean in practice?
A validated state is a claim you defend at any moment, including the moment an inspector walks in unannounced. Most treat it as a certificate earned once. It rests on three things:
- The system is fit for its intended use
- It performs consistently
- You hold current evidence for both
That evidence may need to be demonstrated to an inspector, an auditor or a customer, and each will ask for documentation, not assurances.
What is the difference between validation, verification, qualification and testing?
Validation, verification, qualification, and testing get used interchangeably and mean different things on paper. Mixing them up in a validation plan invites an auditor's challenge.
For more information on system validation and qualification, watch our video below:
When is computer system validation required in pharma?
Computer system validation in pharma is required less often than companies assume, and far more thoroughly where it counts. The scope and level of validation required depends on whether the system can affect data integrity, product quality and patient safety. For more context, read our guide on GxP computer system validation.
Which computerized systems fall in CSV scope?
Lists of in-scope systems circulate widely: laboratory information management systems (LIMS), manufacturing execution systems (MES), ERP modules, electronic batch records, electronic device history records, training, complaints, CAPA, change control and document management.
The list helps, up to a point. Scope belongs to intended use, not system category, which is why the same LIMS product sits in scope at one site and outside it at another.
Ask instead: does this system create, modify, store, transmit or decide on GxP data? GxP covers GMP, GCP, GLP and GDP.
Recommended learning:
What are the three risk-based triggers?
The three key risk-based considerations for computerized systems are patient safety, product quality, and data integrity. A system's intended use and GxP impact should be assessed to determine whether a failure could affect any of these areas and what level of assurance is appropriate.
Use these questions as a starting point for a risk-based CSV assessment:
- Patient safety: Could a system failure harm a patient or create an unacceptable risk to patient safety?
- Product quality: Could a system failure compromise the identity, strength, quality, or purity of a product?
- Data integrity: Could a system failure make GxP data incomplete, inaccurate, unreliable, or otherwise unsuitable for its intended use?
If the answer is yes to any of these questions, include the system in the risk-based CSV assessment and determine the appropriate level of assurance. If the answer is no to all three, document the rationale for determining that the system is outside the relevant CSV scope.
The draft revision of Annex 11 names all three as the axes for quality risk management across the system lifecycle: the approach should consider the complexity of processes, the level and novelty of automation, and the impact on product quality, patient safety and data integrity.
The FDA words it differently. CSA frames risk in two parts, not three, and only for devices: assurance effort follows the risk of compromised safety and/or quality of the device. FDA's Part 11 guidance uses a third formulation: product quality and safety, and record integrity. Note record integrity, not data integrity.
Use the Annex 11 triad. It is the broadest, and the only one written for computerized systems across the whole GxP lifecycle. Where a failure reaches none of the three, you are validating out of routine.
Which regulations govern computer system validation in pharma?
The main regulatory and industry frameworks relevant to CSV in pharma are 21 CFR Part 11, EU GMP Annex 11, GAMP 5, and data integrity principles such as ALCOA+. They serve different purposes and do not have the same regulatory status. 21 CFR Part 11 and EU GMP Annex 11 are law, GAMP 5 is industry guidance, and ALCOA+ is a set of principles.
Do the same FDA rules apply to drugs and devices?
If you make pharmaceutical drugs, your predicate rule is 21 CFR 211.68, and FDA does not publish CSV guidance written for drug manufacturers. For medical devices and in vitro diagnostics (IVDs), that framework changed on 2 February 2026, when the Quality Management System Regulation (QMSR) replaced most of 21 CFR Part 820 and moved software validation into ISO 13485.
This matters for when applying FDA’s Computer Software Assurance (CSA) guidance. Both Computer Software Assurance guidance and General Principles of Software Validation are scoped specifically to medical devices. Drug manufacturers borrow them by analogy. Say so in your validation plan and no inspector will argue.
What does 21 CFR Part 11 require?
21 CFR Part 11 sets the criteria under which FDA treats electronic records and signatures as equivalent to paper. It applies to electronic records and electronic signatures, particularly whenever they are used to replace a paper record or a wet-ink signature.
Four obligations sit underneath it, grouped from the eleven lettered controls in Section 11.10:
- Validation, so the system produces accurate, reliable, consistent results and can spot an invalid or altered record. This is § 11.10(a), the clause most Part 11 summaries leave out.
- Authenticity and integrity, so you can prove who signed and that nobody altered the record afterwards.
- Readability, so the record outlives the software that created it.
- Secure, computer-generated audit trails, and control of system access.
What is EU Annex 11, and what is changing?
EU Annex 11 governs computerized systems used in GMP activities across the EU. The 2011 version is in force and is what inspectors work from today.
A draft revision went out for consultation on 7 July 2025, comments closing 7 October 2025. It runs to 19 pages against the current five, in 17 chapters plus a glossary.
What deserves attention is where the weight moved. In the draft, Security, Identity and Access Management, and Audit Trails each get a chapter of their own. That is where inspection attention is heading, not toward more test scripts.
Section 9.6 is also more specific about testing: access privileges, product release, calculations, audit trails, error handling, boundary and negative testing, interfaces, and restore from backup. If your last validation did not exercise a restore, read it closely.
A new draft Annex 22 covering artificial intelligence went out in the same package, alongside a revised Chapter 4 on documentation.
What is GAMP 5 2nd edition?
GAMP 5, the Good Automated Manufacturing Practice guide, is ISPE guidance, not a regulation. Teams work from it because it answers what regulations avoid. The key question GAMP 5 2nd Edition helps you answer is: How much validation effort is appropriate for this system, based on its intended use, complexity, and risk?
Its answer is effort scaled to software category and risk. A configurable off-the-shelf product does not get the same treatment as custom code. The second edition added critical thinking as a principle and far more on cloud-hosted systems. Pair it with ICH Q9(R1), adopted January 2023.
Read GAMP 5 for GxP-compliant computerized systems and what changed in the GAMP 5 2nd edition for more details.
What is ALCOA+?
ALCOA+ is the data integrity framework regulators use to judge whether a record can be trusted. Validation for computerized systems ultimately reduces to data. If the data cannot be trusted, the validation serves no purpose. The MHRA GXP data integrity guidance spells it out in detail, giving nine attributes: attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring and available.
Common data integrity weaknesses include:
- Contemporaneous: records are entered after the fact because operators batch their entries at the end of a shift.
- Attributable: records cannot be reliably linked to the person who performed the activity, such as when three people share a login because procurement wouldn't pay for three seats.
- Complete: the record is incomplete when a failed test run is re-executed and only the passing result reaches the file.
These principles connect CSV to the quality of the data a computerized system creates, processes, or stores.
Recommended learning:
What are the stages of the computer system validation lifecycle?
The computer system validation (CSV) lifecycle typically includes seven stages: planning, defining intended use, assessing risk, building and configuring, verifying, releasing, and maintaining the validated state. Computer system validation in pharma has no finish line, so draw it as a loop. Treat it as a project with an end date and the validated state degrades.
Figure 1. The CSV lifecycle: plan, define intended use, assess risk, build and configure, verify, release, maintain. Stage seven feeds change control, which returns you to stage one.
1. Planning: what goes into the validation plan?
Decide scope, effort and responsibilities before anybody opens a test script. The validation plan records what you are validating, what you are not, who signs what, and how you assessed the supplier.
Tip: name the person accountable for each deliverable, and make sure that person knows it.
2. Defining intended use: what belongs in the URS?
The User Requirements Specification (URS) describes what you need the system to do in your process. Not what it can do. What you need.
Tip: Good requirements are traceable units, and each carries a unique identifier and a criticality rating applied before testing starts.
3. Assessing risk: how do you score a requirement?
Score each requirement against severity, likelihood and detectability. High-severity, low-detectability functions earn the most verification effort. Everything else earns less.
Tip: If everything scores medium and is tested the same way, the assessment served no purpose.
4. Building and configuring: what has to be documented?
Document the configuration you applied, the security roles you created and the workflows you enabled. Configuration is where most GxP risk lives, because it is the layer you control.
Tip: the configuration specification lets someone rebuild the instance from it.
5. Verifying: what replaced IQ, OQ and PQ?
GAMP 5 2nd Edition states plainly that it “does not use traditional pharmaceutical process validation terminology such as IQ/OQ/PQ”, because the terms imply a linear approach. What replaced them is verification. GAMP 5 Table 4.1 maps the old words onto testing or other verification:
- IQ becomes verification that software and hardware are correctly installed and configured.
- OQ becomes verification against specifications, demonstrating correct operation of the functionality supporting your business process.
- PQ becomes verification demonstrating fitness for intended use, allowing acceptance against specified requirements.
Keep saying IQ/OQ/PQ if your SOPs do. Just know the labels are yours, not the regulators', and what gets inspected is the verification underneath.
For SaaS platforms, the shape shifts, and the FDA now explicitly accepts a mix of scripted and unscripted testing. See how we validated Scilife as a SaaS implementation for a worked example.
Tip: Screenshots carry a date, a time and a username, and deviations get closed.
6. Releasing: what has to be true before go-live?
Establish go-live criteria, training delivered and assessed, SOPs approved and in force. Releasing against draft SOPs is a routine finding. The draft Annex 11 is strict: qualification and validation “should be successfully completed and reported prior to approval and taking a system into use”.
Tip: The summary report states the residual risk in plain words, and the signer can explain it out loud.
7. Maintaining: how do you keep a system validated?
A system remains in a validated state through controlled change management, periodic review, incident and deviation handling, and other lifecycle controls. Keep change control, periodic review, incident and deviation handling under control.
The stage also covers retirement. Decommissioning is part of the lifecycle, and the records a system holds must stay readable for the full retention period after the system itself is gone.
Tip: A file full of no action required tells an inspector more about the reviewer than the system.
What CSV validation documentation do auditors ask for?
Auditors ask for eight documents in almost every inspection: validation plan, URS, risk assessment, traceability matrix, test protocols with evidence, validation summary report, supporting SOPs and training records.
The first two columns are standard. The third is the part guidance documents leave out, and where most validation documentation fails.
An auditor rarely asks whether a document exists. They ask what it proves, then check whether the rest of your evidence agrees. Traceability is where contradictions surface.
Recommended learning:
What is risk-based validation, and what did CSA change?
Risk-based validation means matching effort to what a failure could actually harm, so high-risk functions get scripted testing and low-risk ones get less. It has been the mandate for two decades, and in many organizations it stays a claim.
What decides how much validation effort a system deserves?
Two variables set the work a system deserves: the severity of damage if it fails, and the degree of customization. A configurable eQMS used for document control sits elsewhere from custom code that calculates a release decision. Treat them identically and one is over-validated, the other under-validated.
How much of a vendor’s validation work can you rely on?
You can rely on a supplier's development and testing, but you cannot delegate accountability. The draft Annex 11 says so directly: the regulated user “remains fully responsible for adherence to the requirements included in this document, for maintaining the evidence for it, and for providing it for regulatory review”.
The supplier assessment decides how much of the vendor's work you can lean on, and it moves your testing scope more than anything else you do.
What does the FDA's CSA guidance change?
FDA's Computer Software Assurance (CSA) guidance introduces a risk-based approach for establishing confidence in software used for medical device production and quality management systems.
The final version arrived in February 2026, one day after QMSR replaced the Quality System Regulation. It supersedes Section 6 of General Principles of Software Validation; the rest of that 2002 guidance stands. Note that CSA is written for medical devices.
The substance is straightforward. Direct assurance effort toward functions that could compromise patient safety, product quality or data integrity. Accept unscripted testing for lower-risk functions. And stop generating documentation whose only purpose is proving documentation was generated.
Recommended learning:
What does risk-based validation look like on two real changes?
Two changes arrive in QA's inbox. The first adds an optional free-text field to a meeting-notes form. The second modifies the workflow gating batch release, changing who approves at the final step.
Both enter the same change control process and both need an impact assessment. Then they diverge. The first needs a functional check and a record that somebody thought about it. The second needs requirement-level risk assessment, scripted testing of every approval path including those meant to fail, and evidence the old route is closed.
Same procedure and the same rigor of thinking, but one requires twenty times the verification effort. That's risk-based validation applied.
How do you validate a SaaS system?
You validate a SaaS system by assessing the supplier, then validating your own intended use, configuration and process controls on top of their platform.
Cloud changed who does the work, not who is accountable. Computer system validation in pharma applies to a hosted platform on the same terms, and most friction happens after go-live.
Who is responsible for what in a validated SaaS system?
Your vendor owns the platform: infrastructure, application code, their development lifecycle, their security controls. The end-user owns intended use, configuration, user access and process controls.
Put that split in writing before go-live. It is the only thing that stops both sides assuming the other one did it.
What should you ask a SaaS vendor before signing?
Ask before signature, while you can still negotiate:
- The validation package, and exactly where it stops. A good vendor hands you a plan, requirements, risk analysis, qualification evidence, a traceability matrix and a summary report. None of it validates your configuration.
- Release notes every time, and the notice period before a major release goes live. Sixty days is fair; under a month makes planned testing impossible.
- A pre-production environment on its own database, to test a release against your configuration first.
- What the audit trail captures, field by field: user, timestamp, and previous and new value.
- Evidence that you have tested a restore, not a policy saying restores are tested.
- Where your data physically sits, and whether you choose the region.
- What happens to your records when the contract ends, because GxP retention outlives most contracts.
A vendor who cannot produce these has told you something about the rest of the relationship.
How do you handle frequent vendor releases?
A platform that ships continuously will outpace an annual revalidation cycle within a year, so agree the tiering before go-live.
Most vendors split releases in two. Minor releases and hotfixes need a documented review of the release notes, with effort only where your configuration is touched. Major releases need a change request scoped to the affected requirements.
Two words are worth using precisely, because GAMP 5 does. Regression analysis works out what a change affects and what needs retesting. Regression testing is the retest. Appendix M6 puts both in the quality plan.
Read choosing between an on-premise and a cloud QMS and using SaaS solutions in GxP-compliant industries for the wider picture.
What are the seven most common software validation mistakes in pharma?
Most CSV failures come from seven recurring mistakes, all of them early decisions nobody revisited.
- Treating CSV as a project with an end date. Software validation in pharma is a lifecycle obligation, budgeted or not.
- A URS that describes features instead of intended use. Copy the vendor's capability list into your requirements and you test their software, not your process. Everything passes, nothing gets proven.
- No traceability. When an auditor asks how a requirement was verified, the answer takes 40 minutes to assemble and is unsatisfactory before anybody reads it.
- Testing what's easy. Login screens get exhaustive coverage. The calculation that decides whether a batch is released gets one happy-path script.
- Change control that stops at go-live. Configuration drifts, permissions accumulate, somebody adds an integration. Two years on, the documented system and the running system are different systems entirely.
- Access reviews and audit trail reviews that exist only as SOPs. Writing the procedure is the easy 10%. PIC/S PI 011-3, good practices for computerized systems in regulated GxP environments, treats a missing system description as potentially critical or major, and a procedure nobody followed is worse: the control was designed, but ignored.
- Over-validating the harmless while under-validating the dangerous. Both come from one root, a risk assessment written but not used. One wastes money. The other turns up on an FDA Form 483.
How do you check the health of your CSV program?
Run these five checks in order. They tell you more about your validation program than any gap assessment.
- Mark every system in your inventory against the three triggers. Anything that touches none of them, stop validating and record why.
- Open the traceability matrix for your most critical system, pick a requirement, and trace it end to end. Time yourself.
- Check the date of your last periodic review, and whether it concluded anything.
- Ask your main SaaS vendor for their last twelve release notes. How long they take tells you how much room you have for regression analysis.
- Read the draft Annex 11 chapters on Security, Identity and Access Management, and Audit Trails. That is where the next inspection cycle is going.
For the method behind these checks, read the GxP Computer System Validation guide.
Conclusion
Computer system validation in pharma is the standing claim that a system is fit for the job you bought it for, and the evidence that lets you defend it any day.
Three things decide whether you can. Scope the work against patient safety, product quality and data integrity. Direct the effort where a failure would actually hurt, which is what the draft Annex 11 and CSA now ask for.
And treat maintenance as the stage that matters, because the validated state lapses long before anybody notices.
The regulatory ground shifted in 2025 and again in 2026. Most guides have not caught up. Yours does not have to be.
Next step
Starting a validation or repairing one? The CSV Handbook includes validation plan, URS, and traceability matrix templates ready to fill in.
