CSA vs CSV for life sciences: five stages inspectors can trace

CSV (Computer System Validation) is the traditional specification-and-script approach to proving software works as intended. CSA (Computer Software Assurance) is a risk-based approach that selects proportionate activities and records instead of defaulting to exhaustive scripted testing. FDA's CSA guidance and the MHRA's data-integrity guidance both expect teams to size their effort to actual risk. For validation teams, that means every shortcut needs a documented, defensible reason an inspector can follow.

In short:

• Assess each software function by intended use, process impact and how detectable a failure would be; reserve scripted tests and full traceability for critical controls and quality decisions.
• For low-risk displays or reports, exploratory testing and supplier evidence may be enough when records confirm coverage of your configuration and intended use.
• Every conclusion statement should name the intended use, the risk rationale, the activities, issue resolution, the tester and the date, with screenshots or logs captured during exploratory testing.
• FDA's CSA guidance does not replace device-specific validation requirements; assess software that is itself a medical device or component separately.
• International teams should address data lifecycle risk, metadata and audit trail access, and make cloud contracts preserve usable records after migration or contract end.

CSA vs CSV at a glance

Computer System Validation proves a computerized system does what it is supposed to do through formal user requirements, detailed functional specifications and scripted test protocols with step-by-step expected results. CSV programs often execute, document and trace test cases to requirements, including those that carry little risk to product quality or patient safety. The result can be thorough but disproportionate: a low-risk reporting dashboard may accumulate documentation comparable to a system controlling a sterilization cycle.

Computer Software Assurance starts from a different question: what is this software actually used for, and what happens if it fails? CSA asks teams to determine intended use first, then select assurance activities proportionate to the risk that use carries. A feature with high process risk, like control of a critical process parameter, still warrants scripted, documented testing. A feature assessed as low risk, such as an informational report, might be covered by unscripted exploratory testing or a review of supplier evidence.

Not everything shifts toward lighter assurance. Functions that control a critical process parameter, make an automated disposition decision or directly affect product quality remain candidates for CSV-style rigor inside a CSA program, because the failure risk and detectability profile demand it.

What FDA expects: the four-step approach

FDA's Computer Software Assurance guidance lays out four steps for assuring production and quality system software. Treat this sequence as the backbone of any CSA program.

1. Identify intended use. Define exactly what the software does within your process and quality system, at the level of the specific feature or function, not the software as a whole.
2. Determine a risk-based approach. Assess the risk that the intended use carries, factoring in process impact and the likelihood that a failure would go undetected.
3. Select appropriate assurance activities. Choose from scripted testing, unscripted testing, ad hoc testing or supplier evidence based on the risk determination, not habit.
4. Establish appropriate records. Capture objective evidence proportionate to the risk: a pass or fail conclusion for low-risk items, a detailed script for high-risk ones.

The message underneath is proportionality, not a lower bar. FDA frames CSA as a way to focus assurance where automation introduces risk to product quality and the quality system, not as a way to skip validation. A team that reads CSA as "less documentation everywhere" has misread the guidance; the right reading is "the right amount of documentation for each specific risk."

From an inspector's point of view, acceptable evidence depends on the function. For a feature that generates a batch record automatically from equipment inputs, it might be scripted testing of the calculation logic plus exploratory testing of edge cases. For a feature that displays historical trend data without process-control implications, it might be unscripted testing and a documented conclusion statement, supported by vendor test evidence. In both cases the record, however brief, states the intended use, the risk decision and the conclusion in terms an inspector can trace.

Five governance stages and a phased checklist

A CSA program that survives an inspection needs structure. This five-stage model turns FDA's four steps into something a quality or validation team can run, with evidence captured at each point.

1. Define intended use and critical records. Document what the software function does, which process or quality decision it supports, and which records it generates. A vague or overly broad intended-use statement makes every later risk decision indefensible.
2. Assess impact and failure risk. Evaluate what happens if the function fails: does it affect product quality, patient safety or a regulated decision, and how likely is a failure to go undetected before it causes harm? This produces the risk rating that drives everything after it.
3. Select proportionate assurance activities. Scripted testing for high-impact functions, unscripted or exploratory testing for moderate-risk functions, and supplier evidence for low-risk functions where vendor testing genuinely covers the intended use.
4. Execute and retain objective evidence. Full scripts with expected and actual results for high-risk items, or a documented conclusion statement with supporting screenshots or logs for lower-risk items.
5. Maintain control. Keep the assurance package current through change control, periodic review and monitoring for configuration drift, so the original risk rationale still holds as the system changes.

At each stage, the evidence inspectors ask for first is a written conclusion statement: intended use, risk assessment, assurance activities, issues and their disposition, tester and date.

Mapping activities to risk works best as a simple rule your SOPs can enforce. A function that sets or enforces a critical process parameter, such as a sterilization temperature setpoint, warrants rigorous testing and traceability because a failure could affect a batch before anyone notices. A function that logs operator actions for audit trail purposes, without a process-control role, may be covered by unscripted testing if its assessed risk supports it. A function that formats a report for printing without transforming data might be assured through exploratory testing and vendor evidence.

Pro tip: write each conclusion statement as if an investigator will read it cold, with no access to your meeting notes. It should stand on its own.

Applying CSA to EBR, MES, LIMS and production systems

Intended-use evaluation gets concrete once you apply it to real system categories, because different platforms concentrate risk in different places. The first question for any system is which features control process parameters or make quality decisions, and which only monitor, display or report.

One caution applies across all of these: FDA's CSA guidance covers production and quality management system software, not software that is itself a medical device or part of one. Where software qualifies as Software in a Medical Device or Software as a Medical Device, device-specific validation requirements under 21 CFR Part 820 and the Quality Management System Regulation still apply, and CSA does not substitute for them. When one platform touches both production processes and device functionality, evaluate the device-related functions separately.

How often FDA cites computerized-system controls

Computerized systems show up on Form 483s more often than most teams expect. Across 90 human-drug Form 483s issued in late 2025 in the FDA Form 483 database, 21 CFR 211.68, automatic, mechanical and electronic equipment, which covers routine checks of computerized systems, controls over changes to master records and backup of data, was cited on 17%. The investigation requirement, 211.192, which is where unexplained data discrepancies end up, was cited on 31%, and laboratory controls under 211.160 on 32%.

For devices, inspections since February 2, 2026 run under the QMSR, and device Form 483s now cite ISO 13485 clauses rather than old Part 820 sections. In a sample of 96 device Form 483s issued between May and July 2026, risk management in product realization (clause 7.1) was cited on 31% and process validation, which includes validation of software used in production (clause 7.5.6), on 17%.

Inspection history at the facility level tells the same story: the FDA facility lookup shows which sites have been cited under 211.68 and how often. The practical use of these numbers is calibration. If your risk assessments describe software risks in different terms than investigators cite them, close that gap before an inspection does it for you. Searching the 483s in the database by CFR section shows the language investigators actually use (our guide to where to find FDA 483 reports covers the routes), and each investigator's profile in the FDA investigator lookup shows which sections that person cites most.

Atlas

See what the FDA knows about your next investigator.

30 minutes with the founder. No pitch deck.

See it live

Hybrid strategy: when to keep CSV-style rigor

A mature CSA program is almost always a hybrid, not a wholesale replacement of validation with lighter testing. The decision to keep CSV-style packages comes down to three criteria: does the function control a critical process parameter, does a failure directly affect product quality or patient safety, and would a failure be hard to detect before causing harm. When any of these is true, scripted testing with full traceability remains the defensible choice.

Documenting the hybrid decision matters as much as making it. The rationale needs to live where an inspector can find it: a risk assessment record referenced in the validation SOP, with the intended-use statement, risk rating and chosen assurance activities laid out function by function. Change control should reference the same rationale, so a configuration change to a high-risk function triggers a review against the original risk basis.

A defensible example: an MES platform where the recipe-execution module, which enforces process parameter sequencing, stays under full scripted validation with traceability to requirements, while the operator dashboard module, which only displays status, is covered by documented exploratory testing and a short conclusion statement. Both decisions sit in the same risk assessment, each with its own rationale, so an inspector sees a consistent, risk-driven logic rather than a patchwork.

Documentation and objective evidence: what inspectors expect

CSA records need enough information to serve as objective evidence rather than an unsupported claim:

• Intended use statement, specific enough to tie directly to a risk decision.
• Risk-based decision, with the risk level and reasoning, referencing process impact and detectability.
• Assurance activities performed, naming the method: scripted, unscripted, exploratory or supplier evidence.
• Issues and disposition, with any defect found and how and when it was resolved.
• Conclusion statement, tester and date, closing the record with a clear pass or fail and accountability.

Exploratory testing becomes inspectable only when it is captured as it happens. Keep a lightweight testing log of screenshots, outputs or session notes taken during the test, attached to the conclusion statement, so the record shows what was observed rather than a reconstructed memory.

Data integrity adds another layer. The MHRA's GxP data integrity guidance notes that flat files and relational databases carry different risks, and that audit trail access matters regardless of format. A true copy of a record must preserve not only the visible data but the metadata and audit trail that give it context.

International considerations: MHRA, cloud providers and suppliers

Organizations outside the United States need to read CSA alongside local data-integrity expectations, and the MHRA's guidance is the clearest reference. Its focus is the complete data lifecycle: how data is created, processed, reviewed, reported and retained, with attention to metadata and audit trail access rather than just the finished record.

Cloud and hosted platforms raise a specific risk. Contracts with cloud providers need to guarantee access to metadata and audit trails on an inspection timeline, not only for routine operations; a provider that can produce a report but not the underlying audit trail creates a gap the MHRA treats as a data-integrity weakness. Archival arrangements need the same scrutiny: data retained past a contract's end or a migration must remain retrievable in a usable, attributable form.

Common implementation mistakes

The same mistakes recur in CSA programs that struggle during inspection:

• Assessing software in isolation, without the people, procedures, training and data lifecycle around it. "The system is validated" is not an adequate conclusion on its own.
• Under-documenting exploratory testing, so genuinely useful testing leaves nothing for an inspector to review.
• Over-relying on vendor documentation without confirming it covers your site configuration.
• Traceability gaps between intended use, risk decision, assurance activity and record.
• Thin risk rationale, where a rating with no stated reasoning reads as arbitrary even when the judgment was sound.
• Audit trails that exist but cannot be reviewed.

Pro tip: before an inspection, pull a sample of conclusion statements and read them as if you had never seen the system. If the risk rationale is not obvious, rewrite it now.

What we recommend

The tension in CSA adoption is cultural, not technical. Teams with years of CSV habit read "risk-based" as permission to do less, and that reading is what gets flagged. The guidance asks for better-targeted accountability, and that only survives an inspection if the rationale is written down clearly enough for someone outside the original decision to follow.

Adopt a documented hybrid program deliberately rather than letting it emerge function by function. Decide up front which categories of function default to CSV-style rigor, write that rule into the validation SOP, and require every CSA-selected activity to produce a conclusion statement with the same five elements every time. Then compare your risk language against the language in Form 483s and warning letters for similar systems; our guides to what a Form 483 is and the most common documentation failures FDA flagged in 2024 and 2025 are good places to start.

Atlas

FDA Inspection Intelligence Digest

We track every 483, EIR, and warning letter the moment it happens. Get the signals before they hit the FDA website.

Subscribe