Questions and Answers on CSV Implementation: Insights Incorporating Latest Regulatory Trends

At a recent CSV (Computerized System Validation) seminar, I received the following questions. I would like to share my responses for those who may have similar concerns. This article provides practical guidance based on the latest Computer Software Assurance (CSA) guidance issued by the U.S. FDA (Food and Drug Administration) in September 2025, the requirements of ISO 13485:2016, and the principles of GAMP 5 (Good Automated Manufacturing Practice).

What is CSV: Reconfirming Basic Concepts

CSV is a process that demonstrates computerized systems subject to regulatory oversight are fit for their intended use, accurate, reliable, and produce consistent results. This is not merely bug detection or technical verification, but rather a quality assurance activity to ensure the safety of patients and users.

As a recent regulatory development, the FDA issued the final guidance “Computer Software Assurance for Production and Quality System Software” on September 24, 2025. This guidance supplements the traditional CSV approach and provides a more risk-based and efficient framework for software assurance. This new approach, called “CSA (Computer Software Assurance),” recommends determining the scope and depth of verification activities based on the software’s intended use and risk.

Question 1: Obligation to Create CSV Documentation for Existing Systems

[Question] Must CSV documentation be created retroactively for electronic devices and systems that have already been implemented?

[Answer] Yes, that is correct. CSV, like all quality assurance activities, must be implemented to ensure the safety of patients and users. Therefore, even for electronic devices implemented in the past, CSV must be performed to ensure patient and user safety.

However, if the system has been in use for, say, three years or more without problems, you do not need to perform the same comprehensive CSV as for a new implementation. This is because operational history demonstrates safety and absence of defects. In this case, ensure that operational records (change records, incident response records, maintenance records, etc.) are properly maintained.

Essential Documentation for Existing Systems

Even in this case, the following documents are mandatory:

User Requirements Specification (URS): This is particularly important. CSV confirms that system specifications are fit for the user’s intended use. The URS should clearly describe how the system supports GxP activities and what business requirements it must fulfill.

Validation Plan: Document a plan to confirm that system specifications are fit for the user’s intended use based on past operational performance. It is recommended to include risk assessment of system functions and processes based on a risk-based approach.

Risk Assessment Report: Following the principles of GAMP 5 and ICH Q9 (Quality Risk Management), evaluate the impact of each system function on GxP. Classify each function as “high process risk” or “not high process risk” based on its impact on patient safety, product quality, and data integrity.

Validation Report: Document that there are no issues with quality (fitness for the user’s intended use), quality assurance, and risk management based on past operational performance. By referencing objective evidence such as operational performance data, change history, and incident records, you can demonstrate the system’s continued fitness for purpose.

Application of Risk-Based Approach

For functions assessed as high risk in the risk assessment report, or functions that could directly affect patient safety or product quality, more comprehensive CSV or CSA activities should be implemented. This is consistent with the risk-based approach recommended by GAMP 5 principles and the FDA’s 2025 CSA guidance.

From a CSA perspective, it is important to clearly define the “intended use” of the system and evaluate the impact of each function on production processes or the quality system. Rigorous scripted testing should be applied to high process risk functions, while more flexible exploratory testing or continuous monitoring can be employed for low-risk functions.

Question 2: Optimizing Test Scope According to Risk

[Question] You mentioned that “if something is determined to be low risk, it doesn’t need to be done. Japanese people tend to try to do everything that’s listed.” Could you provide examples of what you think are cases of overdoing validation? I always struggle to make the judgment that something doesn’t need to be done.

[Answer] This is a question about system testing. Note that for systems subject to regulatory requirements, CSV (or CSA) implementation is mandatory regardless of risk level. However, the level of implementation and degree of documentation differ.

Typical Examples of Over-Validation

Examples of overdoing validation include:

Functional Testing of Commercial Off-the-Shelf (COTS) Software Products: There is no need to test the functions themselves of COTS products such as operating systems (OS) like Windows, computer hardware, or analytical instruments (corresponding to GAMP 5 Category 1 or 3). This is because the manufacturer guarantees the quality. For these, it is sufficient to conduct supplier assessment and confirm that the products are from qualified manufacturers.

Detailed Verification of Infrastructure Software: For infrastructure software such as database engines, middleware, and programming languages (GAMP Category 1), testing to the extent that confirms your company’s business processes can be properly executed is sufficient.

Understanding the True Purpose of CSV

The purpose of CSV is solely to confirm that system specifications are fit for the user’s intended use. Since there is no problem as long as business can be conducted according to your company’s SOPs (Standard Operating Procedures), you should conduct testing to the extent that can prove this.

The FDA’s 2025 CSA guidance recommends applying “Critical Thinking” to evaluate how software functions impact product quality and patient safety. Rather than treating all software components the same, assurance activities should be adjusted based on risk analysis.

Examples of Low-Risk Systems

The following types of systems are typically classified as low risk or not high process risk, and simplified verification approaches can be applied:

Training Records Management System: While training records are subject to regulation, even if data becomes corrupted, it does not directly harm patients or users. It is sufficient to confirm that the system can properly store and retrieve training records and generate necessary reports.

Document Management System (DMS): Even if there are bugs in the document management system, the content of stored documents themselves is not altered. Verify that important functions such as document version control, approval workflows, and access control operate normally, and confirm only that there are no operational problems.

Business Intelligence (BI) and Reporting Tools: It is typically sufficient to confirm that these tools can accurately retrieve data from databases and generate reports in the appropriate format. However, more rigorous verification is required when generating critical reports used for regulatory submissions or product release decisions.

Optimizing Test Strategy

Based on GAMP 5 and the FDA’s CSA guidance, the following test strategies are recommended:

Risk Level	Recommended Test Approach	Documentation Level
High Process Risk	Rigorous scripted testing, detailed test cases, traceability matrix	Comprehensive
Moderate Risk	Combination of scripted and exploratory testing	Moderate
Not High Process Risk	Exploratory testing, scenario-based testing, continuous monitoring	Simplified

Question 3: CSV for Records Using Excel Functions

[Question] In our company, quality records using Excel are frequently seen. For example, when manufacturing instructions use functions like VLOOKUP to extract product names based on product numbers, is it necessary to confirm that these functions work correctly and maintain records of this? Or is it not required because it’s a commercial application?

[Answer] CSV is not conducted to eliminate bugs. Therefore, there is no need to test the VLOOKUP function itself and maintain records. Excel is a commercial standard software product (GAMP Category 3), and Microsoft guarantees the quality of its functions.

Validation of GxP Excel Spreadsheets

However, it is necessary to test and maintain records that the relevant manufacturing instructions are created “correctly.” In other words, you need to prove that “what was done manually and what was done electronically produce the same results.”

Specifically, verify the following points:

Data Accuracy: Confirm that when a product number is entered, the correct product name is extracted. Verify using multiple test cases (normal cases, boundary value cases, abnormal cases).

Validity of Calculation Logic: Confirm that the functions and macros being used execute correct calculations that meet business requirements and regulatory requirements. Documentation of calculation logic is also important.

Ensuring Data Integrity: Following ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate + Complete, Consistent, Enduring, Available), verify data attributes. It is important to implement measures such as cell protection, change history recording, and access control to prevent data tampering and erroneous input.

Version Control: Properly manage versions of Excel files and record change history. For critical spreadsheets, it is recommended to apply a change control process.

Category 4 and 5 Excel Spreadsheets

Note that when Excel includes macros or custom programming (VBA, etc.), the system may be classified as GAMP Category 4 (configured system) or Category 5 (custom system). In this case, design specifications for macros, source code reviews, and more comprehensive testing are required. When complex business logic is implemented, verification following a Software Development Life Cycle (SDLC) approach is required.

Addressing Electronic Records and Electronic Signatures

When quality records using Excel are subject to 21 CFR Part 11 (United States) or EU GMP Annex 11 (Europe) requirements for electronic records and electronic signatures, additional controls are necessary:

• Ensuring audit trails
• Implementing access controls
• Data backup and archiving procedures
• Regular review and approval processes

Transition to CSA: A Modern Approach

The FDA’s CSA guidance from September 2025 does not completely replace the traditional CSV approach but supplements and modernizes it. The key principles of CSA are as follows:

1. Clarification of Intended Use

For each software function, clearly define its intended use in production processes or the quality system. Not all functions impact GxP, and this clarification is essential for appropriately determining the scope of verification.

2. Risk-Based Assessment

Evaluate the potential impact of each function on product quality, patient safety, and data integrity. Clearly distinguish between “high process risk” and “not high process risk,” and document the rationale for risk classification.

3. Selection of Appropriate Assurance Activities

Based on risk assessment, combine the following assurance activities:

• Scripted Testing: Conducted for high-risk functions based on detailed test procedures
• Unscripted Testing: Exploratory testing, scenario-based testing, ad hoc testing, etc.
• Continuous Monitoring: Regular review of system logs, audit trails, and performance metrics
• Leveraging Supplier Evidence: Utilize evidence from suppliers such as certifications, accreditations, SDLC documentation, and cybersecurity measures

4. Efficient Documentation

The CSA guidance recommends utilizing digital records (system logs, audit trails, automated traceability). There is no need to rely excessively on paper-based documentation or screenshots, and the verification process can be streamlined by using appropriate electronic evidence.

5. Lifecycle Approach

Maintain continuous assurance throughout the software lifecycle. Particularly for SaaS (Software as a Service) and cloud-based systems, risk-based regression testing can be applied to automatic updates, avoiding complete revalidation.

CSV/CSA for Cloud and SaaS Systems

Modern technologies such as cloud computing, IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service) are also subject to verification when used as part of production or quality systems.

Key Considerations for SaaS Systems

Service Agreement Review: Ensure service agreements covering security, data integrity, change management, backup and recovery, and Service Level Agreements (SLA).

Supplier Assessment: Evaluate the capabilities of SaaS suppliers. Verify certifications (ISO 27001, SOC 2, etc.), SDLC processes, and data center security.

Data Security and Privacy: Verify data encryption, access control, data ownership, and regulatory compliance (GDPR, HIPAA, etc.).

Change Management: When automatic updates by SaaS suppliers may affect intended use, implement risk-based assurance activities. Complete revalidation is not required for all updates; determine the scope of regression testing based on risk assessment.

Validation Strategy for Cloud Systems

For cloud-based systems, the traditional IQ (Installation Qualification), OQ (Operational Qualification), and PQ (Performance Qualification) approach may not be appropriate. Instead, a combination of testing based on intended use and continuous monitoring is recommended.

21 CFR Part 11 and Data Integrity

When using electronic records and electronic signatures, requirements of 21 CFR Part 11 (United States) and EU GMP Annex 11 (Europe) must be met. The CSA guidance recommends applying Part 11 requirements with a risk-based approach.

Key Requirements of Part 11

System Validation: When electronic records are created and maintained under rules requiring electronic records (e.g., 21 CFR Part 820), Part 11 generally applies. However, for validation of production or quality system software, a CSA risk-based approach can be used.

Audit Trail: Ensure independent, computer-generated, time-stamped audit trails for the creation, modification, and deletion of electronic records.

Record Integrity: Implement procedures and controls to ensure that records are accurate, complete, reliable, and consistent.

Data Integrity Principles

Ensure data integrity following ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, Available).

Practical Recommendations

Phased Approach

When implementing CSV or CSA, the following phased approach is recommended:

Step 1: Inventory and Scoping Create an inventory of all computerized systems and assess their GxP impact. Identify systems used as part of production or the quality system.

Step 2: Risk Classification Evaluate functions of each system based on intended use and classify as high process risk or not high process risk. Document the rationale for risk classification.

Step 3: Develop Validation Strategy Based on risk classification, determine appropriate assurance activities (scripted testing, unscripted testing, continuous monitoring, leveraging supplier evidence, etc.).

Step 4: Implementation and Documentation Implement verification activities and maintain an appropriate level of documentation. Utilize digital records and avoid unnecessary paper-based documentation.

Step 5: Ongoing Maintenance Maintain the validated state of systems through change control, periodic reviews, and incident management.

Organizational Culture Change

Transition to CSA requires not just technical changes but organizational culture transformation. It is important to foster a culture of critical thinking, risk-based decision making, and continuous improvement. Not only the quality department, but all relevant departments including IT, manufacturing, and regulatory affairs must collaborate in CSA activities.

Preparation for Audits

In regulatory inspections, the following points are emphasized:

• Rationale and logical consistency of risk classification
• Appropriateness of assurance activities based on risk
• Transparency and documentation of decision-making processes
• Effectiveness of supplier management
• Appropriateness of data integrity controls

Prepare to clearly explain the rationale for risk assessments, validation strategies, and implemented assurance activities in preparation for audits.

Conclusion

CSV (and CSA) is an important quality assurance activity to ensure the safety of patients and users. By properly applying a risk-based approach, validation resources can be concentrated in high-risk areas while simplified approaches can be adopted in low-risk areas.

By following the latest regulatory requirements and guidelines such as the FDA’s CSA guidance from September 2025, ISO 13485:2016, and GAMP 5, an efficient and effective verification process can be established. The key is to clearly understand the system’s intended use, assess risk based on impact on patient safety, product quality, and data integrity, and select appropriate assurance activities.

The transition from the traditional rigid, documentation-focused approach to a risk-based, flexible CSA approach enables innovation, accelerates adoption of new technologies, and ultimately allows for delivering higher quality products to patients more quickly. Organizations should view this transformation not merely as a regulatory compliance issue, but as an opportunity for quality improvement and enhanced competitiveness.