What is Computer Software Assurance (CSA)?

CSA definition

Computer Software Assurance (CSA) is a risk-based methodology for demonstrating that software used in medical device production or the quality management system performs as intended. FDA's February 2026 final guidance (GUI00017045) describes CSA as establishing confidence in automation through proportionate assurance activities — not prescribing identical test-script volume for every function.

CSA aligns with the Quality Management System Regulation (QMSR) and ISO 13485:2016 by reference. The guidance applies to computers and automated data processing systems used as part of production or the QMS — including on-premises, SaaS, IaaS, and PaaS deployments when used for production or quality purposes.

CSA does not replace the underlying requirement to validate software. It reframes how assurance effort is scoped: higher process-risk features warrant more rigorous, often scripted testing; lower-risk functions may be covered with leaner methods such as scenario testing, error-guessing, or exploratory testing.

FDA guidance scope

FDA issued Computer Software Assurance for Production and Quality Management System Software on 3 February 2026, superseding the September 2025 version. The guidance scope is production and QMS software for medical devices — not device software functions regulated under §201(h) of the FD&C Act (SaMD/SiMD), which remain governed by separate device software guidance.

The guidance explicitly states it is not intended to provide a complete software validation life cycle. It extends the risk-based approach from FDA's General Principles of Software Validation guidance to production/QMS software, with additional discussion of process risk, acceptable testing methods, and efficient generation of objective evidence.

Pharmaceutical and biologics manufacturers may reference parallel FDA guidance for pharmaceutical quality systems; the CSA principles — intended use, process risk, proportionate evidence — are increasingly relevant across regulated life sciences even when the citing document differs.

Process risk vs device risk

A central CSA concept is process risk — the potential for a software function to impact patient safety, product quality, or data integrity within the production or QMS context. This is distinct from ISO 14971 device risk management, though both inform assurance decisions.

FDA's framework asks whether a software feature, if it failed or produced incorrect results, could reasonably affect product quality, release decisions, nonconformance handling, or electronic records relied upon for GxP decisions. High process-risk features justify more rigorous assurance; features with lower direct quality impact may use proportionately lighter evidence.

In GXPLearn Module 11, learners practise assessing risk severity and detectability, then sizing assurance effort — mirroring the critical-thinking emphasis FDA describes rather than checkbox compliance alone.

FDA six-step CSA risk framework

FDA Section V.A organises CSA into six interconnected steps. Assurance is not a one-time event — each step informs the others across the software life cycle, including when changes occur.

1. Intended use — Define what the software function is meant to accomplish in production or the QMS, including user roles and decision points.
2. Risk approach — Identify process risk for each function; determine where additional rigor is appropriate versus where leaner methods suffice.
3. Changes — Plan how software changes, configuration updates, and vendor releases will be assessed to maintain validated state.
4. Assurance activities — Select testing methods (scripted, unscripted, hybrid) proportionate to process risk and intended use.
5. Additional considerations — Address cloud/SaaS models, vendor evidence, data integrity, AI/ML tools used in production/QMS, and supplier quality.
6. Records — Document assurance activities with objective evidence reviewers can follow — without requiring identical artefact depth for every function.

Testing methods under CSA

FDA Table 1 contrasts scripted and unscripted testing approaches. Scripted testing (robust or limited) provides predefined steps and expected results — appropriate when process risk is high or when repeatability and auditability are paramount.

Unscripted methods include scenario testing, error-guessing, and exploratory testing. These can be appropriate for lower process-risk functions where the goal is to exercise realistic workflows and observe behaviour without exhaustive pre-written scripts.

Hybrid approaches combine elements of both. The key CSA judgement is matching method to risk — not defaulting to full regression for every screen change or, conversely, skipping evidence for functions that directly affect batch release or quality records.

21 CFR Part 11 and CSA

FDA Section V.B clarifies that enforcement discretion for certain Part 11 requirements does not apply to the validation of production or QMS software. Electronic records and signatures subject to predicate rules still require appropriate controls.

CSA does not reduce Part 11 obligations where they apply. Instead, it helps scope validation and assurance effort for the software functions that generate, modify, or rely upon GxP electronic records — focusing controls on predicate-rule records and documenting scoping decisions.

Practise CSA thinking in GXPLearn

Module 11 (CSA · Assurance) walks learners through assurance scenarios: pick a case, assess risk severity and detectability, walk the Assurance Chain, and generate a defensible assurance rationale. Module 12 (CSV vs CSA) then compares both lenses on the same change — essential for governance conversations as organisations adopt CSA principles.

GXPLearn content reuses vocabulary from public FAQ and glossary entries and extends them with interactive judgement practice. Foundation Modules 01–03 are free; Modules 09–12 and the full professional curriculum unlock with an individual licence.