CSAComputer Software Assurance

Computer Software Assurance is FDA's recommended modernised approach to validating software used in production or the quality system for medical devices. Its central idea: the level of assurance effort must be proportional to the risk the software poses to product quality or patient safety. Low-risk features get lightweight evidence; high-risk features get rigorous testing. The aim is to remove documentation-for-documentation's-sake without weakening assurance where it matters.

CSA was issued as FDA draft guidance in September 2022. While medical-device-specific in scope, the underlying logic has been adopted across pharma, supplements and food by sites looking to escape the binder-thick CSV model. Inspectors across the device, drug and biologics centres are aligned with the risk-based premise even where the formal guidance does not apply, and GAMP 5 Second Edition (2022) was rewritten to align with CSA terminology and decision framework.

The shift is real and overdue. Traditional CSV had drifted into a documentation theatre — sites generating thousands of pages of scripted protocols, screenshot books and re-tested vendor evidence, with no measurable improvement in software assurance and substantial drag on getting validated systems into production. CSA puts the validation effort where the risk is and stops the rest.

Software validation in regulated industries followed a trajectory that ended up trapped in process:

The trigger for CSA was a 2020 FDA Case for Quality finding: medical-device manufacturers reported spending up to 80% of validation effort on documentation, with only 20% on actual testing. Patients were no safer for the imbalance, and the documentation burden was actively delaying useful software from reaching production. The agency's explicit aim with CSA is to flip that ratio.

CSA starts every validation activity with a risk question: if this software feature fails, what is the impact on the product or the patient? FDA's decision tree groups features by intended use:

The classification is per-feature, not per-system. A single platform like V5 contains all three classes: dispense, e-signature and batch record are direct-impact and validated heavily; trend dashboards are indirect; the admin colour theme is no-impact. CSA expects the validation package to acknowledge that and not waste effort homogenising the rigour across them.

The risk question gets re-asked on every change. A new feature is classified on its way in; an existing feature is reclassified if its use changes (e.g. a dashboard that gets cited in a release decision moves from indirect to direct).

1. Scripted testing — traditional pre-written protocol with expected/actual results, screenshots, signatures. Still appropriate for direct-impact features; nothing about CSA discourages it where the risk justifies the rigour.
2. Unscripted testing — exploratory testing by an SME against a feature, with notes captured. Appropriate for indirect-impact features. Defensible when the SME is qualified and the notes are contemporaneous.
3. Ad-hoc testing — short, focused tests in response to a specific question ("does the boundary condition behave correctly?"). Captured with same audit trail expectations as any GxP record.
4. Vendor-supplied evidence — testing, qualifications and certifications from a qualified vendor, leveraged rather than duplicated. Requires a vendor audit or supplier qualification to use.
5. Continuous monitoring — live telemetry, error logs, alerting as on-going assurance once the system is in production. Increasingly accepted as part of the assurance posture, not just operational monitoring.
6. Automated testing — unit, integration and end-to-end test suites that run on every release. The execution log is the evidence; no separate manual protocol is required where automated coverage is justified and traceable to risk.

CSA reduces documentation burden in the validation activity. It does not relax the regulatory obligations the validated system has to satisfy. The line is important — sites that read CSA as permission to skip Part 11 controls or audit-trail capture will find inspectors disagreeing.

CSA is a lighter route to the same regulatory outcome — not an exemption from it. The Compliance Loop (controls + records + audit trail + e-signatures) must be intact regardless of whether validation evidence is scripted or unscripted, full or leveraged.

1. Inventory all software features in scope of validation. Group by direct/indirect/no-impact based on intended use.
2. For each feature, write a one-line intended-use statement and a risk classification. This is the risk register; it is the entire validation strategy in one document.
3. For direct-impact features, write scripted test protocols. Execute, capture evidence, sign off.
4. For indirect-impact features, run unscripted SME testing. Capture notes contemporaneously. Reference vendor-supplied test evidence where the vendor is qualified.
5. For no-impact features, perform installation confirmation and a basic smoke check. Done.
6. Wire the validated system into change control. Every change re-runs the risk assessment for the affected feature(s) and triggers re-testing scoped to risk.
7. Set up continuous monitoring — error logs, alerts, periodic review — as the on-going assurance posture.
8. Compile the validation pack: risk register, intended-use matrix, test evidence summary, vendor-evidence leverage statement, change-control linkage, Part 11 controls evidence.

A team that previously spent six months on a CSV exercise will typically deliver the equivalent CSA pack in six to eight weeks, with stronger assurance on the features that actually matter and substantially less paper.

One of CSA's largest practical wins is the explicit endorsement of leveraging vendor-supplied test evidence rather than re-running everything in-house. The conditions are:

• The vendor's quality system is qualified — either by formal audit (typical for high-impact systems) or by a documented assessment of the vendor's release-engineering practices.
• The vendor's test evidence is specific, version-pinned and reproducible — not a marketing data sheet but actual test execution records.
• The intended use in your site matches the use the vendor tested. Where it differs, that delta is tested locally.
• Vendor change notifications are part of your change-control intake, so a vendor patch triggers a local impact assessment.

Vendor evidence cannot substitute for direct-impact testing of features used in ways the vendor didn't test, but for the indirect-impact bulk of a typical platform it removes weeks of duplicate work.

• "CSA means no documentation." Wrong — it means proportional documentation. Evidence is still required and inspections still look for it.
• "CSA replaces CSV entirely." Wrong — for direct-impact features, scripted testing is still appropriate and CSA explicitly preserves it.
• "CSA only applies to medical devices." The formal guidance is device-scoped, but the logic is being adopted across pharma, supplements and food. Inspectors across centres are aligned with the underlying risk-based approach.
• "CSA lets us skip Part 11." No. Part 11 controls (audit trail, e-signatures, security) are independent of validation approach.
• "CSA means we don't need to test vendor software." Only where the vendor is qualified, the evidence is specific to your use, and the change-control linkage is in place.
• "CSA is finalised guidance." As of 2026 it remains FDA draft; the approach is widely adopted in practice but the document still carries draft status.
• "Going from CSV to CSA needs a new SOP." Usually it needs an updated validation strategy and a risk-register practice; the change-control SOP, Part 11 SOP and supplier qualification SOP often need only minor edits.

An inspector arriving at a CSA-validated site will ask for the same things as a CSV-validated site, with the burden of proof on the risk classifications:

• Show me the risk register. Demonstrate that the high-risk features got rigorous evidence.
• Show me the intended-use statement for [random feature]. Show me the test evidence proportional to that classification.
• If you leveraged vendor evidence, show me the vendor qualification and the evidence itself.
• Show me the change-control trail for the last 12 months and a sample re-validation triggered by a change.
• Show me the Part 11 controls — audit trail sample, e-signature meaning, two-factor authentication.
• Show me the continuous-monitoring evidence — error logs, alerts, periodic review.

A clean CSA validation pack answers each of those questions in under a minute. A weak one cannot defend the risk classifications, and the inspector will treat the lower-rigour evidence on indirect features as a gap rather than a justified choice.

The first concrete step in any CSA programme is intended-use risk classification of every feature in scope. The 2022 draft guidance defines two top-level categories — direct impact on product quality / patient safety / record integrity, and indirect impact — and within each, three risk tiers driven by detectability + consequence + probability. The rigour of testing for each feature follows directly from its classification.

The classification is the validation defence. An FDA investigator looking at a low-rigour testing record will ask why; the rubric provides the answer in writing. Sites that skip the classification step and just test 'everything to medium rigour' end up with a pack that is both too heavy on low-risk features and too light on high-risk ones — and inspectors notice both.

CSA opens the evidence aperture beyond the traditional scripted protocol + screenshot model. FDA's draft guidance explicitly endorses unscripted exploratory testing, automated test execution logs, vendor-supplied evidence (with appropriate qualification), and continuous-deployment evidence (CI/CD test runs). The right modality follows from the feature's risk tier:

• Scripted protocol with objective evidence — the traditional model. Still appropriate for high-direct features. Evidence is the executed protocol + screenshots / data dumps / log extracts + reviewer signature.
• Automated test execution log — modern CI-driven pattern. The test code itself is the protocol (version-controlled, reviewed under change control), the test run output is the evidence. Strongest for regression coverage on high + medium direct features.
• Unscripted exploratory testing — tester operates the system under realistic scenarios, captures notes + screenshots + defects in a structured record. Appropriate for medium / low risk and as supplement to scripted on high-risk.
• Vendor-supplied evidence — leveraged with documented vendor qualification (audit + ongoing monitoring). Strongest for cloud / SaaS GxP systems where the customer cannot economically re-test infrastructure.
• Production-monitoring evidence — for continuously-running systems, evidence of in-spec operation over time supplements pre-go-live testing. Strongest as part of periodic review rather than initial validation.

The pattern that defines a mature CSA programme is layered evidence: automated tests cover the regression baseline (catches regressions on every change), scripted protocols cover the high-direct features (defends against the 'show me the test for X' question), and exploratory testing covers the realistic-usage edges. Programmes that rely on a single modality leave gaps that show up at inspection.

FDA's CSA guidance pre-dates the explosion of AI-assisted GxP features, but the same risk-based logic applies — and FDA's 2024 draft 'AI/ML in Software as a Medical Device' framework explicitly cross-references the CSA approach. For non-device GxP systems with AI components (predictive maintenance, anomaly detection, document summarisation, deviation classification suggestions), three additional disciplines apply on top of standard CSA:

1. Bound the AI's role — explicitly distinguish features where AI output is advisory (human reviews + decides) from features where AI output drives a regulated decision (release, hold, disposition). The latter is high-direct and requires extensive validation; the former can be medium-direct if the human review gate is enforced.
2. Drift monitoring — AI models can degrade as underlying data distributions shift. A validation pack snapshot at go-live is necessary but not sufficient; periodic re-evaluation against ground truth is part of the ongoing CSA evidence.
3. Explainability + override — for any AI-driven decision the user / reviewer must be able to see why the model concluded what it did, and override it with a recorded reason. Without this, the system fails Part 11 meaning-binding and the audit trail loses interpretive value.