Pillar Wissen Jun 23, 2026 · 11:00 8 min read By Daniel Herrmann

CSA Methodology: Risk-Based Validation Explained in 5 Steps

Implement Computer Software Assurance with DHC's five-step practice model for scope, process risk, assurance activities, records and governance.

Computer Software Assurance (CSA) is the risk-based assurance approach in the final FDA guidance for software used in medical-device production and quality management systems. Five steps structure implementation: applicability, risk assessment, use-case centring, appropriate assurance activities and lifecycle governance. The methods can inform risk-based CSV for other Pharma GxP systems, but they do not extend the direct FDA scope.

The five steps are a DHC practice model for implementation. They are not a verbatim five-step FDA requirement.

Lead

Your team validates a new system following an established CSV framework. All functions are tested at similar depth, documentation grows, the go-live date keeps slipping. In the steering committee, the question is raised why progress is slow — even though everyone in the room knows that a large share of the tests covers functions no one uses critically.

FDA revised the final CSA guidance in February 2026 to align it with the amended 21 CFR Part 820 Quality Management System Regulation (QMSR); it supersedes the September 2025 version. Within its direct scope, assurance effort follows process risk. In practice, CSA is often misunderstood as a blanket instruction to “validate less”. That creates new audit risk and inaccurate scope claims.

This guide shows the five steps of a clean CSA implementation — and where the most common misconceptions lie.

What CSA Really Is (and What It Is Not)

Computer Software Assurance is a risk-based software-assurance approach for computers and automated data processing systems used in medical-device production or the related quality management system. The core: assurance effort and records follow process risk and intended use.

Modern CSA approaches allow you to focus test effort and documentation more strongly on risk-relevant functions. Instead of documenting every feature to the same depth, testing every workflow and substantiating every configuration, CSA directs attention specifically to where risk arises. The result: leaner validation packages — and teams gain time for risk-oriented thinking.

CSA flips the logic. The question is no longer "What do we need to test?", but "Where can a defect cause real damage — and how do we mitigate exactly that risk?"

Legacy CSV Implementation vs. Modern CSA Approach

Aspect	Legacy CSV Implementation	Modern CSA Approach
Test strategy	Full testing of all functions	Risk-based: focus on high risk
Documentation output	Often template- and volume-driven	Appropriate and risk-justified
Vendor leverage	Own tests dominant	Vendor evidence structurally integrated
Pace	Slowed by uniform full testing	Focused through suitable assurance activities
Mindset	Documentation first	Process risk and intended use first
FDA / guidance link	Recognised, but often implemented documentation-heavy	Supported by the CSA guidance
Audit reliability	Industry standard	Equal or better with consistently risk-based implementation

The 5 Steps of CSA Methodology

Step 1: Risk Assessment Before Test Script

Before any test comes the question: What can go wrong, how likely is it, how severe would it be?

The assessment follows ICH Q9 — structured, documented, traceable. Each function receives a risk classification: high, medium, low. This classification governs every subsequent step.

Practical output: A system risk matrix that assesses reasonably foreseeable software failures and their process impact. High-risk functions receive deeper, traceably justified assurance.

Step 2: Use-Case-Centred Requirements

User Requirements Specifications (URS) in CSA are no longer written as pure feature lists. Instead, they describe critical user journeys: Which tasks must the user complete successfully in daily work — and which errors must not occur?

This sharpens the URS in two ways. First: it becomes shorter and more precise. Second: it directly yields the test cases needed later. In our projects, a well-written URS noticeably reduces subsequent validation effort.

Step 3: Tiered Test Depth by Risk

Instead of checking each function with documented test scripts, test depth is matched to risk:

High risk: Comprehensive, documented test scripts with traceable evidence
Medium risk: Sampling-based testing, supplemented by vendor evidence and documented risk justification
Low risk: Reduced test depth — depending on intended use, qualified vendor status, GxP criticality and documented risk justification. A manufacturer's declaration alone is not sufficient; the assessment must be justified and traceable.

This step provides the central efficiency lever. The actual effect depends on intended use, process risk, system complexity and usable supplier evidence and is not promised as a blanket percentage.

Step 4: Structuring Vendor Evidence Cleanly

Vendor evidence is more than "accept an ISO certificate". The FDA guidance allows you to use vendor responsibility as part of validation evidence — but only under clear conditions:

Vendor qualification: The vendor is assessed and approved against GxP criteria
Intended use defined: What is expected from the system, in which regulatory context?
GxP criticality classified: What regulatory significance does each function have?
Change control agreed: How are vendor updates handled?
Traceability ensured: Vendor evidence is unambiguously linked to your own risk assessment
Evidence assessment documented: Vendor tests are not adopted unexamined but evaluated

With this setup, qualified supplier evidence can complement or reduce selected in-house assurance activities. The manufacturer remains responsible for the fitness assessment.

Step 5: Continuous Adaptation across the Lifecycle

CSA is not a one-time setup before go-live. After go-live, risk assessments are reviewed at defined intervals and upon significant changes. The interval follows the relevant process and system risk.

For patches, updates or new integration points, the risk profile is reassessed, not the entire system revalidated. This keeps ongoing validation effort low and ensures continuous compliance at the same time.

Governance: The Invisible Prerequisite

CSA only works if IT, QA, business and vendor use the same risk logic. An isolated methodology shift in IT alone does not take hold — the risk assessment must be anchored as a shared evaluation standard across all stakeholders.

In practice, that means a shared risk-assessment standard, clear interface agreements, coordinated change management and regular stakeholder reviews. Where this consensus is missing, CSA generates friction instead of efficiency.

Three Common Misconceptions — and How to Avoid Them

Misconception 1: "CSA means fewer tests."

CSA means more targeted tests. On high-risk-relevant functions, it actually tests deeper — because attention is concentrated there deliberately. Anyone who interprets CSA as a savings programme produces exactly the audit findings the approach is designed to prevent.

Misconception 2: "CSA replaces CSV."

CSA does not replace the demonstration of fitness for intended use. Within direct medical-device production/QMS scope, it describes how to select assurance activities and records based on risk. Pharmaceutical GMP, GCP, GLP or GDP systems outside that scope continue under their applicable CSV and GxP requirements.

Misconception 3: "CSA only applies to the FDA market."

The FDA guidance has a defined US regulatory scope. European GxP rules and GAMP 5 also support risk-based methods, but that does not create a direct CSA obligation for DACH Pharma. Any methodological transfer must be justified within the applicable framework.

What You Can Do Concretely as IT Lead

Three levers, in this order:

First lever: Perform a retrospective risk assessment of one actively validated system. It shows which assurance activities need a new rationale in the next cycle.

Next project cycle: Modernise the URS for the next validation project and connect requirements directly to intended use and process risk.

Portfolio rollout: Build competence and governance. IT, QA, business and suppliers need one shared assessment standard, clear roles and defined change controls.

Frequently Asked Questions

Is CSA suitable for all GxP systems?

No. Direct applicability does not depend on a generic criticality label or product category. It depends on whether the system is used in medical-device production or a quality management system. Other GxP systems may use suitable risk-based methods without thereby entering the FDA CSA scope.

How does CSA relate to GAMP 5 Second Edition?

Very compatible. GAMP 5 Second Edition supports risk-based validation methodologically and aligns well with CSA logic. Both frameworks can be applied in parallel without conflict.

What does the transition to CSA cost?

Effort depends on the maturity of your current validation practice. A strategy call clarifies in 30 minutes where your current validation setup stands and which CSA levers are realistic.

Primary sources

Author

Daniel Herrmann Consulting — boutique consultancy for GxP compliance and Computer System Validation in pharma, biotech and MedTech. 15+ years of hands-on expertise. 60+ validated systems. 100 % audit pass rate. 0 critical findings.