Computer Software Assurance (CSA)
Computer Software Assurance is FDA’s final guidance (September 2022) directing manufacturers to apply critical thinking and risk-based test methods — rather than exhaustive scripted validation documentation — to assure that software used in medical device production and quality systems performs as intended. Its scope is specifically device production and quality-system software under 21 CFR Part 820; it is not a general replacement for computer system validation practice across every GxP domain.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 21 LINKSCSA moves effort from documenting tests to deciding which tests matter — and its scope is narrower than its popularity: it addresses device production and quality-system software, not every GxP system a site runs.
06 · QUALITY MATURITY — COMPUTER SOFTWARE ASSURANCE (CSA), REACTIVE TO ADAPTIVE
Assurance means a thick binder. Effort is measured in pages produced rather than in questions answered.
The approach is described as risk-based, but every system still receives the same scripted testing and the risk step changes nothing downstream.
Intended use and the consequence of failure are determined first, and they visibly change what testing is performed and how it is recorded.
Unscripted and exploratory testing carry real weight where the risk justifies it, and the record captures what was learned rather than only that a step passed.
Assurance effort tracks risk continuously: a change in use or consequence moves the testing without a project, and the documentation burden falls where nothing is at stake.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 3
Derived from the 3 standards SPEQ maps to this subject, across 2 regulatory bodies: FDA, ISPE.
RECORDS & OBJECTIVE EVIDENCE
- Intended-use determination per feature, and the failure consequence that follows from it
- The assurance approach chosen per feature, with the reasoning
- Records of unscripted or exploratory testing, including what was found
- The scope statement showing which software the approach was applied to
- Change records reassessing intended use when the software’s role changed
COMMON INSPECTION FINDINGS
- A risk determination performed and filed while the testing plan stayed unchanged
- The approach applied to systems outside the guidance’s stated scope with no separate justification
- Unscripted testing recorded only as a pass, so nothing survives about what was actually exercised
- Intended use assessed once at implementation and never after the software’s role changed
- Reduced testing adopted as a policy rather than derived per feature from consequence
What CSA Changes
Traditional CSV practice, as widely implemented, tended toward exhaustive scripted test cases with screenshot-level evidence for every function regardless of risk — a documentation burden that FDA’s guidance argues consumed assurance effort without proportionally reducing patient risk. CSA reorients that effort: spend the deepest scrutiny on high-risk functions (those directly affecting product quality, data integrity, or patient safety) and apply lighter-touch, unscripted or ad hoc testing to low-risk functions.
The guidance explicitly endorses leveraging vendor testing and documentation for lower-risk, well-established functionality rather than re-proving what a reputable supplier has already demonstrated — a direct extension of the risk-based thinking GAMP 5 introduced into the CSV space.
Scope — Where CSA Applies
CSA’s guidance document is scoped explicitly to software used in the production and the quality system of medical device manufacturers under 21 CFR Part 820 — think manufacturing execution, inspection, and quality-record systems used by a device maker. It does not extend by its own terms to clinical trial systems, pharmacovigilance databases, or pharmaceutical GMP computerised systems outside the device production/QMS context; those remain governed by their existing validation expectations.
This scope boundary is a common point of confusion: “apply CSA thinking” is sometimes used loosely across GxP domains as shorthand for risk-based validation generally, but citing the CSA guidance itself as authority for, say, a clinical eTMF system’s validation approach would be a scope error.
Risk Determination First
CSA’s core sequence is: determine the intended use of the software feature, assess the risk that feature poses if it fails (to patient safety, product quality, or data integrity), and only then select an assurance activity proportionate to that risk. Unscripted testing, ad hoc exploratory testing, and leveraged vendor assurance are all legitimate outcomes of that assessment for lower-risk features — the guidance treats “less documentation” as a valid conclusion, not a shortcut taken without the risk analysis behind it.
Relationship to Existing CSV Practice
CSA does not remove the underlying Part 820 requirement to validate software used in production or the quality system; it changes how manufacturers may demonstrate that assurance. Organisations that have historically run scripted CSV under a GAMP 5-based program can generally apply CSA principles within that same governance framework — CSA is best understood as a refinement of assurance method for a specific software scope, not a parallel or competing system.
SPEQ interpretation: the guidance rewards organisations that already have a disciplined risk-assessment step in their CSV process, because CSA’s time savings come entirely from correctly triaging risk — an organisation without a credible risk methodology cannot safely thin out its testing just because CSA permits it in principle.
FREQUENTLY ASKED
Can CSA be applied to a pharmaceutical GMP computerised system?
The CSA final guidance itself is scoped to device production and quality-system software under 21 CFR Part 820. Applying its risk-based reasoning more broadly is a defensible quality-system choice many organisations make, but doing so is a site policy decision, not something the CSA guidance itself mandates or endorses outside its stated scope.
Does CSA eliminate the need for a validation plan?
No. CSA changes the depth and style of testing evidence for individual features based on risk; it does not remove the overarching requirement to plan, execute, and document that a system is fit for its intended use.
How does CSA relate to GAMP 5 categories?
They are complementary rather than competing: GAMP 5 categorisation helps scope overall validation rigor for a system, while CSA provides risk-based method selection for individual features and functions within that system, with a shared emphasis on proportioning effort to risk.