Computer Software Assurance Is Device Guidance — Cite It for a Drug System and Fail

FDA issued a new version of Computer Software Assurance for Production and Quality Management System Software on 3 February 2026, superseding the final guidance of 24 September 2025. The reissue is genuinely useful: it adds a definitions section, addresses cloud service models directly, and states that its risk framework "can be applied, but is not limited, to automation tools (e.g., BOTS or automatic workflows), data analytic tools, artificial intelligence/machine learning tools, and cloud computing when used as part of production or the quality management system."

It is the only FDA text that says in plain words that a risk-based, least-burdensome approach applies to AI tools in a quality system. So it gets pasted into validation plans for LIMS, eQMS, eTMF and deviation-triage systems at drug sponsors that have never made a device.

The scope section did not move. It reads: "This guidance provides recommendations regarding computer software assurance for computers or automated data processing systems used as part of production or the quality management system for medical devices." The obligations it interprets are ISO 13485 subclauses 4.1.6, 7.5.6 and 7.6, incorporated by reference into 21 CFR Part 820 by the Quality Management System Regulation, which took effect on 2 February 2026 — the day before the guidance was reissued. Searching the full 41-page PDF at fda.gov/media/188844/download on 30 August 2026 returns zero occurrences of "pharmaceutical", zero of "CGMP", zero of "Part 211" and zero of "clinical". The word "drug" appears eight times, every one of them inside the name of an agency, an office or the Federal Food, Drug, and Cosmetic Act.

What the February 2026 reissue actually changed

The changes are real, and all of them sit inside the device world.

Two details deserve quoting rather than summarising. Footnote 14 states that "cloud computing used as part of production or the quality management system, including when supporting associated recordkeeping and manufacturing activities, is within the scope of this guidance", while cloud used as part of device software functions is not. And the guidance now says explicitly that the enforcement-discretion policy in FDA's 2003 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".

That second point is the sharpest thing in the document and the one most likely to be misquoted at a drug company. It closes a discretion for device manufacturers. It does not open or close anything for you.

Does CSA apply to pharma?

No, with one specific exception that most articles miss.

The general answer follows from scope. CSA interprets device quality management system obligations. A drug sponsor's computerised system obligations do not arise there. They arise from 21 CFR 211.68 for manufacturing, from Part 11 for electronic records under any predicate rule, and in Europe from Annex 11. Citing a CDRH and CBER guidance as your authority for a Veeva Vault configuration or a batch-record system tells a QA reviewer that nobody on the project checked which regulation applies to the product.

The exception is combination products. Under 21 CFR 4.4(b)(1), a manufacturer whose operating system complies with drug CGMP may use the streamlined approach, in which case the QMSR final rule of 2 February 2024 rewrote the additional device requirements as ISO 13485 clauses. The first item now reads: "General requirements and management responsibility. Clause 4.1, Clause 5 and its subclauses, Clause 6.1 of ISO 13485, and Sec. 820.10 of this chapter."

Clause 4.1 includes 4.1.6, the requirement to document procedures for validating computer software used in the quality management system, proportionate to risk. So a prefilled-syringe or autoinjector operation running a drug-CGMP-based streamlined quality system is, for that product's quality management system software, inside exactly the obligation CSA interprets. That is the one place where a company that thinks of itself as a drug maker can cite CSA on point — and it is worth knowing which of your sites are in it before someone else discovers it during an inspection.

What binds a drug sponsor instead

State the instrument, the clause and the status. The honest map on 30 August 2026:

Note the asymmetry. FDA guidance documents, CSA included, state on their own title page that they "do not establish any rights for any person and [are] not binding on FDA or the public". EU annexes are part of the GMP guide and inspectors cite them as expectations. A draft annex is neither. If your validation plan quotes draft Annex 22 as a requirement, you have made the same category error in the other direction — an error worth avoiding for the same reason, and one this site works through clause by clause in the reading of draft Annex 22.

What inspectors actually cite at a drug site

Not CSA. On 10 April 2026 FDA issued a warning letter to Fareva Amboise in France, following an inspection of 8 to 16 September 2025. Violation 3 is cited under 21 CFR 211.68(b): the firm "failed to exercise appropriate controls over computer or related systems to assure that only authorized personnel institute changes in master production and control records, or other records", and did not maintain a backup file of data.

The facts underneath are ordinary. Operators on particle counters in classified areas could modify system dates, adjust alarm limits and change access settings without restriction; network user authentication was not enforced. Electronic data on those counters showed multiple Grade A action-limit exceedances for which no original printed record could be produced, with only conforming retest results retained in batch records. A vendor calibration deleted all electronic data beforehand and there was no backup.

None of that needs a new framework to diagnose. It needs access control, audit trail, retention and a quality unit that reviews the raw data. That is 211.68 and Part 11, and it is what a 483 will be written against whatever methodology your validation plan names on its cover.

The boundary does move, in 2027

The interesting part of the reissue is a footnote. The February 2026 guidance was "prepared by the Center for Devices and Radiological Health (CDRH) and the Center for Biologics Evaluation and Research (CBER) in consultation with the Center for Drug Evaluation and Research (CDER), Office of Combination Products (OCP), and Office of Inspections and Investigations (OII)". CDER was in the room.

Five months later, CDER's guidance agenda dated July 2026 lists exactly one item under the category Artificial Intelligence: "Computer Software Assurance for AI-Based Systems in Drug Manufacturing and Clinical Investigations; Supplemental Guidance". RAPS reported the addition on 16 July 2026 among 85 planned documents across 14 categories.

Three things follow. First, the drug-side extension of CSA thinking is now an FDA intention on the record, not a consultant's inference. Second, it is supplemental to a device text, which hints at the shape of the eventual document: method transplanted, obligations left where they are. Third, and least convenient for planning, the agenda carries its own disclaimer that "CDER is not bound by this list of topics nor required to issue every guidance document on this list", and gives no date. When it lands it will land as a draft, open for comment, nonbinding for a year or more after that. Anyone selling you 2027 CSA compliance for drug systems is selling a draft.

The pattern to expect is the one already visible across FDA's drug-side AI work, where a context-of-use and credibility approach does the work that scripted protocols used to do — the same logic as the seven-step credibility framework and its scope limits.

Borrowing the method without borrowing the authority

None of this means abandoning CSA thinking. CSA versus CSV is an argument about method, not about jurisdiction, and the method travels freely. The authority does not, and getting that citation chain right is the difference between a plan that survives a QA challenge and one that does not.

The method you want — risk-based rigour, unscripted and exploratory testing where process risk is low, using supplier and cloud-provider evidence rather than re-testing it, a lean record of assurance instead of a scripted protocol mountain — is fully available to a drug sponsor through GAMP 5 Second Edition, published by ISPE in July 2022, which formalised critical thinking in Appendix M12 and expanded its appendices to cover AI/ML, cloud computing and open-source software. GAMP 5 is not law either, but it is the reference that European and US inspectors expect to see, and it is written for your regulations rather than someone else's.

So the sentence in your validation plan is not "per FDA CSA guidance we applied unscripted testing". It is "the validation requirement arises under 21 CFR 211.68(b) and Annex 11 clause 4; rigour was scaled using GAMP 5 Second Edition critical thinking; the approach is consistent with the risk-based direction of FDA's Computer Software Assurance guidance for devices". The second version answers the question the inspector is actually going to ask, which is which rule you satisfied.

For an AI component the additional layer is the one nobody inherits from CSA at all: intended use and context of use, independent test data, pre-defined acceptance criteria, human oversight design and production monitoring. That layer is set out in the ISPE GAMP Guide: Artificial Intelligence of July 2025 and, for anything non-deterministic, has to be built rather than borrowed — the problem worked through in validating a non-deterministic LLM honestly.

What this means in practice

On Monday, do four things.

Search your validation library for the string "Computer Software Assurance" and read every hit. Where it appears as the stated basis for a drug or clinical system, replace the authority line with the predicate rule and keep the method. That is a controlled document update with a short justification memo, not a revalidation and not a deviation.

Second, identify which of your sites run a combination product under a drug-CGMP-based streamlined quality system, and confirm that the ISO 13485 Clause 4.1 obligations, 4.1.6 included, are actually mapped in that site's quality manual. This is the one place where CSA is on point, and it is usually owned by device quality rather than by the IT validation function, which is how it goes unnoticed.

Third, decide the house position on the CDER supplemental guidance before it publishes. One page saying what you will do when a draft appears, whether that is comment, monitor or adopt selected methods, costs an afternoon and prevents the reflexive gap assessment a draft triggers in most quality organisations.

Fourth, be careful with the savings numbers in the business case. The frequently repeated claim that CSA-style approaches cut validation effort by 40 to 70 per cent is an industry and vendor figure with no regulator behind it, and it does not appear in the FDA guidance at any version. A sourced planning figure exists: the GAMP community estimate that validation done pre-emptively and well should account for around 10 per cent of overall project budget. Present that, and present the effort reduction as an expectation you will measure, not a number you have already banked.

Who signs matters as much as what it says. The authority line in a validation plan is normally the QA reviewer's responsibility rather than the system owner's, and in most organisations nobody has explicitly been asked to check it. Ask. The broader question of which AI-related instruments bind you today, which are draft and which inspectors are already citing is worth settling once for the whole portfolio, and is treated at length in the guide to what binds you under GxP in 2026.