FDA computer software assurance (CSA) for production and quality management system software

What does a nonbinding final guidance oblige you to do?

The CSA guidance obliges you to nothing on its own. It is a guidance document, and it says so on every page, each of which is headed "Contains Nonbinding Recommendations". The text states that it "does not establish any rights for any person and is not binding on FDA or the public", and that "should" in its pages means suggested or recommended.

The obligation sits elsewhere. Software used as part of production or the quality management system has to be validated for its intended use, and since the Quality Management System Regulation took effect on 2 February 2026 that requirement reads as ISO 13485:2016 clause 4.1.6, clause 7.5.6 and clause 7.6, incorporated by reference into 21 CFR Part 820. CSA is the method FDA recommends for satisfying it, described in the guidance as a least-burdensome approach "where the burden of validation is no more than necessary to address the risk".

Two things follow for a CEO. A validation programme that already satisfies those three ISO 13485 subclauses does not have to be rebuilt around CSA, because the guidance recommends rather than requires. A programme still written against Section 6 of the 2002 General Principles of Software Validation is quoting a section this guidance replaced: the February 2026 document supersedes Section 6 outright while supplementing the rest of the 2002 guidance. What the enforceable quality system asks of software is covered under ISO 13485 software validation.

The title moved at the same time. The current document is "Computer Software Assurance for Production and Quality Management System Software", issued 3 February 2026 under docket FDA-2022-D-0795. It wholly supersedes the final guidance of 24 September 2025, which was titled "Computer Software Assurance for Production and Quality System Software". Comments may still be filed under the docket at any time, so the text can move again.

Which of your software does this cover?

Step 1 of the framework sorts software by how it is used, and the sort decides whether the validation requirement applies at all.

FDA Computer Software Assurance guidance: how software is used in production or the QMS, with examples, and whether the validation requirement applies.

How the software is used	Examples from the guidance	Validation requirement
Directly as part of production or the QMS	Automating production processes, inspection, testing, or the collection and processing of production data; automating QMS processes or maintaining a quality record	Applies
To support production or the QMS	Development tools that test or monitor software systems or automate testing activities, including firmware embedded in production equipment; general record keeping that is not part of the quality record	Applies, with effort often reduced because the risk is lower
Not as part of production or the QMS	Email, accounting, networking, user authentication, backup and restore	Does not apply

The sort is done per feature, function or operation, because one system can hold several intended uses at once. The guidance works the point through a spreadsheet: used for basic input of time and temperature readings it is low process risk, and the same spreadsheet with custom formulas used directly in production may need additional validation. FDA recommends documenting the decision-making process itself, alongside its outcome.

Section III draws the other boundary: the guidance does not cover design and development verification or validation for device software functions, meaning software that meets the device definition under section 201(h) of the FD&C Act. That testing is described under software as a medical device instead.

What decides how much testing a feature gets?

One sentence in Section V.A(2) carries the framework: "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." The trigger is the consequence of a failure, rather than the fact that the software touches product.

Features the guidance names as generally high process risk:

• Maintain process parameters, such as temperature, pressure or humidity, that affect the physical properties of product or of manufacturing processes identified as essential to device safety
• Measure, inspect, analyse or determine acceptability of product or process with limited or no additional human awareness or review
• Perform process corrections or adjustments based on data monitoring or automated feedback from other process steps, without additional human awareness or review
• Produce instructions for use or other labelling for patients and users that are necessary for safe operation of the device
• Automate surveillance, trending or tracking of data the manufacturer identifies as essential to device safety, cybersecurity included, and quality

Features named as generally not high process risk include CAPA routing, automated complaint logging, change control management, procedure management, data collection for monitoring and review with no direct impact on process performance, and everything in the supporting category above.

Two worked examples in the guidance separate the categories better than the definition does. An ERP restocking feature where a qualified person checks the materials before use is intermediate risk, not high. The same feature where the software performs the check and no person repeats it is high process risk. Human review inside the loop is what moves the classification, which is also what makes a classification stale the moment somebody automates a manual approval.

The guidance presents the classification as binary while acknowledging that risk is a spectrum. A moderate, intermediate or low rating is allowed, and each falls under the not-high provisions. FDA states it is "primarily concerned with the review and assurance for those software features, functions, and operations that are high process risk". Where the rating is high, the assurance level follows the medical device risk; where it is not high, the rigour follows the process risk.

Which testing methods does FDA name, and how do they nest?

The guidance takes its definitions from IEC/IEEE/ISO 29119-1:2022 and hangs them on two branches. Unscripted testing is "dynamic testing in which the tester's actions are not prescribed by written instructions in a test case". Scripted testing is testing in which test cases are recorded, then executed manually or by an automated tool.

A summary offering five flat "CSA testing types" has flattened that hierarchy, usually by promoting ad-hoc testing to a method of its own. The nesting decides what you have to write down, because Table 1 assigns evidence by branch: scenario testing and error guessing carry no test plan, while exploratory testing carries high level objectives with pass or fail criteria for each objective.

The mapping from risk to method is a default. For high process risk the guidance suggests scripted testing or a hybrid of scripted and unscripted, scaled as appropriate; for not high process risk it suggests scenario testing, error guessing, exploratory testing or a combination. FDA then states that "the testing examples discussed for high process risk and not high process risk are not exclusive to those categories": unscripted methods can suit a high-risk feature, and automated scripted testing can be the cheaper option for a low-risk one. The list of methods is expressly not exhaustive. What that permission costs in practice, and where a CSV-era protocol library still earns its keep, is worked through in CSA compared with CSV. Running automated scripts inside a system that is itself validated is covered in test automation in a validated environment.

What record will an investigator ask for?

The guidance recommends six record elements for every assurance activity, whichever method produced it. It asks the manufacturer to "capture sufficient objective evidence to demonstrate that the software feature, function, or operation was assessed and performs as intended", then lists what that evidence contains.

FDA writes that documentation "need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified", and recommends keeping enough detail "to serve as a baseline for improvements or as a reference point if issues occur". Table 1 keeps the same record elements on every row, unscripted rows included, and shrinks the test plan column instead.

FDA Computer Software Assurance record elements per assurance activity, from robust scripted testing to exploratory testing, with the test plan and results each requires.

Assurance activity	Test plan	Test results
Scripted testing, robust	Test objectives, step-by-step test cases, expected results, independent review and approval where appropriate	Detailed report of testing performed
Scripted testing, limited	Limited test cases, expected results, identification of the unscripted testing applied	Summary description of testing performed
Unscripted, scenario testing	None	Summary description of testing performed
Unscripted, error guessing	None	Summary description of testing performed
Unscripted, exploratory testing	High level objectives with pass or fail criteria for each objective, no step-by-step procedure	Summary description of testing performed

FDA also asks for the evidence in the form the system already holds it, recommending system logs, audit trails and other data generated and maintained by the software over paper documentation, screenshots, or duplicates of results the software already retains. Accuracy, reliability, integrity, availability and authenticity of those digital records become part of the risk-based approach, which is what audit trail testing is for. The guidance refers record retention to ISO 13485 clause 4.2.5.

Software changes carry a reporting consequence for approved PMAs and HDEs. A change to production or quality management system software that may result in a quality problem foreseeably compromising safety belongs in a 30-day notice; one that would not may be appropriate for the annual report. The guidance contrasts a manufacturing execution system that manages workflow and alerts with one that automatically controls and adjusts critical production parameters such as temperature, pressure and process time.

Where does the guidance stop helping?

The CSA guidance stops at Appendix A, which carries four worked examples: a configured COTS nonconformance management system, a learning management system, business intelligence applications, and a SaaS product life cycle management system. All four are quality management and enterprise software.

None of them is production line control. The features the guidance itself calls generally high process risk, a controller that maintains a process parameter such as temperature, or an inspection station that determines acceptability with no human review, have no worked example anywhere in the document. A team validating one of those builds the argument from the five bullets of Section V.A(2) and nothing else the guidance offers.

Where does a CSA implementation go wrong?

• The intended use and the risk are recorded once per system, so a single high-risk function drags an entire platform to robust scripted testing, or disappears inside an average. The guidance asks for the analysis per feature, function and operation.
• Unscripted testing runs and its record stops at a summary, with no conclusion of acceptability, no named tester and no date. Table 1 asks for those on the unscripted rows too.
• The supplier file holds a SOC report and an ISO certificate with no assessment of either against the manufacturer's own supplier evaluation procedure, which is the shape Example 1 of Appendix A demonstrates.
• Screenshots are pasted into a protocol to duplicate results the system already retains in its audit trail.
• A classification made while a person checks the output stays in the file after that check is automated away.
• The validation procedure cites 21 CFR 820.70(i), removed by the QMSR on 2 February 2026, or the guidance titled "Quality System Software", superseded on 3 February 2026.

What do we run against the CSA guidance?

We start where the guidance starts: an inventory of features, functions and operations with the intended use written against each, then the process risk determination, then the assurance activity, then the record. The classification drives everything downstream, so the argument for each rating is written before any testing is planned, and it is the artefact we expect to be challenged on.

For features that come out high, the testing is scripted and traceable, with the evidence pulled from the system's own logs wherever they hold it. For the rest, we run scenario testing and experience-based sessions against written objectives with pass or fail criteria, and each session record carries the six elements above, so a lighter method does not leave a lighter file. Where an outside team touches systems that hold PHI, the access terms and the BAA and PHI handling are settled before the first session.

Dates, clause numbers and quotations on this page were checked against the FDA guidance Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026.