CSA Assurance Strategy Workbench
Determine the risk-based assurance strategy for a computerized system the way FDA’s final Computer Software Assurance guidance (September 2025) intends: intended use → process impact → failure risk → the recommended verification method (none / supplier evidence / unscripted / exploratory / targeted / scripted / automated) and the evidence it implies. Deterministic and explainable, with additional AI-assurance controls when the system is AI-enabled. A scoping aid, not a validated assurance system.
OUTPUT
TIME
Limitations — read before you rely on this
- This is a scoping aid, not a validated system, and not the documented risk assessment each computerized system still requires. Reproduce the determination in your own validation framework and record the rationale; never cite this tool as evidence a system was assured.
- CSA is FDA’s approach for medical-device production and quality-system software. Applying the same risk-based method to clinical, pharmacovigilance, or pharmaceutical-process systems is a planning heuristic only — it does not make CSA the governing regulation there, and you must confirm the framework that does apply.
- The tier thresholds and the supplier/usage adjustments are SPEQ judgement expressing CSA’s intent, not fixed FDA allowances. A different, equally defensible model could place a borderline case one tier away — treat a near-threshold result as a prompt to reason, not a verdict.
- It assesses one feature/function at a time, as CSA intends. A system is a set of features at different risks; run it per function and do not average a whole system to a single method.
WHAT THIS CALCULATES
The risk-based assurance strategy a computerized system actually needs — the recommended verification method (none, supplier evidence, unscripted, exploratory, targeted, scripted, or automated) and the evidence it implies — derived deterministically from the feature’s process impact, the severity and detectability of a failure, how much supplier assurance can be leveraged, and how often it runs. It turns "assure it proportionate to risk" into a specific, defensible method, with additional AI-assurance controls when the system is AI-enabled.
THE METHOD
method = ladder( process_risk ), process_risk = f(risk_score), risk_score = impact_w × severity + detectability, then adjusted by supplier and usage- impact_w
- process-impact weight: direct = 2, indirect = 1, none = 0 (no production/quality-system role → out of scope)
- severity
- severity if the feature fails to perform as intended, 1 (business-only) … 4 (patient safety)
- detectability
- chance the failure escapes existing controls, 1 (always caught downstream) … 4 (undetectable until harm)
- risk_score
- the transparent 0–12 process-risk score; ≥9 → high, ≥6 → medium, else low; a direct patient-safety function is high by rule
- process_risk
- the resulting tier (none / low / medium / high) that sets the base assurance effort
- supplier
- leverageable supplier assurance, 1 … 4 — a mitigant that lowers effort, but never for a high-risk function
- usage
- run/re-verification frequency, 1 … 4 — high frequency escalates high-risk to automated and low-risk to chartered exploratory
- ladder
- the effort ladder none → supplier-evidence → unscripted → exploratory → targeted → scripted → automated
- method
- the recommended verification method selected on the ladder for this risk, after supplier and usage adjustment
Deterministic and monotonic: raising impact, severity, detectability, or usage never lowers the recommended rigour, and raising leverageable supplier assurance never raises it. A high-risk function has a rigour floor (scripted) that supplier evidence cannot reduce. The tier thresholds are SPEQ judgement expressing CSA’s risk-based intent, not fixed FDA values.
THE INPUTS, AND WHAT THEY MEAN
- Process impact on product / quality
- Whether the feature is a production or quality-system function that directly affects product quality, safety, or a record (direct), merely supports a GxP process (indirect), or has no GxP role (none). This is CSA’s first determination and it dominates the result.
- Severity if the feature fails
- How bad the consequence is when the function fails to perform as intended, from business-only through data-integrity impact to a failure that could foreseeably compromise patient safety. Patient-safety severity on a direct function is high-risk by rule.
- Detectability of a failure
- How likely an existing downstream control is to catch the failure before it causes harm. A failure that is undetectable until harm occurs raises the risk even when the immediate severity looks moderate.
- Leverageable supplier assurance
- How much validated-COTS or supplier validation evidence you can actually assess and rely on. Strong, assessable supplier assurance lets you leverage it and confirm rather than re-script — but only where the process risk is not high.
- Usage / re-verification frequency
- How often the function runs and is regressed. Frequent, high-volume execution is what justifies automating a high-risk function’s testing and chartering structured exploratory sessions for a low-risk one.
Right-size assurance from a system's process risk.
Determine the risk-based assurance strategy the way FDA’s final Computer Software Assurance guidance (September 2025) intends: from a feature’s intended use and process impact to the verification method and evidence it actually needs. Deterministic and explainable — set the drivers, and SPEQ returns the method, with additional controls when the system is AI-enabled.
CSA is FDA’s approach for medical-device production and quality-system software. The risk-based method is applied here as a broader scoping heuristic — it does not make CSA the governing regulation for clinical, pharmacovigilance, or pharma-process systems. A SPEQ planning aid, not a validated assurance system.
Structured exploratory testing — chartered, time-boxed sessions with documented observations, without predetermined step-by-step scripts.
Session charters and notes: what was explored, observations, defects, and disposition.
direct process impact with failure severity 3 and detectability 2 → medium process risk (score 8/12). Leverageable supplier assurance (2/4) lowers the effort to exploratory.
HOW TO READ THE OUTPUT
- The method is the recommendation; the process-risk tier is why. Read them together — "targeted testing because this is a medium-risk direct function with moderate detectability" is the defensible sentence, not the method alone.
- Supplier assurance lowers effort but never removes it once there is GxP impact, and never for a high-risk function. If a patient-safety-critical direct feature still lands on scripted despite strong supplier evidence, that is the rule working, not a limitation.
- A "none" result is a genuine outcome, not a gap: a feature with no production or quality-system role is outside CSA scope, and the honest action is to record the intended-use rationale and stop, not to invent testing.
- The AI-enabled controls sit on top of the method, not instead of it. An AI system is still assured for its process risk; the extra controls (Context of Use, an owned evaluation suite, monitoring, human approval) address what is AI-specific — see the AI risk classifier and Good AI Practice.
WORKED EXAMPLE
A configured MES electronic batch-record step that releases a batch to the next stage. Direct process impact; a failure could compromise product quality but is usually caught at QA review; partial vendor documentation; run on every batch.
- Process impact
- Direct
- Severity
- 3 — product-quality impact
- Detectability
- 2 — usually caught before impact
- Supplier assurance
- 2 — some vendor documentation
- Usage frequency
- 4 — continuous, regressed often
RESULT
The medium tier puts the base at limited scripted testing of the risk-relevant functions; the weak supplier evidence does not pull it down further, and because this is not a high-risk function the high-frequency use does not force full automation. The defensible plan is targeted scripted coverage of the release logic and its expected results, with the evidence being those scripts and the risk basis for what was and was not scripted.
REGULATORY BASIS
- FDA — Computer Software Assurance for Production and Quality System Software (final, Sep 2025)
- The risk-based assurance method this workbench implements: least-burdensome verification proportionate to process risk, for medical-device production and quality-system software specifically.
- ISPE GAMP 5 (2nd ed.) — A Risk-Based Approach to Compliant GxP Computerized Systems
- The framework CSA builds on; supplies the category and risk-based testing model and the supplier-leverage principle the engine encodes.
- 21 CFR Part 11 — Electronic Records; Electronic Signatures
- The records-integrity requirements the retained scripted testing on high-risk functions continues to satisfy.