What is CSV?
Computer System Validation (CSV) establishes documented evidence that a computerized system is fit for its intended use. It connects the process, requirements, risks, testing and controls needed to keep the system suitable throughout its life.
The required evidence depends on the actual use and applicable quality procedures. A validation package should explain what was assessed, what was demonstrated and what remains to be managed.
What is CSA?
Computer Software Assurance (CSA) emphasizes critical thinking and a risk-based choice of assurance activities. It asks which failures matter and which evidence will establish confidence in the intended use.
FDA’s CSA guidance addresses software used in medical-device production and quality management. Apply its principles within the requirements relevant to your own sector; it does not replace those requirements.
What actually changes?
| Traditional tendency | CSA approach |
|---|---|
| Document extensively | Document what provides useful evidence |
| Test everything similarly | Focus testing based on risk |
| Heavy scripted testing | Use scripted and unscripted testing appropriately |
| Recreate supplier testing | Consider suitable supplier evidence |
| Focus on document completion | Focus on confidence in intended use |
Worked example
Example: an eQMS configuration
Worked exampleFictional example. A release changes a dashboard color and the CAPA approval workflow. Check that the display remains understandable. Put deeper testing into the approval path: challenge unauthorized approval, missing mandatory review and open records carried into the new version. Review relevant supplier evidence before deciding which checks to repeat locally.
Key takeaway
CSA does not mean less control. It means applying effort where failure matters and using appropriate evidence to support the intended use.
Detailed practice, examples and references
Plain meaning
Computerized system validation, or CSV, establishes and maintains evidence that a computerized system is suitable for its intended use. Computer software assurance, or CSA, emphasizes confidence in the software’s use through risk-informed assurance activities. In practice, the terminology matters less than the quality of the reasoning and evidence.
FDA’s February 2026 CSA guidance concerns software used in medical-device production and quality management systems. It is a guidance document with recommendations, not a universal replacement for every computerized-system obligation across all regulated sectors. FDA CSA guidance ↗
What a useful change looks like
Imagine a team writing 150 step-by-step scripts for an eQMS release. Many scripts repeat simple screen navigation. Meanwhile, none tests whether a rejected CAPA can bypass reapproval through an interface.
The improvement is to investigate the process risk and strengthen that missing challenge. Some navigation checks might be combined, automated, or supported by suitable existing evidence. The purpose is better confidence in the workflow, with records proportionate to the decision.
Three examples
Document library search. A user searches for a procedure. If the system can return obsolete documents as current, the important test is version and effective-status behavior. Testing only whether the search box accepts text misses the process concern.
Production acceptance calculation. Software determines whether measurements satisfy a product specification. The team needs confidence in the input units, formula, limits, rounding, and recommendation. A polished test report cannot compensate for an incorrect independent expected value.
Internal announcement page. Software displays an office event. Its failure has a different relationship to quality than a product acceptance decision. Check the actual use before assigning a regulated-process assurance burden.
What does not disappear
The team still needs an accountable owner, an understood process, suitable controls, an explanation of relevant risks, trustworthy evidence, and a decision about use. Changes and incidents still need attention. “We use CSA” is not a rationale for missing records or unsupported assumptions.
A better project conversation
Instead of asking, “How many scripts are required?” ask:
- What decision or action will this function support?
- What failure could affect the process?
- What prevents or detects that failure?
- What evidence already supports those controls?
- What uncertainty remains, and how will we address it?
Example record wording: “The test approach concentrates detailed challenges on acceptance calculations and status changes. Standard navigation uses reviewed supplier evidence plus local exploratory checks. This selection reflects the defined failures, local configuration, and evidence gaps; it is not based solely on a system-wide risk label.”
Where the familiar CSV deliverables fit
CSA does not prohibit a validation plan, user requirements specification (URS), functional or configuration specification, installation qualification (IQ), operational qualification (OQ), performance qualification (PQ), user acceptance testing (UAT), requirements traceability matrix (RTM), validation summary report (VSR), or release approval. Your quality management system (QMS), software category, intended use, and risk determine which records are needed and how detailed they should be.
| CSV lifecycle record | What it should establish | What CSA changes |
|---|---|---|
| Validation plan | Scope, roles, approach, deliverables, and acceptance route | Focus the plan on important functions and known uncertainties |
| URS and specifications | What users need and how configured functions must behave | Write testable requirements for functions that affect the regulated process |
| Risk assessment | Failure mode, process effect, existing controls, and risk | Use risk to select the type and depth of testing and review |
| IQ, OQ, PQ, or UAT | Installation, functional control, and use under realistic conditions | Use only the activities that answer relevant risk questions |
| RTM, deviations, and VSR | Coverage, exceptions, results, open items, and release conclusion | Keep traceability useful; do not create links or records with no decision value |
Practitioner guidance by Sandip Thorat · Simplified 17 September 2026. Apply the requirements and approved procedures relevant to your system. Report a correction.
Questions and discussion
Ask a question or share a perspective. Contributions are reviewed before publication.
Loading contribution options…