Computer Software Assurance vs CSV: What Changed

Last updated August 2026. Computer software assurance is the FDA's risk-based approach to establishing confidence that software used in production or the quality management system performs as intended. It replaces the habit of testing every function to the same depth with a model that concentrates effort where a failure could affect product quality or patient safety. The FDA issued an updated final guidance on February 3, 2026, superseding the final version of September 24, 2025 and aligning the document to the new Quality Management System Regulation. CSA is a change of emphasis, not a change of law.

That last point is the one teams get wrong in both directions. Some read CSA as permission to stop validating. Others read it as a new regulation they have to implement by a deadline. Neither is right, and the gap between them is where a lot of wasted money sits. This guide covers what the guidance actually says, how CSA differs from traditional computer system validation in practice, how to decide the assurance effort a given system needs, and the 21 CFR Part 11 trap sitting in the middle of it.

What is computer software assurance?

Computer software assurance is a risk-based method for deciding how much testing and documentation a piece of software needs before you rely on it. Instead of treating a label printer, a spreadsheet and a manufacturing execution system as equivalent, you ask what happens if the software fails, and you spend your assurance effort in proportion to that answer. The FDA's framing is that assurance effort should be driven by intended use and process risk.

The scope matters and is narrower than most people assume. The guidance addresses software used in production or in the quality management system: things like equipment control, automated inspection, calibration tracking, document control, training records and complaint handling. It is not guidance about software in a medical device itself. Device software has its own premarket expectations and a separate guidance family.

What changed in the February 2026 CSA guidance?

The substance of CSA has been stable since the 2022 draft. What changed on February 3, 2026 is alignment. The FDA reissued the guidance under a new title, Computer Software Assurance for Production and Quality Management System Software, to match the QMSR vocabulary, and added material on when 21 CFR Part 11 electronic record requirements apply.

The timing is not a coincidence. The QMSR took effect on February 2, 2026, amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. The CSA guidance was reissued the following day so the two documents would speak the same language. If you are working from a copy of the guidance dated 2022 or September 2025, the model you are applying is still broadly correct, but the terminology and the Part 11 section have moved.

Computer software assurance vs computer system validation

The honest version of this comparison is that CSA is not a replacement technology. It is the same regulatory obligation, approached with a different default. Traditional computer system validation drifted toward uniform, heavily scripted testing with extensive screenshot evidence, largely because that felt defensible in an inspection. CSA says that effort spent proving a low-risk function works is effort not spent on the function that could hurt someone.

One caution about that table. It compares CSA to CSV as commonly practised, not to what the underlying rules ever required. Nothing in 21 CFR 820 ever demanded uniform scripted testing. The documentation habit grew up around the regulation rather than out of it, which is why the FDA can shift the expectation through guidance without amending anything.

Does computer software assurance replace validation?

No. Validation remains a requirement, and CSA is a method for satisfying it proportionately. The obligation for production and quality system software sits in 21 CFR 820.70(i), which requires validation of software used as part of production or the quality system according to an established protocol. CSA tells you how to size that work. It does not remove it.

This is worth stating plainly because the enforcement discretion story around Part 11 gets tangled up with it, which brings us to the trap.

Does CSA change anything about 21 CFR Part 11?

It clarifies a misreading that has been circulating for two decades. In its August 2003 scope and application guidance, the FDA said it intends to exercise enforcement discretion over four areas of Part 11: validation, audit trails, record retention and record copying. Teams have repeatedly read that as "we do not have to validate."

The FDA's position, restated in the CSA guidance, is that enforcement discretion over the Part 11 validation clause does not relieve you of the validation requirement in the predicate rule. If software is used as part of production or the quality management system, 820.70(i) requires validation regardless of what the FDA is choosing not to enforce under Part 11. The discretion narrows one route to a finding. It does not remove the underlying duty.

The same distinction runs through the rest of Part 11. Enforcement discretion covers four requirements. Access controls, authority checks, training records, written accountability policies and the whole electronic signature subpart are enforced as written, and they are ordinary controls work rather than validation work. We keep a clause-by-clause breakdown of which is which on the 21 CFR Part 11 compliance software page, including the rows where the honest answer is that a controls platform is not what covers it.

How do you decide how much assurance a system needs?

The guidance works through two questions in order, and the order is the part people skip.

First, is the software used directly as part of production or the quality system, or does it support those processes indirectly? Direct use means the software's failure could affect the product or the record itself. Indirect use means a failure would be caught by something downstream before it reached the product.

Second, for direct-use software, could a failure compromise product quality or patient safety? If yes, it is a high-process-risk function and it earns scripted, documented testing. If no, lighter assurance activity is appropriate, and unscripted testing is explicitly acceptable.

Two practical notes. The assessment is per function, not per system, and that is where most of the savings live. A quality management platform might have one high-risk function around electronic batch release and thirty low-risk ones around reporting and search. Assessing the platform as a single high-risk object is the expensive mistake. Second, the assessment is a judgement you have to be able to defend, so write down the reasoning rather than just the conclusion. An inspector who disagrees with a rating will still respect a documented rationale far more than a bare score.

What is critical thinking in the CSA guidance?

Critical thinking is the FDA's term for expecting a human to reason about risk rather than follow a checklist. It appears throughout the guidance as the thing that decides testing depth, evidence sufficiency and whether supplier activities can be leveraged. It is genuinely the load-bearing concept, and it is also the hardest to operationalize, because a documented rationale is harder to produce than a filled-in template.

In practice it means someone qualified writes down why this function is low risk, why this vendor's testing is credible, and why this evidence is sufficient. That short paragraph is what turns a lighter approach into a defensible one.

What testing does CSA accept?

Four kinds, and the guidance treats them as a toolkit rather than a hierarchy. Scripted testing follows pre-approved step-by-step cases with expected results. Robust scripted testing adds boundary, error and stress conditions and is reserved for the highest-risk functions. Unscripted testing covers exploratory and ad hoc work where a tester exercises the function knowledgeably without a pre-written script. Error-guessing testing deliberately probes where a tester expects the software to break.

The evidence expectation drops with the risk. For unscripted testing the guidance is satisfied by a record of what was tested, who tested it, the date, and the outcome, including issues found. That is a meaningful reduction from the screenshot packs many teams still assemble. Automated test output counts, and for teams running large regression suites the practical shift is toward letting tooling generate and execute the test cases and keeping the tool's log as the record, rather than having an analyst reproduce each step by hand.

Which systems are actually in scope?

Scope questions cause more delay than the testing does. The guidance covers software used in production or as part of the quality management system. That typically pulls in equipment and process control software, automated inspection and test systems, calibration and maintenance tracking, document and change control, training records, complaint handling, CAPA and nonconformance systems, and electronic batch records.

It typically does not pull in general business software with no quality system role, such as finance, sales or HR platforms, and it does not cover software in the device itself. If a system holds a record a predicate rule requires, Part 11 may still reach it even where CSA does not, which is why the two scoping exercises need to be run separately rather than merged into one spreadsheet.

What should a quality team do next?

Start by re-reading your validation SOP against the current guidance. Most SOPs written before 2022 mandate uniform scripted testing by policy, which means your own procedure, not the FDA, is what forces the heavy approach. Until that document changes, an inspector will hold you to it, because you wrote it.

Then take your system inventory and split it by function rather than by application, rate each function on the two questions above, and record the rationale. Expect the high-risk list to be short. Where the risk is low, move to unscripted testing and lighter evidence, and where you rely on supplier testing, document the assessment that makes that reliance reasonable.

The controls half of this, meaning who has access, whether the audit trail is on and reviewed, whether training is current and whether the leaver was removed, is not validation work at all and should not be sitting in your validation protocols. It is the same access, change and training evidence a SOC 2 programme already produces, and running it once against every framework you carry is how life sciences teams stop paying for the same evidence three times. Our guide to the user access review process covers the review that sits behind 11.10(d) and 11.10(g), and IT general controls covers the wider access, change and operations set an auditor samples.

None of this is a deadline. There is no CSA compliance date, no certification, and no filing. It is a better-calibrated way of meeting an obligation you already had, and the main risk in ignoring it is that you keep paying for assurance you do not need while the function that could actually hurt somebody gets the same two hours as the label printer.