CSA vs CSV: what FDA computer software assurance changes and what it leaves in place

Does CSA actually mean less paperwork?

One column of the file gets shorter and the rest does not. FDA's computer software assurance guidance describes a risk-based approach in which "the burden of validation is no more than necessary to address the risk", and Table 1 of the guidance is where that sentence turns into something you can price. Read the table across its five activity rows and the record column holds the same items on every one of them. The column that changes is the test plan.

Scenario testing and error guessing carry no test plan. Exploratory testing carries high level objectives with pass or fail criteria for each objective and no step-by-step procedure. Robust scripted testing keeps its objectives, its step-by-step cases, its expected results and its independent review. What none of the five rows drops is the intended use, the risk result, the description of what was tested, the issues found, the conclusion of acceptability and the name and date of whoever did it. The full taxonomy and the table row by row are set out under FDA computer software assurance.

The saving therefore lands before the testing and not after it. Writing step-by-step scripts for a feature whose failure would not foreseeably compromise safety is the expense the guidance is aimed at. Assembling the record that an investigator reads is not, and FDA asks for enough detail in it "to serve as a baseline for improvements or as a reference point if issues occur". A vendor proposal that quotes a smaller documentation number without saying which column it came out of has not told you what you are buying.

Which of your software does each name reach?

CSV, as a practice, reaches whatever your own procedure said it reached. The guidance draws its own boundary in Section III, and it is narrower than most procedures. It covers computers and automated data processing systems used as part of production, or as part of the quality management system, for medical devices. It excludes device software functions by name, meaning the software functions that meet the device definition under section 201(h) of the FD&C Act, and offers no recommendation at all on their design and development verification or validation.

For a company whose product is software as a medical device, that boundary decides which of two conversations you are in. The risk-based framing belongs to the systems behind the product: the quality management system, the tooling around release, the equipment on the line. Applying it to the device software itself scopes the product under a document whose own scope section excludes it.

The schedule for adopting the newer approach is therefore yours to set, and the argument for setting it slowly is on the record. The current text already wholly supersedes a final guidance of the same programme issued on 24 September 2025, and comments may be filed under docket FDA-2022-D-0795 at any time. A quality system rebuilt around the exact wording of one revision will eventually meet another. What the enforceable quality system asks of software, independently of any guidance, is covered under ISO 13485 software validation.

What can you stop doing, and what can you never stop doing?

What FDA's Computer Software Assurance guidance lets a manufacturer drop from validation, set against the records every testing method still has to produce.

What a risk-based approach lets you drop	What stays behind every method
Step-by-step cases for scenario testing and error guessing, the two Table 1 rows that carry no test plan	The intended use of the feature, function or operation, decided before the testing is chosen
The per-step procedure for an exploratory session, which carries high level objectives with pass or fail criteria instead	The result of the risk-based analysis, with the reasoning FDA recommends you document alongside the outcome
Screenshots duplicating results the software already retains, in favour of system logs and audit trails FDA names as the least-burdensome record	A description of the testing conducted and the deviations, defects and failures it found
Repeating validation your vendor already performed, where purchasing controls and the vendor's own practices are assessed; for some lower risk items the guidance says this may be all the assurance needed	A conclusion declaring the software acceptable for its intended use, with each issue resolved or justified
Uniform rigour at every stage of the life cycle, which is how the guidance describes what validation has often been	The individual who performed the work, the date, and review and approval where that applies

The right column does not know which method produced it. An exploratory session and a robust scripted run end in the same six items, and only one of them arrives there with a script to copy from. Assembling those items so a reader can walk them without a guided tour is validation documentation.

One expectation about electronic records survives the switch untouched. The guidance states that the enforcement discretion described in FDA's Part 11 Scope and Application guidance "expressly does not apply to validation requirements for computer software used as part of production or the quality management system arising under Subclauses 4.1.6, 7.5.6, and 7.6 of ISO 13485". A record held electronically and needed as evidence of the validated state is generally an electronic record, with the controls that follow from that, described under 21 CFR Part 11 validation testing.

Who inside the company now carries a judgement they did not carry before?

Whoever signs the risk determination, and that is rarely the person who used to sign the protocol. The guidance turns on one sentence: "FDA considers a software feature, function, or operation to pose a high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning a medical device risk." Under a scripted programme the size of the effort was settled by the procedure. Under this one it is settled by an argument someone writes about a specific feature, and FDA recommends documenting the decision-making process itself and not only its outcome.

Three properties of that judgement change who is exposed by it.

• It is made per feature, function or operation. One platform can hold several intended uses at once, so the signature is not on a system name; it is on a list of behaviours somebody had to enumerate first.
• It is presented as binary. The guidance acknowledges that risk is a spectrum and allows a moderate, intermediate or low rating, and every one of those falls under the not-high provisions. The file therefore records a decision that reads as absolute even where the analysis behind it was graded.
• It expires without anyone touching the file. The guidance separates an ERP restocking feature where a qualified person checks the materials, which is intermediate, from the same feature where the software performs the check and no person repeats it, which is high process risk. Human review inside the loop is the difference. Any automation project that removes a manual approval moves the classification, and nothing in the deployment pipeline knows that.

For a chief executive the exposure is concrete. The artefact an investigator challenges first is now a written opinion about foreseeable harm, produced by an engineer or a quality lead, in a document your company signed. Selecting a partner who will put their reasoning in that document, and who will be there to defend the wording, is a different purchase from buying test execution: FDA software validation sets out the artefacts that decision produces.

How does a team adopt the newer approach and end up with weaker evidence?

By dropping the script and the record together, which is easy to do because they used to be the same document. Five routes lead to a thinner file, and each of them is visible in the guidance's own text.

• The risk determination is made once per system, so a single high-risk function is averaged away inside a platform rated low. The analysis is asked for per feature, function and operation.
• An exploratory session runs with nothing written first, so the file holds a summary of what was found and no statement of what the session set out to falsify. The exploratory row expects objectives with pass or fail criteria for each objective.
• "Least burdensome" is read as a scope decision. The sort in the first step of the framework keeps software used to support production or the quality management system inside the requirement, with the effort often reduced because the risk is lower.
• The method is chosen from the label instead of from the feature. FDA states that "the testing examples discussed for high process risk and not high process risk are not exclusive to those categories", so an unscripted method can suit a high-risk feature and automated scripted testing can be the cheaper route for a low-risk one.
• A vendor's certificate is filed as the assurance, with no record of it being judged against your own supplier evaluation procedure. That judgement is the part the guidance's worked example spends its space on.

The fourth of those costs money in both directions. Where an automated suite already exists, running it against a low-risk feature is often cheaper than a manual session, and the guidance does not stop you; the qualification the suite itself needs is covered in test automation in a validated environment.

Sources for this page. Every date, quotation, section number and table detail above was read from the FDA guidance Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 under docket FDA-2022-D-0795, and checked on 2 September 2026. The ISO 13485 subclause numbers and the effective date of the Quality Management System Regulation are as cited in that guidance. CSA is a guidance document and not a rule: every page of the source is headed "Contains Nonbinding Recommendations".

What does the switch cost to run?

Three things have to exist before a method changes, and each of them is work somebody has to be paid for. The first is an inventory of features, functions and operations, because a per-feature judgement cannot be made against a list of installed systems. The second is the written risk argument for each item, produced before any testing is planned, because the size of the effort is later justified against it. The third is the record template that every assurance activity ends in, which is what stops a lighter method producing a lighter file.

Unscripted work raises one question a scripted programme could postpone. An exploratory session is a person moving through the live screens of a quality system, and a complaint or nonconformance record on those screens can carry patient information. We do not need production PHI to test. Environments run on synthetic and de-identified data. Where a test genuinely needs a real-world shape, the route to it is agreed in writing before an environment exists, and de-identification is verified rather than assumed. The rest of what an outside team is asked before it touches such a system is answered at how we work with protected health information.

None of that work moves the regulatory position for a device you place on the market, which stays with you whichever assurance method you adopt. What an outside team can hand over is the intended use, the risk argument and the assurance record for each item, written so an investigator can read them in that order.