A validation engineer at a mid-size pharma company spends three weeks writing 47 scripted test cases for a training management module. Every step has a screenshot. Every expected result is documented. The package is 180 pages. An internal auditor reviews it, finds no defects, and signs off.

Six months later, the same module fails a critical workflow in production. The failure was in a boundary condition that none of the 47 scripts tested — because the scripts were written to prove the system works, not to find where it breaks.

This is the CSV trap. And it is exactly what the FDA’s Computer Software Assurance framework was designed to fix.

The Core Paradox

The fundamental tension in the CSV-to-CSA transition is this: the organization must do less documentation while simultaneously achieving higher assurance. That sounds contradictory until you understand what CSA actually changes.

Traditional CSV asks: “Did we execute all required scripts?”

CSA asks: “Do we have confidence this software works for its intended use?”

The first question rewards volume. The second rewards judgment. They produce fundamentally different validation packages, different testing strategies, and different Quality organizations.

The FDA finalized its CSA guidance in September 2025 and updated it in February 2026 to align with the new Quality Management System Regulation (QMSR) that folds ISO 13485:2016 into 21 CFR Part 820. This is not a draft. It is the current regulatory expectation. And it explicitly supersedes Section 6 of the older General Principles of Software Validation guidance for production and quality system software.

What CSA Does NOT Change

Before diving into what needs to change, it is worth stating what does not:

  • High-risk functions retain rigorous scripted testing. If a function directly affects patient safety, product quality, or batch release — MES recipe execution, LIMS sample pass/fail, electronic batch record calculations — it still gets full scripted verification with traceability and formal defect handling.
  • Part 11 requirements are unchanged. Electronic signatures, audit trails, and access controls remain non-negotiable.
  • Existing validated systems remain validated. You do not retroactively convert existing CSV packages. You apply CSA forward for new systems and material changes.
  • Objective evidence is still required. The form of evidence changes. The requirement for it does not.

Phase 1: Rewrite the Foundation (Weeks 1-4)

Issue a CSA Position Paper

The first deliverable is a two-page memo signed by QA leadership. It states three things:

  1. The organization is adopting FDA’s Computer Software Assurance guidance as its interpretation of 21 CFR 820.70(i), 820.75, and the QMSR.
  2. What CSV meant (exhaustive, one-size-fits-all testing) and what CSA means (effort commensurate with risk).
  3. Existing validated systems remain validated.

This memo is not a formality. It is the organizational permission slip that lets validation engineers change their behavior without fear of being told “that’s not how we do things.”

Re-Inventory by Intended Use

The old CSV inventory listed systems. The CSA inventory lists functions by intended use.

For every computerized system, answer: “Is this directly used as part of production or the quality system?”

Category Examples CSA Treatment
Direct impact MES recipe execution, LIMS sample pass/fail, eQMS approval workflows Full assurance, scripted for high-risk functions
Supports production ERP inventory tracking, issue tracking, calibration tools Reduced rigor, unscripted for medium-risk
Out of scope Email, general BI dashboards, office tools Vendor assessment only or justified exemption

The critical shift: a single system can span all three categories. An eQMS has high-risk functions (electronic signatures, approval workflows, audit trails) and low-risk functions (search, dashboards, UI preferences). CSA assesses at the function level, not the system level.

Form the Cross-Functional Task Force

CSA is not a Quality-department-only initiative. The task force needs:

  • Quality / CSV lead (sponsor)
  • IT / systems engineering
  • Manufacturing / operations
  • Regulatory affairs
  • Business process owners for key systems

Without cross-functional alignment, Quality rewrites the SOPs and everyone else keeps behaving like it is still CSV.

Phase 2: Rebuild the Risk Framework (Weeks 4-8)

Replace System Criticality with Process Risk

This is the single biggest conceptual change.

Traditional CSV: “MasterControl is a critical system, therefore everything gets extensive testing.”

CSA: “Which specific functions in MasterControl can cause a significant quality, data integrity, or patient safety consequence if they fail?”

For MasterControl, that might look like:

High process risk:

  • Electronic signature
  • Approval workflow
  • Effective-date control
  • Controlled document versioning
  • Audit trail
  • Training completion status

Medium process risk:

  • Routing notifications
  • Workflow reminders
  • Search functionality
  • Dashboards

Low / not high risk:

  • UI preferences
  • Cosmetic settings
  • Convenience functions

Now your assurance effort follows the risk. A search function bug does not carry the same consequence as an electronic signature bypass. Your testing strategy should reflect that.

Build the Risk Assessment Template

For every function, document six elements:

  1. Intended use — a specific operational statement, not a generic description. “Users must be able to locate the currently effective version of an SOP” is useful. “System shall provide a search function” is not.
  2. Failure mode — what could reasonably go wrong
  3. Potential impact — severity on patient safety, product quality, data integrity
  4. Risk classification — High / Medium / Low
  5. Existing controls — RBAC, authentication, audit trails, validation of upstream systems
  6. Required assurance — scripted / unscripted / vendor evidence / configuration review

This template becomes the heart of your CSA methodology. Every downstream decision — testing approach, documentation depth, AI applicability — flows from it.

Rewrite Four Core QMS Documents

Document What Changes
Validation SOP → Software Assurance SOP Replace “validate” language with “assure.” Add risk-tiering decision logic. Explicitly permit unscripted, exploratory, and automated testing.
Validation Master Plan → Assurance Plan Add the matrix: Risk Tier → Assurance Method. Remove mandatory IQ/OQ/PQ waterfall language.
Testing SOP Formally allow the three testing approaches. FDA explicitly encourages “a mix of scripted and unscripted tests proportionate to risk.”
Vendor Qualification SOP Require leveraging supplier artifacts. Accept SOC 2, ISO 27001, release notes, and automated test suites as baseline evidence.

Phase 3: Change How You Test (Weeks 8-16)

The Three Testing Approaches

Risk Level Old CSV Way New CSA Way Evidence
High 50 scripted test scripts with screenshots Still scripted, but focused on process risk scenarios, negative testing, challenge testing Script + audit trail export
Medium Same 50 scripts Unscripted / exploratory, scenario-based, error-guessing. Leverage vendor testing. Video recording, system logs, summary notes
Low Same 50 scripts Ad-hoc verification + supplier certification One-line record: intended use, risk, what was tested, by whom

Structured Exploratory Testing

Unscripted does not mean unstructured. For medium-risk functions, use test charters:

Charter: “Determine whether users can circumvent the document approval workflow.”

The tester explores: alternate navigation paths, browser back button, direct URLs, concurrent sessions, role changes mid-workflow, rejected documents, expired sessions.

They record: objective, tester identity, environment, actions taken, observations, evidence captured, conclusion.

This approach finds defects that scripted happy-path testing systematically misses. It is also explicitly recognized by the FDA under CSA.

Stop Doing These Things

  • Stop writing scripted test cases for functions that do not directly impact product quality
  • Stop requiring screenshots for every routine pass step (require only for deviations or complex edge cases)
  • Stop executing baseline IQ/OQ steps that the vendor has already proven
  • Stop printing screenshots — archive digital evidence instead

Start Doing These Things

  • Map every requirement to its risk tier; only high-risk gets full scripted coverage
  • Use system audit trails as primary test evidence
  • Archive automated test runner logs
  • Export electronic traceability matrices from your ALM tool
  • Record exploratory testing sessions as video evidence

Phase 4: Integrate AI in the Sweet Spot (Ongoing)

Where AI Belongs

The medium-risk, high-volume tier is where AI delivers the most defensible value under CSA. These are tasks that are too important to skip but too voluminous to do entirely by hand:

Process AI Does Human Does
URS Drafting Auto-generates initial requirements from process descriptions, FMEA inputs, regulatory references Reviews for intended use accuracy, adds critical thinking rationale, applies e-signature
Requirements-to-Test Mapping Maps requirements to test cases, flags gaps, generates RTM draft Approves RTM, adjusts for high-risk gaps, validates coverage
Evidence Summarization Parses test run outputs, summarizes logs, drafts pass/fail deviation summaries Performs critical review, verifies against raw data, applies Part 11 e-signature
Risk Assessment Suggests risk classifications from function descriptions and historical data Makes final risk determination, approves classification

The Governance Controls

AI is classified as an Indirect / Supporting Tool under the CSA framework — not a GxP production system. But it still requires:

Supplier assessment: SOC 2, data residency guarantees, contractual commitment that your data is not used for model training.

Installation qualification: Model version locked, configuration documented, prompt library version-controlled. Every prompt used to draft a URS is a GxP record.

Three mandatory controls for every AI-generated document:

  1. Audit trail: Prompt version + model version + date + user captured in document history
  2. Verification checklist: Human reviewer attests: “I verified AI output against source process documents and risk assessment. No hallucinated requirements.”
  3. Part 11 compliance: AI cannot apply an e-signature. Only a qualified QA person with a unique login applies the final electronic signature. AI output remains Draft status until then.

Performance Monitoring

Define measurable thresholds and monitor continuously:

  • Less than 10% edit rate for AI-generated URS drafts
  • 100% accuracy for requirement-to-test mappings
  • Less than 5% omission rate for critical findings in evidence summaries

If a tool misses a threshold, trigger a CAPA, re-assess the tool’s credibility, and update its evidence package.

Phase 5: Retrain the Organization (Ongoing)

The Five Questions

Every Quality team member should internalize five questions:

  1. What is this system function intended to do?
  2. What could reasonably go wrong?
  3. What happens if it goes wrong?
  4. What evidence would give us confidence?
  5. Why is this evidence sufficient?

That is the CSA mental model. It replaces the old CSV model of “because our SOP says to execute 147 test scripts.”

What to Train On

  • Critical thinking: Asking “why” before writing any test script. If the answer does not relate to patient safety, product quality, or data integrity, it likely does not require formal scripting.
  • Exploratory testing techniques: How to probe software without rigid scripts while still capturing objective evidence.
  • Risk assessment methodology: How to defend a “not high process risk” classification to an FDA investigator.
  • AI output evaluation: How to spot hallucinations in AI-generated requirements and traceability matrices.
  • Audit readiness: How to demonstrate that a system is fit for its intended use, not just that all test scripts were completed.

The Cultural Barrier

This is the hardest part. CSV conditioned teams to equate documentation volume with assurance. A 200-page validation report feels safe. A 10-page assurance statement feels risky — even when the assurance statement contains more critical thinking than the 200 pages of screenshots ever did.

Quality leadership must actively coach teams through this transition. The reframe: success is not “did we test everything?” but “do we have confidence this works?”

Phase 6: Pilot, Measure, Scale

Pick One System

Choose a medium-risk system coming up for a lifecycle event — an upgrade, a new module, a periodic review. Do not start with a high-risk manufacturing execution system. Do not try to convert the entire portfolio at once.

Run the full CSA flow:

  1. Intended use documentation (one page per function cluster)
  2. Feature-level risk assessment workshop with Process Owner and QA
  3. Assurance plan per risk tier
  4. Execute unscripted for medium-risk, scripted for high-risk
  5. Digital evidence package

Measure These Metrics

Metric Expected Direction
Validation cycle time Decrease 40-60%
Documentation volume Decrease 50-70%
Critical defects found in UAT Stay flat or improve
Defects escaped to production Stay flat or improve
Team satisfaction Increase
Audit readiness confidence Increase

Then Scale

After the pilot succeeds and internal quality stakeholders approve, expand to additional medium-risk systems. Once the team is proficient, adapt the framework for low-risk (even more streamlined) and high-risk (more rigorous, but still risk-based) systems.

The Bottom Line

Moving from CSV to CSA is not a re-validation exercise. It is a governance and decision-making model change. The organizations that get this right will ship validated systems faster, find more real defects, and face less audit anxiety — because their evidence packages demonstrate critical thinking rather than checkbox compliance.

The trap most organizations fall into is treating CSA as “CSV but with AI and fewer screenshots.” The actual transition starts with rewriting how Quality thinks about risk, continues with changing how testing is designed and executed, and only then introduces AI as an accelerant for the medium-risk, high-volume work that CSA’s risk-based model makes defensible.

Start with the SOP. Build the risk framework. Pilot one system. Measure the results. Then scale.

That is the playbook.

Research notes: [[CSV to CSA Transition - Comprehensive Compiled Report]]