Computerized system validation (CSV) practices continue to evolve as life sciences organizations look for more risk-based ways to establish that software is fit for its intended use. The goal is not simply to reduce testing or documentation, but to focus assurance activities and evidence where they provide the most value based on intended use and risk.
Computer software assurance (CSA) has become an important part of that discussion. The FDA’s CSA guidance applies specifically to computers and automated data processing systems used in medical device production and quality management systems. While that guidance has a specific regulatory scope, its emphasis on critical thinking, intended use, and risk-based assurance aligns with broader risk-based validation practices reflected in frameworks such as GAMP 5 Second Edition.
These FAQs distinguish the FDA's CSA guidance from broader validation practices while addressing practical questions about CSV, risk-based assurance, testing, documentation, traceability, and digital validation.
Understanding CSV and CSA
What is the difference between CSV and CSA?
CSV is the established practice of validating computerized systems to provide confidence that they are fit for their intended use and meet applicable requirements. Risk-based approaches are already an important part of modern CSV, particularly under frameworks such as GAMP 5 Second Edition.
CSA places additional emphasis on critical thinking and using risk to determine the appropriate assurance activities for software features, functions, and operations. Rather than applying the same level of testing and documentation across the board, assurance activities should be proportionate to intended use and risk.
Is CSA replacing CSV?
No. CSA does not eliminate the need to validate computerized systems or establish that software is fit for its intended use. It provides a risk-based approach for determining how assurance activities should be applied. In practice, the distinction is less about replacing validation and more about avoiding unnecessary testing and documentation while applying appropriate rigor where risk warrants it. Scripted testing, for example, remains appropriate when additional rigor is needed, while other testing approaches may be suitable depending on intended use and risk.
Risk-Based Testing and Assurance
How does CSA change the approach to software testing?
CSA uses intended use and risk to determine the appropriate assurance activities for software features, functions, and operations. Instead of applying the same testing approach to every area, teams can use different levels of rigor and different testing methods based on the potential impact of failure. This can include scripted, unscripted, or hybrid testing approaches. The objective is to select an approach that provides sufficient confidence that the software performs as intended for the identified risk.
Why is intended use important in risk-based validation?
Intended use establishes what the software is expected to do and provides context for evaluating risk. Without a clear understanding of how a system will be used, teams cannot effectively determine what could go wrong, what the consequences might be, or what level of assurance is appropriate. Intended use also helps inform requirements, risk decisions, and assurance activities throughout the validation lifecycle. The level of effort, formality, and documentation should be proportionate to intended use and risk.
Does CSA mean less testing?
Not necessarily. CSA uses intended use and risk to determine the appropriate level of testing and other assurance activities. Greater assurance rigor is appropriate where a software failure could compromise product quality or safety, while the level of effort and evidence may be streamlined for lower-risk uses. The testing approach should provide sufficient assurance for the identified risk.
Can CSA include unscripted testing?
Yes. FDA's CSA guidance recognizes scripted, hybrid, and unscripted testing as assurance approaches that may be selected based on intended use and risk.
Unscripted testing does not mean uncontrolled testing. Testers use their knowledge of intended use, system behavior, previous results, and risk to determine how best to evaluate the software, while still documenting sufficient objective evidence to support the outcome. FDA states that unscripted testing may be appropriate even for high-process-risk functions, while scripted testing may sometimes be effective for lower-risk functions. The methods should not be presented as a simple hierarchy of rigor.
What is the difference between scripted and unscripted testing?
Scripted testing defines test cases, expected results, and required objective evidence before execution. The appropriate level of detail, review, approval, repeatability, traceability, and auditability should reflect the software's intended use and associated risk.
Unscripted testing gives qualified testers greater flexibility to determine how to evaluate the software based on intended use, system behavior, previous results, and risk. The results still need to be supported by sufficient objective evidence. A hybrid approach can combine elements of scripted and unscripted testing when appropriate.
How does risk affect the level of assurance needed?
Risk should inform the level of effort, formality, and documentation applied to validation activities. Greater rigor may be appropriate where software failure could affect product quality, patient safety, data integrity, or process integrity. This does not mean that risk simply determines how many documents or test scripts to produce. Risk should help teams determine which assurance activities are appropriate and how much rigor is needed to establish confidence that the software performs as intended.
Is risk assessment a one-time validation activity?
No. Risk management should continue throughout the life of a computerized system. Systems and processes change, technology evolves, and new risks can emerge after the initial assessment. As a result, risk should be reevaluated when relevant changes or new information could affect previous risk decisions or controls. Treating risk assessment only as an early project activity can leave organizations relying on conclusions that no longer reflect the system's current state.
Documentation and Objective Evidence
Does CSA eliminate documentation?
No. CSA does not eliminate documentation or the need for objective evidence. Instead, documentation should be appropriate to the software’s intended use, risk, and assurance activities. The goal is to retain sufficient evidence to demonstrate that the software performs as intended without creating documentation that does not contribute meaningful assurance.
What objective evidence should be retained?
Objective evidence should be sufficient to demonstrate that the software feature, function, or operation was appropriately evaluated and performed as intended for the identified risk. The type and amount of evidence will depend on the assurance activity, testing method, intended use, and associated risk.
FDA generally recommends documenting the intended use, the result of the risk-based analysis, the assurance activities performed, issues identified, the conclusion regarding acceptability, the person who performed the assessment and the date, and review and approval when appropriate. Evidence may include test results and electronically generated records that demonstrate the outcome. The emphasis should be on whether the evidence adequately supports the result, not on collecting a particular volume of documentation.
Can system-generated records be used as objective evidence?
Yes. System-generated records, such as audit trails and other electronic records, can provide objective evidence when they meaningfully demonstrate the activity performed and its outcome. The existence of a system-generated record alone does not make it sufficient evidence; its relevance and adequacy should be considered in the context of the assurance activity and associated risk.
Requirements, Risk, and Traceability
What role do requirements play in a risk-based assurance approach?
Requirements help define what a computerized system must do to support its intended use. Clear requirements provide a basis for identifying which functions are important, evaluating the risks associated with those functions, and determining appropriate assurance activities. In a risk-based approach, not every requirement necessarily warrants the same level of testing or documentation. The assurance applied should reflect the requirement's intended use, potential impact, and associated risk.
How can traceability support risk-based software assurance?
Traceability can connect requirements, risk decisions, testing, and objective evidence so teams can understand how assurance activities address identified risks. This helps demonstrate why particular activities were performed and provides a clearer record of the evidence supporting validation decisions.
Traceability can also help teams evaluate the effect of changes by showing which requirements, risks, tests, and evidence may be affected.
Adopting a CSA Approach
What challenges can organizations encounter when adopting CSA?
Organizations adopting CSA may need to adjust established validation practices, procedures, and expectations. Teams accustomed to highly prescriptive testing and documentation may need guidance on applying critical thinking, making risk-based decisions, selecting appropriate assurance activities, and documenting the rationale for those decisions. The transition may also require alignment across quality, validation, IT, business, and other stakeholders so that risk-based practices are understood and applied consistently.
How can organizations begin adopting a CSA approach?
Organizations can begin by evaluating existing validation practices to identify where testing and documentation may not be proportionate to intended use and risk. From there, they can establish clear criteria for making risk-based decisions, determine which assurance approaches are appropriate for different circumstances, and update procedures and training as needed.
A phased approach can allow teams to apply these practices in a defined area, evaluate the results, and use what they learn to refine the approach before expanding it more broadly.
Can a CSA approach work with agile software delivery?
Yes. Risk-based assurance can be incorporated into iterative software development when validation activities, risk decisions, testing, and change control remain appropriately managed and traceable. Rather than treating validation as a separate activity performed only after development is complete, assurance activities can progress alongside development as requirements and software evolve.
Supporting Risk-Based Assurance With Digital Validation
How can a digital validation platform support risk-based software assurance?
A digital validation platform can help connect requirements, risk assessments, assurance activities, testing, objective evidence, deviations, and change records within controlled workflows. Bringing these activities together can make it easier to maintain traceability, apply risk-based decisions consistently, and understand how changes affect related validation records.
Digital workflows can also support lifecycle management by making relationships among requirements, risks, testing, evidence, and changes more visible than when those records are maintained across disconnected documents and systems.
Can organizations support both established CSV processes and CSA-aligned assurance activities in the same digital environment?
Yes. A digital validation environment can support different assurance approaches when its workflows allow organizations to apply the appropriate level of rigor based on intended use, risk, and applicable procedures. This can include established CSV practices alongside more flexible risk-based assurance approaches without requiring every system or validation activity to follow an identical process. The key is maintaining appropriate control, traceability, and objective evidence regardless of the assurance approach selected. ValGenesis iVal supports these approaches within the same digital environment while maintaining control, traceability, and objective evidence.
How does ValGenesis iVal support risk-based software assurance?
ValGenesis iVal connects requirements, risk assessment, assurance selection, testing, execution evidence, deviations, and change records within controlled, traceable workflows. Configurable scoring logic, risk models, and business rules can be used to assess risk and help determine the appropriate assurance approach and level of rigor.
iVal also supports traceability from user and functional requirements through test cases, execution evidence, deviations, and associated change records while supporting fit-for-purpose assurance approaches. This allows validation activities and their supporting evidence to remain connected as systems and requirements change.
CSV and CSA do not have to be viewed as competing approaches. Both can support the same fundamental objective: providing confidence that computerized systems are fit for their intended use. Across the broader GxP environment, risk-based validation helps organizations focus testing, documentation, and assurance activities where they matter most while maintaining lifecycle control, traceability, and sufficient objective evidence.
Table of Contents
