Computer Software Assurance (CSA): The FDA Guidance Explained

What CSA is, in one paragraph

The guidance defines computer software assurance as a risk-based approach for establishing and maintaining confidence that software is fit for its intended use. It looks at the risk to device safety or quality if the software fails to perform as intended, and uses that risk to set the level of assurance effort. It also expects the software to stay in a state of control, which it calls the validated state, for its whole life cycle.

In practice that means four decisions per feature: what it is used for, how risky a failure would be, which assurance activities fit that risk, and what record proves the activities were done.

Scope: who the CSA guidance applies to

The guidance covers computers and automated data processing systems used as part of medical device production or the quality management system. The legal basis is 21 CFR Part 820, the Quality Management System Regulation (QMSR), which took effect on 2 February 2026 and incorporates ISO 13485:2016 by reference. The February 2026 revision was issued to align the guidance with the QMSR.

It supplements the FDA's "General Principles of Software Validation" and supersedes only Section 6 of that guidance, the section on validating automated process equipment and quality system software. It does not cover device software functions, meaning software that is itself a medical device.

For drug and biologic manufacturing, the validation duty comes from the drug CGMP rules (for example 21 CFR 211.68) and from 21 CFR Part 11, not from this guidance. Many pharmaceutical and biotech quality teams still apply CSA's reasoning to their own computerised systems, because it matches the risk-based, critical-thinking approach of GAMP 5 Second Edition, which the guidance itself points to as a resource. If you do that, say in your validation procedure that you are applying the approach, and why.

The CSA risk framework, step by step

Section V of the guidance sets out a framework in six parts. These are the steps a validation plan written under CSA should follow.

High process risk and not high process risk

This is the decision the whole approach turns on. Under the guidance, a feature is high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety. The guidance is clear that this step looks at the process, not at the device risk to the patient.

Its examples of features that are generally high process risk include software that:

• maintains process parameters, such as temperature, pressure or humidity, that affect product properties essential to device safety;
• measures, inspects, analyses or decides whether product or process is acceptable, with limited or no human review;
• corrects or adjusts process parameters from monitoring data or automated feedback, without additional human review;
• produces instructions for use or other labelling provided to patients and users.

Its examples of features that are generally not high process risk include software that collects and records process data for monitoring without directly affecting production; quality-system tools for CAPA routing, complaint logging, change control or procedure management; and software that manages data, automates an existing calculation, increases monitoring or raises alerts. The guidance adds that risk sits on a spectrum and that you should assess each feature, function or operation, not just the system as a whole.

The practical consequence is that most of a typical eQMS, learning management system or reporting tool falls on the lower side, while the parts that decide product acceptability or control a process do not. One system can contain both.

Assurance activities: scripted and unscripted testing

The guidance describes several kinds of testing and what each record should contain. For high process risk features, manufacturers may use scripted testing, or a mix of scripted and unscripted testing, scaled to the risk. For features that are not high process risk, they may use unscripted methods such as scenario testing, error guessing or exploratory testing.

Every method still records the intended use, the risk result, the issues found, a conclusion on acceptability and who tested and when. The guidance also says the categories are not rigid: unscripted testing may suit a high-risk feature, and scripted, automated testing may be the more efficient choice for a low-risk one. Unscripted testing under CSA covers how to run and document these methods so they hold up.

Taking credit for the vendor and for other controls

Section V.A(5) lets you reduce your own testing where other controls already lower the impact of a failure. Two are especially useful.

The first is purchasing controls over the software vendor. The guidance says a manufacturer can use the vendor's development practices, validation work and electronic information as the starting point and decide what else is needed, and that for some lower-risk features this may be all the assurance required. That only works if you have actually assessed the vendor and recorded why its evidence is adequate for your use. supplier qualification is where that assessment gets done properly.

The second is process control. If a process is fully understood, its critical parameters are monitored, or every output is verified downstream, a software failure is caught before it matters, and the assurance needed from the software itself goes down.

The record CSA expects

The guidance recommends that the record of assurance include:

• the intended use of the feature, function or operation;
• the result of the risk-based analysis;
• a description of the testing done, the issues found (deviations, defects, failures) and a conclusion that the software is acceptable for its intended use, including how issues were resolved or why they do not affect that use;
• who performed the testing or assessment, and when;
• review and approval where appropriate, for example a dated signature by someone with signatory authority.

It also says the documentation "need not include more evidence than necessary" for the risk, and encourages digital retention of results, automated traceability, automated testing and electronic capture of the work as objective evidence instead of paper. That is the strongest signal in the document: the FDA expects a lean record, made electronically, that explains why the effort was right.

CSA and 21 CFR Part 11

CSA does not change Part 11. Section V.B of the guidance tells manufacturers to use the FDA's "Part 11, Electronic Records; Electronic Signatures: Scope and Application" guidance when deciding whether and how Part 11 applies to production and quality system software. Part 11 still sets the conditions under which electronic records and signatures are trusted as equivalent to paper. Our 21 CFR Part 11 page and the 21 CFR Part 11 guide go through those controls section by section.

The four worked examples in Appendix A

Appendix A applies the framework to four systems, and they are worth reading in full because they show the reasoning, not just the answer:

• a nonconformance management system;
• a learning management system (LMS);
• business intelligence applications;
• a software as a service (SaaS) product life cycle management (PLM) system.

Each example identifies the intended use, splits the system into features with different risk levels, and picks different assurance activities for each. They are a good template for a CSA validation plan, because they show one system getting both scripted and unscripted testing.

CSV vs CSA: what actually changes

Computer System Validation (CSV) is the obligation and the lifecycle: requirements, risk, testing, traceability, release and periodic review. CSA is a way of meeting that obligation that puts the effort where the risk is. What changes in practice is the default. Under a traditional CSV procedure the default is a scripted test for every requirement; under CSA the default is a recorded risk decision per feature, and the test method follows from it.

What does not change is the need for a plan, traceability, controlled changes and an inspectable record. Our CSV vs CSA comparison is the short version, the computer system validation guide covers the full lifecycle, and The CSV to CSA transition plan sets out how to move a team across.

How to start using CSA on your next system

• Update the validation procedure so it allows unscripted methods and vendor evidence, and says how each is recorded.
• For the next system, list its features and record the intended use and a high or not-high process risk decision for each, with the reason.
• Pick the assurance activity per feature from that decision, and take credit for vendor evidence only after a documented supplier assessment.
• Keep the record electronic: results, evidence and traceability captured as the work happens.
• Compare the effort with your last comparable project. One real number persuades a quality leadership team faster than any argument. Defending CSA to an inspector covers the questions an inspector is likely to ask.

Cybroscape GxP Copilot is built this way: risk is assessed per requirement, the test approach (scripted, unscripted or vendor evidence) follows from it, and the record and the Live RTM are generated as the work is done. You can run a project in CSA or traditional CSV mode. Our CSA services team can also run a first CSA re-baseline with you.