In many FDA-regulated companies, computer system validation (CSV) has come to mean scripted test protocols, step-by-step evidence and screenshots for almost every function. FDA's Computer Software Assurance (CSA) guidance asks a different question. Not "did we document everything?" but "how much assurance does this function need, given what happens if it fails?"
This article explains what the guidance says, who it applies to, and what changes in day-to-day work for validation teams.
Key takeaways
- FDA finalized its CSA guidance in September 2025 and reissued it on February 3, 2026, aligned with the new Quality Management System Regulation (QMSR).
- It covers software used in medical device production and quality systems. It does not cover device software functions.
- Testing rigor follows risk. Functions that pose high process risk get more rigorous testing. Lower-risk functions can rely on unscripted testing.
- FDA recommends digital records such as logs and audit trails over screenshots and paper.
- Part 11 still applies. CSA changes how you build confidence in software, not whether you need it.
Where CSA comes from
FDA's General Principles of Software Validation guidance dates from 2002. Section 6 of that document, "Validation of Automated Process Equipment and Quality System Software," covered the software used in production and quality systems.
On September 24, 2025, FDA announced the final CSA guidance in the Federal Register. On February 3, 2026, FDA issued an updated version titled Computer Software Assurance for Production and Quality Management System Software. It supersedes the September 2025 version.
The update tracks a regulatory change. The QMSR took effect on February 2, 2026 and incorporates ISO 13485:2016 by reference. The current guidance refers to Part 820 as it now applies through ISO 13485.
The CSA guidance supersedes Section 6 of the 2002 guidance. The rest of the 2002 document still applies, and CSA supplements it.
Who the guidance applies to
The guidance covers computers and automated data processing systems used as part of production or the quality management system for medical devices. It was prepared by CDRH and CBER "in consultation with the Center for Drug Evaluation and Research (CDER)." It does not address design verification or validation of software that is itself a device function.
Drug and biologics manufacturers outside that scope still have a well-established risk-based reference. ISPE's GAMP 5 Guide, 2nd Edition explores CSA concepts. ISPE's summary of the second edition notes that it encourages "exploratory testing and other unscripted techniques" to extend test coverage, and it stresses critical thinking. Pharma QA leaders should decide with their regulatory teams how far to adopt CSA terms in their own SOPs.
The CSA framework in four steps
The guidance describes a four-part approach.
- Identify the intended use. Decide whether the software, or each feature, function and operation, is used directly in production or the quality system, or supports it. Different functions in one system can play different roles.
- Determine the risk-based approach. Identify reasonably foreseeable failures and decide whether each poses a high process risk. FDA considers a function to pose high process risk "when its failure to perform as intended may result in a quality problem that foreseeably compromises safety."
- Determine the assurance activities. Set the rigor of testing according to that risk.
- Establish the appropriate record. Capture enough objective evidence to show the software performs as intended, and no more.
The guidance gives examples of each risk level. Automating process parameter control, or deciding product acceptability without human review, can be high process risk. Collecting monitoring data, routing CAPAs or automating existing calculations are examples of functions that are not.
FDA notes that risk sits on a spectrum. For assurance purposes, though, the guidance uses the two categories: high process risk and not high process risk.
Scripted and unscripted testing
CSV teams often treat robust scripted testing as the default for every function. The CSA guidance lists several options and matches them to risk:
- Robust scripted testing: step-by-step procedures, expected results and, where appropriate, independent review of the test plan.
- Limited scripted testing: fewer test cases, often combined with unscripted testing.
- Scenario (ad hoc) testing: exercising realistic sequences of interactions.
- Error guessing: test cases built from the tester's knowledge of past failures and failure modes.
- Exploratory testing: the tester designs and runs tests on the fly, based on what earlier results show.
High process risk functions may call for more rigorous scripted testing. But the guidance also says unscripted testing "may be better suited to assure the software performs as intended even for high process risk" functions. For some lower-risk functions, unscripted testing "may be all the assurance that is needed."
This is where CSA asks the most of people. Good exploratory testing needs testers who understand the process, the system and how it tends to fail. A tester who only knows how to execute scripts will struggle.
What the examples show
Appendix A of the guidance walks through several systems. Two are useful to compare with a typical CSV package.
In the nonconformance management system example, a commercial off-the-shelf system is assessed through the vendor and its configuration. Functions for starting a nonconformance record are not high process risk and get exploratory testing. The product containment function is high process risk and gets a detailed scripted protocol, including repeatability testing.
In the learning management system example, access control and notifications are tested through error guessing. Record-keeping functions get unscripted "break the system" tests, such as attempting to delete the audit trail.
The pattern is the same throughout. One system, several functions, different levels of rigor. Under a blanket CSV approach, every function in these systems might have received the same scripted treatment.
What the record should contain
CSA does not mean less evidence of thinking. It means less evidence that adds nothing. The guidance recommends that the record capture:
- The intended use of the software, feature or function
- The result of the risk-based analysis
- A description of the testing performed and any issues found
- A conclusion on whether the software is acceptable
- Who performed the testing and when, with review and approval where appropriate
FDA states that documentation "need not include more evidence than necessary." It also recommends digital records, "as opposed to paper documentation, screenshots, or duplicating results already digitally retained by the software." System logs and audit trails can serve as evidence.
For teams that capture screenshots by default, this is a clear basis for revisiting that practice.
Leaning on vendor work
Many production and quality systems are commercial products. The guidance lets manufacturers use vendor evaluations, vendor validation records, installation and configuration activities as part of their assurance. It acknowledges that manufacturers "may have limited access to information from the software vendor."
FDA recommends a risk-based vendor evaluation. The guidance treats onsite audits as optional and lists alternatives such as SOC reports or ISO certifications. Used well, vendor evidence lets your own testing focus on your configuration and your intended use.
What does not change
CSA is not a shortcut around existing rules. A few points stay firm:
- Part 11 still applies. The guidance points to FDA's Part 11 Scope and Application guidance for electronic records and signatures. It notes that the enforcement discretion described there for Part 11 validation requirements "expressly does not apply" to validation of software used as part of production or the quality system.
- Software must stay in a validated state. CSA covers the full life cycle, so changes, upgrades and periodic review still need risk-based assurance.
- Decisions must be documented. The guidance asks manufacturers to document the intended-use decision and the risk analysis. A risk call that isn't written down won't help during an inspection.
Practical first steps
Moving from CSV to CSA is mostly a change in procedures, templates and skills. Typical first steps:
- Rewrite the SOPs. Validation, risk assessment and testing procedures written for CSV often require scripted testing for everything. They need to allow risk-based choices and say who makes them.
- Build a function-level risk template. Assess intended use and process risk per function, not per system.
- Train testers for unscripted work. Teach exploratory testing and error guessing, and how to record them with the elements listed above.
- Revisit vendor qualification. Define what supplier evidence you will accept for each risk level.
- Pilot on one system. Pick a system with an upcoming change, apply the new approach and adjust before rolling it out.
Results depend on the starting point. In one documented CSA transformation at a global pharmaceutical company, SQA Solution helped cut the validation cycle from 6–8 weeks to 3–4 weeks and reduced documentation by about 40%. Exploratory or unscripted testing rose to 60% of testing, from a fully scripted baseline.
If you want an outside view of where your current procedures stand, a Part 11 and CSA readiness assessment is a practical first step.
Moving from CSV to CSA
CSA asks validation teams to spend their effort where failure would hurt patients or product quality, and to stop spending it where it doesn't. The guidance gives the framework. The work is in procedures, risk decisions and tester skills. SQA Solution's CSA consulting services and CSV to CSA transition program help teams update SOPs, set up risk-based testing and train staff for the change.