Glossary Term
Computer Software Assurance (CSA)
FDA's risk-based approach to software assurance — effort follows intended use and risk, and the record exists to support the conclusion rather than to prove diligence.
Computer Software Assurance (CSA) is FDA's risk-based approach to establishing and maintaining confidence that software used in medical device production or the quality management system is fit for its intended use. It asks teams to identify intended use, judge process risk, choose a proportionate assurance activity, and keep a record sized to that risk.
On this page
What Computer Software Assurance is
Computer Software Assurance (CSA) is FDA's risk-based approach to establishing and maintaining confidence that software used in medical device production or in the quality management system is fit for its intended use. It's set out in the guidance Computer Software Assurance for Production and Quality Management System Software, first finalised in September 2025 and reissued on 3 February 2026 to align with QMSR.
CSA doesn't remove the obligation to validate software. It changes where the effort goes. The method rests on four moves, applied feature by feature rather than to a whole system at once:
- Identify the intended use — what does this specific feature do in your process?
- Determine the risk — if it failed, could product quality or patient safety be affected?
- Choose a proportionate assurance activity — higher risk pulls toward more rigorous, more scripted testing.
- Keep a record sized to the risk — enough to support the conclusion, not enough to prove you were busy.
The phrase doing the heavy lifting is critical thinking. CSA asks teams to reason about what could go wrong and why it matters, then spend their testing effort accordingly. The habit it's aimed at is the opposite: applying identical scripted rigour to a batch-release calculation and a font-size setting, because a template demanded it.
Assurance is the goal; documentation is the byproduct
The shift CSA names is from producing evidence of diligence to producing confidence the software works. If a testing activity isn't increasing your confidence, its documentation isn't buying you anything either.
Why FDA moved away from validate-everything
By the late 2010s, FDA had a problem it had partly created. Manufacturers were spending enormous validation effort on software that posed little risk, and most of it went into paperwork rather than testing. The burden had also become a disincentive: teams avoided upgrades, declined useful automation, and stayed on aging systems because the validation cost of change felt heavier than the risk of standing still. That's a patient-safety problem wearing a compliance costume.
CSA exists to correct it, and the correction runs in both directions:
- Less effort where risk is low — a feature that can't affect product quality doesn't warrant a fifty-step protocol with screenshots of every field.
- Sustained rigour where risk is high — CSA isn't a licence to test less overall. Features that release product, control a process, or make a quality decision still earn robust, well-documented testing.
- Lower cost of change — when re-assurance after an upgrade is scoped to what actually changed, staying current stops being punitively expensive.
- Judgement becomes visible — a documented risk rationale is more defensible than an undocumented one, even when it concludes the risk is low.
The practical consequence is worth stating plainly. Under CSA the reviewable artefact shifts from the volume of test evidence to the quality of the reasoning behind it. Four hundred pages of low-value screenshots with no risk rationale is a weaker position than six pages explaining exactly why each feature was tested the way it was.
Inspector perspective: "You classified this feature as low risk and tested it unscripted. Walk me through how you reached that. What does it do, what happens downstream if it's wrong, and who agreed?" A CSA-aligned programme answers from a record it wrote at the time. A team that adopted CSA as a documentation-reduction exercise starts reconstructing the reasoning in the room.
Where CSA sits — and what it does not cover
CSA has a specific legal home, and getting the scope right matters more than most summaries admit:
CSA is a device guidance — say so plainly
It's issued by CDRH and CBER and scoped to device production and quality management system software. Pharmaceutical manufacturers aren't its legal audience. Plenty of vendors blur that line, and a validation document that blurs it is a finding waiting to happen. Adopt the methodology by choice, and record it as your policy rather than as a citation.
- The guidance - current title Computer Software Assurance for Production and Quality Management System Software, issued by FDA's CDRH and CBER. First finalised as Computer Software Assurance for Production and Quality System Software on 24 September 2025 (Federal Register notice), superseding the draft published on 13 September 2022. The current version was issued on 3 February 2026 and supersedes the September 2025 final.
- The original hook - before QMSR, 21 CFR Part 820 carried the software-validation obligation at former §820.70(i). QMSR removed most of those standalone Part 820 texts and incorporated ISO 13485:2016 by reference instead.
- The QMSR re-anchor - FDA's Quality Management System Regulation took effect on 2 February 2026, incorporating ISO 13485:2016 into Part 820 by reference. The refreshed CSA guidance followed on 3 February 2026, re-pointing software-validation obligations at ISO 13485:2016 subclauses including 4.1.6, 7.5.6 and 7.6.
- What is in scope - computers and automated data processing systems used in device production or the quality management system. The current guidance applies the framework to automation tools, data analytics tooling, AI/ML tools and cloud computing (IaaS/PaaS/SaaS), with a worked example built around a SaaS system.
- What is out of scope - device software functions. Software as a Medical Device and software embedded in a device are governed elsewhere and aren't what CSA addresses.
- Part 11 still applies - CSA doesn't displace 21 CFR Part 11. Where a system holds regulated electronic records or signatures, those obligations run alongside the assurance approach; the current guidance includes a dedicated section on electronic-records considerations.
- Related standards - ISO 13485:2016 carries the software-validation obligations QMSR now points to, and ISO/TR 80002-2:2017 offers device-industry guidance on validating software used in quality systems. GAMP 5 (Second Edition, 2022) is the parallel industry framework most teams pair with CSA.
How a CSA assessment actually runs
In practice CSA is a short chain of questions asked per feature, and the answers drive everything downstream. A quality management system isn't assessed as one monolith. The feature that releases a batch and the feature that emails a reminder get different treatment, which is the whole point.
- What is the intended use of this feature? Describe the job it does in your process, in your words rather than the vendor's.
- Is the process risk high or not high? FDA's gate is whether failure may result in a quality problem that foreseeably compromises safety. Direct effects on product, on a quality decision, or on data used to make one usually push a feature into the high bucket.
- Which assurance activity fits? Higher risk pulls toward scripted, repeatable, independently reviewable testing. Lower risk permits lighter, unscripted approaches.
- What record supports the conclusion? Capture intended use, the risk-based analysis, what you tested and what you found, the fitness-for-use conclusion, and who performed the assessment (with review and approval when appropriate).
Step two is where most programmes actually struggle. "High process risk" in CSA is a question about the process, not about how complicated the software is or how much it cost. A sophisticated reporting engine can be not-high-risk; a trivial checkbox that gates batch release is not. The table below is practitioner guidance for applying FDA's foreseeably-compromises-safety test — not a quotation from the guidance:
| Points toward high process risk | Points toward not-high process risk |
|---|---|
| The feature makes or enforces a quality decision (release, disposition, approval) | The feature is informational, and a person independently confirms anything that matters |
| It directly controls or monitors a production process | Output is reviewed downstream before it can affect product |
| It creates or maintains data used to make a quality decision | A failure would be obvious and self-announcing rather than silent |
| A failure would be silent, and nothing downstream would catch it | Convenience or presentation only, with no path to product quality |
Two traps recur. The first is letting the answer be set by what the team wants the workload to be. The second is assuming a compensating control exists without checking that anyone actually performs it — a downstream review that nobody does isn't a risk reducer, and an inspector will ask who does it and how often.
The methods FDA discusses sit on a spectrum rather than in two boxes. Unscripted testing includes scenario testing (also called ad-hoc), exploratory testing, and error-guessing; scripted testing scales in detail with risk:
| Method | What it looks like | Typically fits |
|---|---|---|
| Robust scripted testing | Pre-approved step-by-step protocols, expected results defined in advance, formal evidence and independent review | High process-risk features affecting product quality or patient safety |
| Limited scripted testing | Documented scripts covering the critical path, lighter evidence capture | Features with meaningful but bounded risk |
| Exploratory testing | Structured investigation by someone who knows the process, findings recorded as they surface | Not-high-risk features where process knowledge finds more than a script would |
| Error-guessing | Deliberately probing the inputs and edge cases most likely to break | Not-high-risk features with known failure patterns |
| Scenario / ad-hoc testing | Unscripted confirmation that a function behaves as expected across realistic interaction sequences | Low-risk, well-understood functions |
One nuance catches teams out. Choosing an unscripted method doesn't mean keeping no record. The record describes what was explored and what was found, rather than reproducing a script that was never written, and the rationale for choosing that method is itself part of the evidence.
Whatever method you choose, FDA recommends the record carry enough objective evidence to show the software was assessed and performs as intended. In practice that usually means:
- The intended use of the feature, function, or operation being assessed.
- The result of the risk-based analysis — high process risk or not, and why.
- A description of the assurance activity — what was tested or evaluated, and how.
- Issues found — deviations, defects, or failures, plus how they were resolved or justified.
- A fitness-for-use conclusion, plus who performed the work and when (with review and approval when appropriate).
Read as a set, those elements are simply the reasoning written down. That's the practical test of a CSA record: someone who wasn't in the room should be able to follow why this feature got this treatment and reach the same conclusion.
Assess features, not systems
The most common CSA mistake is running the assessment at system level and landing back where you started — one risk rating applied to everything. Granularity is where both the effort savings and the genuine confidence come from.
What strong CSA programmes share
Programmes that hold up under inspection and actually reduce effort tend to share a handful of disciplines:
The record has to survive the author leaving
A risk rationale that made sense to the person who wrote it, and to nobody since, fails the only test that matters. Write it so the next reviewer can follow the reasoning without a conversation.
- Risk criteria defined before the assessment - what counts as high process risk is written down and agreed in advance, not decided case by case to suit the desired workload.
- Feature-level intended-use statements - each assessed function has a plain description of what it does, owned by someone who runs that process.
- The rationale recorded alongside the result - why a method was chosen is captured with what the testing found, so a reviewer can follow the judgement rather than infer it.
- A named person concluding fitness for use - assurance ends in a decision by someone accountable, not in a folder of artefacts nobody signed.
- Change-triggered re-assurance - upgrades, configuration changes and patches are assessed for what they touch, and re-testing is scoped to that rather than repeated wholesale or skipped entirely.
- Vendor evidence used, not duplicated - where a supplier has tested its own product competently, that evidence is leveraged and the customer's effort concentrates on configuration and intended use.
- Periodic review that can change the answer - the risk picture is revisited on a defined cadence, and a review that never changes a classification isn't being run seriously.
How Complere supports computer software assurance
Validating a new quality management system is usually where a CSA programme meets reality: you're being asked to establish confidence in software you didn't build, on someone else's timeline. Complere is built to shorten that. You start from Complere's vendor validation package and adapt it for your intended use, rather than beginning from an empty template folder, and the reasoning your team produces along the way stays in the same system as the records it applies to.
The evidence and the decision live together
When a reviewer asks why a feature was tested the way it was, your team answers from the same controlled record the decision was made in — with the version history, the sign-off, and the change that prompted the last review all attached.
- A vendor validation package you can adopt — Complere's starting evidence set includes a master plan, requirements, risk assessment, and qualification templates, ready to extend for your own intended use and configuration.
- Classified the way your framework expects — GAMP 5 Category 4 (configured / configurable SaaS) as the baseline classification, so your team starts from a defensible position instead of arguing the category from scratch.
- Requirements tied to test evidence in the vendor pack — Complere's validation traceability maps requirements to the tests that exercise them, so you inherit a connected evidence chain rather than rebuilding the matrix from zero.
- Your reasoning kept as controlled records — intended-use statements, risk rationales and test evidence can live as version-controlled documents with role-based electronic sign-off, so the judgement behind a decision is retrievable years later.
- Change that re-opens the right questions — controlled change requests link the documents and training a change affects and carry an effectiveness review, so re-assurance is scoped to what actually moved.
- Periodic review built into the document cadence — review intervals sit on the controlled record itself rather than on a side spreadsheet that quietly goes stale.
- An immutable audit trail, database-enforced — audit-trail records can't be modified or deleted, so the history behind every assurance decision stands on its own.
Frequently asked questions
Common questions about Computer Software Assurance (CSA) sourced from regulatory references and inspection patterns.
Is CSA a replacement for computer system validation?
Not a replacement — a reframing of how you satisfy the same obligation. The requirement to validate software for its intended use hasn't gone anywhere. What CSA changes is the default: instead of applying the same heavy scripted treatment to every system, you first ask what a feature actually does and what happens if it fails, then match the effort to that answer. High-risk features still earn rigorous testing. Low-risk ones stop consuming effort that was never buying real confidence.
Does CSA apply to pharmaceutical manufacturers, or only to medical devices?
The guidance itself is scoped to medical devices. FDA issued it through CDRH and CBER, and it addresses computers and automated data processing systems used in device production or the quality management system. Pharmaceutical manufacturers aren't its legal audience. The thinking travels, though: GAMP 5 second edition moves in the same direction, and many pharma quality teams have adopted critical thinking and risk-proportionate testing as internal policy. In pharma, treat CSA as a methodology you adopt by choice, and be precise about that distinction in your own validation documents.
What changed in the February 2026 update to the CSA guidance?
The update re-anchored the guidance to a new regulatory baseline. FDA's QMSR took effect on 2 February 2026, incorporating ISO 13485:2016 into 21 CFR Part 820 by reference, and the refreshed CSA guidance was issued the next day (3 February 2026). Terminology moved from 'quality system' to 'quality management system', and software-validation obligations now point at ISO 13485:2016 subclauses including 4.1.6, 7.5.6 and 7.6 rather than resting on the former 21 CFR 820.70(i) alone. The current guidance also illustrates the framework for automation tools, data analytics, AI/ML tools and cloud computing, and includes a worked example built around a SaaS system.
Is unscripted testing actually acceptable to FDA?
Yes, where the risk justifies it. FDA recognises unscripted methods — including scenario testing (also called ad-hoc), exploratory testing, and error-guessing — as assurance activities under CSA, not shortcuts to be hidden. The condition is that the choice is deliberate and defensible: you identified the intended use, judged the process risk as not high, and picked a method proportionate to that judgement. What draws objection isn't light testing on low-risk features — it's testing effort that bears no relationship to risk in either direction.
Does CSA mean less documentation?
It means differently-sized documentation, and for high-risk features it may mean no reduction at all. FDA expects enough objective evidence to show the software was assessed and performs as intended: intended use, the risk-based analysis, what assurance activity you ran (including issues found), a fitness-for-use conclusion, and who performed the work (with review and approval when appropriate). Screenshots of every click on a low-risk screen were rarely evidence of anything. A clear statement of why a feature is low-risk and how you confirmed it works is. Teams that read CSA as permission to document nothing tend to discover the gap during an inspection.
How does CSA relate to GAMP 5?
They're compatible frameworks that reached similar conclusions from different directions. GAMP 5 is an ISPE industry framework that classifies software by category and scales validation to risk and supplier reliability; its second edition leans further into critical thinking. CSA is FDA's own articulation of risk-based assurance for device production and quality management system software. Most organisations use GAMP 5 categorisation to frame what a system is, and CSA-style critical thinking to decide how much assurance each function warrants.
What does 'intended use' mean in a CSA assessment?
Intended use is the specific job the software does in your process, assessed feature by feature rather than system-wide. A single quality management system might contain a feature that releases product, another that schedules a reminder, and another that formats a report. Treating them as one undifferentiated 'system' is what produced the old validate-everything reflex. CSA asks you to be granular: name what each feature does, then ask whether a failure in that specific function could affect product quality or patient safety.
Can we rely on the vendor's testing for a cloud or SaaS quality system?
You can leverage it, but you can't inherit the conclusion. CSA expects you to use credible supplier evidence rather than blindly re-testing what the vendor already tested competently — that's part of the point. What stays with you is your intended use and your configuration: how you've set the system up, which features you rely on for quality decisions, and whether those behave correctly in your process. In practice that means assessing the supplier's development and testing discipline once, then concentrating your own effort where your configuration and your use of the system live. The current guidance makes cloud computing (including SaaS) part of the illustrated scope and includes a worked SaaS example.
See what a CSA-aligned vendor validation package actually contains
Walk through the validation evidence Complere provides as a starting set — VMP, requirements, risk assessment, and qualification templates — and see how your intended-use rationale, risk decisions, and test records stay controlled, versioned, and connected to the changes that affect them.