CSA Risk-Based Testing Examples for Low, Medium and High Risk

written by

Sundar

Director, GoVal

Published on July 27, 2026

Last updated on October 9, 2026

Reading time: 5 min read

Ready to modernize?

See GoVal in Action

Book a 30-minute walkthrough with our validation specialists. No slides — just your questions, answered live.

Summary

CSA-aligned risk-based testing scales assurance activity to the potential impact of software failure and the ability to detect that failure before harm. FDA's CSA guidance was first finalized in September 2025 and revised in February 2026; the current guidance includes Scenario Testing (also referred to as Ad-Hoc Testing) as one form of unscripted testing. Its formal scope is medical-device production and quality-management-system software under 21 CFR Part 820.

What are examples of CSA risk-based testing for high, medium, and low risk?

High-risk examples — batch release calculations, e-signature enforcement, critical alarm logic — get scripted testing with pre-defined steps and expected results. Medium-risk examples — deviation routing, reviewed reports, training reminders — get scenario-based testing, recorded but not scripted line by line. Low-risk examples — cosmetic UI, unconfigured vendor features, non-GxP tools — get light scenario testing or a record review.

The hard part of CSA was never the concept. It's knowing which testing method actually applies to the feature sitting in front of you. Here it is, tier by tier, with real GxP system examples.

How Risk Level Is Determined

Two questions set the tier for any software feature: does it directly affect patient safety, product quality, or data integrity, and is there an independent way to catch a failure before it causes harm? Yes to the first with no independent check is high risk. A supporting role with a human review or downstream check before consequence is medium risk. No meaningful GxP impact at all is low risk — regardless of how central the feature feels to daily use.

High-Risk Testing Examples

High-risk features get scripted testing — pre-defined steps, inputs, and expected results, with edge cases built around specification limits, executed under a formal, traceable protocol.

Feature / System	Why It's High Risk	What the Evidence Looks Like
Batch release calculation logic (MES/ERP)	Directly determines product disposition; an error could release an out-of-spec batch	Scripted test cases at, above, and below spec limits, with pass/fail recorded against each
Electronic signature enforcement (LIMS/QMS)	Controls approval of GxP records; a bypass would break accountability entirely	Scripted verification that signing is enforced at every required step, with no workaround path
Potency/assay calculation (chromatography data system)	Feeds directly into a release decision with no independent recheck before use	Scripted testing across a range of inputs, including known edge-case values near acceptance limits
Alarm logic on environmental monitoring (sterile manufacturing)	A missed excursion alarm could allow contaminated product to proceed undetected	Scripted testing of trigger thresholds and escalation routing for each alarm condition

Medium-Risk Testing Examples

Medium-risk features get scenario-based testing — a term used in FDA's current guidance, which defines Scenario Testing as also referred to as Ad-Hoc Testing. Testing stays purposeful and recorded, but without a rigid, line-by-line script.

Feature / System	Why It's Medium Risk	What the Evidence Looks Like
Deviation/CAPA routing logic (QMS)	Supports the quality process, but a person reviews and approves before any consequence	A handful of representative deviation types run through, outcomes and screenshots recorded
Certificate of Analysis draft compilation (LIMS)	Output is reviewed and approved by a QA reviewer before it's used for anything	Exploratory testing across representative sample types, results documented
Training due-date reminder notifications (LMS)	Supports compliance tracking, but a missed reminder is caught by other periodic checks	Scenario testing of upcoming and overdue cases, confirmed and recorded
Equipment performance trending dashboard (MES)	Used for internal visibility, not a direct release or disposition decision	Scenario testing confirming data displays accurately for a few representative periods

Low-Risk Testing Examples

Low-risk features can rely on light scenario testing or a record review, often leveraging the vendor's own test evidence directly rather than re-testing from scratch.

Feature / System	Why It's Low Risk	What the Evidence Looks Like
Column sort order / field label display (any GxP system)	Cosmetic; no effect on data, decisions, or compliance	Brief visual confirmation, recorded in a line or two, or skipped with documented rationale
Standard PDF export button (unconfigured vendor feature)	Unmodified commercial functionality already covered by vendor testing	Vendor test evidence referenced directly; no independent re-testing needed
Non-GxP document search/filter tool	No GxP data or decision involved in what it searches	Light scenario check that search returns expected results
Routine system login confirmation notification	No regulatory content; purely a convenience notification	Record review confirming the notification fires; no dedicated test case required

Terminology note: FDA's current CSA guidance (revised February 2026) lists Scenario Testing as "also referred to as Ad-Hoc Testing" and separately describes other unscripted approaches such as error guessing and exploratory testing. The important point is to select assurance activities based on intended use and risk, and to establish an appropriate record of what was done and concluded.

How GoVal Applies This

GoVal classifies each system by GAMP 5 category and risk tier at intake, then scales required test depth and documentation to that classification automatically — scripted protocols for high-risk functions, scenario-based testing for medium-risk ones, light evidence for low-risk functions — so the tiering above gets applied consistently across a portfolio instead of being re-judged, feature by feature, by whoever happens to be running that day's validation.

Frequently Asked Questions

What are examples of high-risk CSA testing? +

High-risk examples include batch release calculations in an MES or ERP that determine product disposition, electronic signature enforcement on GxP records, automated potency or assay calculations in a chromatography data system feeding a release decision, and alarm logic on environmental monitoring systems protecting sterile manufacturing. Each directly affects patient safety, product quality, or data integrity with no independent check before harm could occur, so each requires scripted testing with boundary and edge-case scenarios around specification limits.

What are examples of medium-risk CSA testing? +

Medium-risk examples include deviation or CAPA routing logic in a QMS, report generation features whose output a human reviews before any decision is made, training due-date reminder notifications, and equipment performance dashboards used for internal trending rather than release decisions. These support GxP processes without directly making a critical decision, so they use scenario-based testing — purposeful, realistic scenarios executed and recorded without a rigid script.

What are examples of low-risk CSA testing? +

Low-risk examples include cosmetic UI elements like column sort order or field label display, unconfigured vendor-tested functions such as a standard PDF export button, non-GxP document search or filter tools, and routine system notifications with no regulatory content. These carry minimal or no GxP impact, so light scenario testing or a record review leveraging existing vendor test evidence is typically sufficient.

How do you decide if a software feature is high, medium, or low risk under CSA? +

Ask two questions: does it directly affect patient safety, product quality, or data integrity, and is there an independent way to detect a failure before it causes harm? Yes to the first with no independent detection is high risk and needs scripted testing. A supporting role with a human review step or downstream check is typically medium risk. No meaningful GxP impact at all is low risk, regardless of how central the feature feels to daily use.

Is "ad hoc testing" still the correct term under FDA's final CSA guidance? +

Not exactly. FDA's CSA guidance, first finalized in September 2025 and revised in February 2026, lists Scenario Testing as "also referred to as Ad-Hoc Testing" and also describes error guessing and exploratory testing as unscripted approaches. The appropriate approach should be selected based on intended use and risk, with an assurance record that supports the conclusion.

Can vendor testing evidence replace testing for low-risk features? +

Supplier information and prior assurance evidence can be considered where their relevance and adequacy are justified, but they do not automatically eliminate the need for manufacturer assurance. The final scope should reflect intended use, risk-based analysis, system capability, supplier evaluation, and any configuration or higher-risk functions that warrant additional evidence.

How does GoVal support risk-based test scoping under CSA? +

GoVal classifies each system by GAMP 5 category and risk tier at intake, then scales the required test depth and documentation to that classification automatically — scripted protocols for high-risk functions, scenario-based testing for medium-risk ones, light evidence for low-risk functions — rather than leaving that judgment to be made fresh, inconsistently, for every system.

Apply risk-based test scoping consistently across your systems

GAMP 5 classification, scripted and scenario-based test workflows, and audit-trailed evidence — in GoVal.

Book a Free Demo →