Understanding “User” in Computer System Validation: Regulatory Perspectives and Modern Approaches

Introduction: The Ambiguity of “User” in CSV Context

In the implementation of Computer System Validation (CSV), the term “user” appears frequently in regulatory guidance, industry standards, and validation documentation. However, this seemingly simple term carries considerable ambiguity that can lead to misunderstandings about roles, responsibilities, and accountability in computerized system validation. This ambiguity has significant implications for compliance, particularly regarding who should create critical validation documents such as User Requirements Specifications (URS) and who should perform User Acceptance Testing (UAT).

The confusion stems from the fact that “user” can be interpreted at multiple organizational levels. At the broadest level, pharmaceutical and medical device manufacturing companies are considered “user companies” as opposed to “supplier companies” that provide systems and services. However, this company-level designation is far too broad to be useful in defining validation responsibilities. At the individual level, an operator who performs data entry in a Laboratory Information Management System (LIMS) or a quality control analyst who reviews analytical results is also called a “user.” Between these extremes lie multiple other interpretations, including departmental users, system administrators, and quality assurance personnel who oversee system compliance.

This article examines the regulatory definition of “user” in the context of CSV, with particular focus on the concept of “regulated user” as defined in international guidance documents. We explore the implications of this definition for validation activities, particularly the creation of User Requirements Specifications and the execution of User Acceptance Testing. The discussion incorporates recent regulatory developments, including the FDA’s Computer Software Assurance (CSA) guidance finalized in September 2025, the GAMP 5 Second Edition published in July 2022, and the draft revision of PIC/S GMP Annex 11 issued in July 2025.

The Concept of “Regulated User” in PIC/S GMP Annex 11

Current Version (2011) Requirements

PIC/S GMP Annex 11 “Computerised Systems,” which has been in effect since June 2011, uses the term “regulated user” in several critical contexts. It is important to note that PIC/S GMP Annex 11 has been adopted by numerous regulatory authorities worldwide, including the European Union, Japan, South Korea, Australia, and New Zealand, making it a globally influential document for computerized system compliance.

The current Annex 11 contains specific references to regulated users in two key sections:

Section 3.3 – Suppliers and Service Providers: “Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled.”

Section 4.5 – Validation: “The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately.”

These references establish that the regulated user has distinct responsibilities that extend beyond simply operating the system. The regulated user must actively oversee vendor relationships, review documentation, assess supplier quality systems, and ensure that systems are developed and maintained in accordance with appropriate quality standards.

Defining the “Regulated User”

A critical distinction must be made: the regulated user is not the individual operator who physically interacts with the computerized system on a daily basis. Rather, the regulated user is the organizational entity or designated individual(s) responsible for ensuring compliance with regulatory requirements for the business operation or process in question.

The regulated user typically encompasses:

1. Quality Assurance/Quality Unit representatives who have oversight responsibility for ensuring GMP compliance
2. Process owners who are responsible for the business process that the computerized system supports
3. System owners who are responsible for the system’s availability, maintenance, and security
4. Validation personnel who plan, execute, and document validation activities
5. Subject matter experts who understand both the business requirements and the regulatory constraints

This interpretation aligns with the broader regulatory framework established in EU GMP Chapter 4 (Documentation) and various FDA guidance documents. The regulated user represents the company’s accountability for ensuring that computerized systems are fit for intended use and maintain patient safety, product quality, and data integrity.

It is instructive to contrast this with the definition of “Process Owner” and “System Owner” provided in the Annex 11 Glossary:

• Process Owner: The person responsible for the business process
• System Owner: The person responsible for the availability and maintenance of a computerized system and for the security of the data residing on that system

The regulated user concept encompasses both of these roles and extends to include quality oversight and regulatory compliance responsibilities. The regulated user is not defined by whether they physically use the system, but rather by their accountability for ensuring the system meets regulatory requirements.

Evolution: Draft Annex 11 (July 2025)

The draft revision of PIC/S GMP Annex 11, published for stakeholder comment in July 2025, represents a significant modernization effort to address technological advances and regulatory developments since 2011. This revision reflects the extensive progress in cloud computing, artificial intelligence, agile development methodologies, and data integrity expectations over the intervening 14 years.

Key changes relevant to the regulated user concept include:

1. Enhanced Data Integrity Requirements: The draft incorporates ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, and Available) explicitly, emphasizing the regulated user’s responsibility for ensuring trustworthy data throughout its lifecycle.
2. Cloud Service Provider Oversight: The draft addresses the increasing use of cloud-based systems (Infrastructure as a Service, Platform as a Service, and Software as a Service), specifying that regulated users must maintain access to validation documentation and system operation documentation for systems operated by cloud service providers.
3. Alternative Practices Recognition: The draft acknowledges that as technology evolves, regulated users may develop novel methods for validation and operation. Such methods must demonstrate equivalent or superior risk control compared to traditional approaches.
4. Critical Thinking and Risk-Based Approach: The draft emphasizes that regulated users must apply critical, patient-centered, risk-based thinking to all decisions regarding computerized systems, moving away from one-size-fits-all validation approaches.
5. Agile Development Methods: The draft explicitly recognizes modern software development approaches, including iterative and incremental methods, requiring regulated users to adapt their oversight and validation strategies accordingly.

The draft revision maintains and strengthens the concept that regulated users bear ultimate responsibility for ensuring computerized systems meet regulatory requirements, regardless of whether systems are operated internally or by third-party service providers. This is particularly relevant as pharmaceutical companies increasingly adopt cloud-based quality management systems, electronic batch record systems, and advanced analytics platforms.

User Requirements Specifications: Authorship and Responsibility

Traditional Understanding and Common Misconceptions

When implementing CSV according to GAMP 5 and regulatory expectations, a User Requirements Specification (URS) is a fundamental deliverable that defines what the system must do to meet business and regulatory needs. Many practitioners intuitively understand that the URS should be created “by users,” but as noted previously, the term “user” lacks precision.

A common misconception is that individual operators—those who will perform daily data entry, sample login, or batch execution tasks—should be responsible for writing the URS. This interpretation is problematic for several reasons:

1. Technical Expertise Gap: Operational users may lack the technical knowledge required to specify system requirements in a structured, testable manner.
2. Regulatory Knowledge Limitations: Individual operators may not fully understand the regulatory requirements (21 CFR Part 11, EU GMP Annex 11, data integrity principles) that the system must satisfy.
3. Cross-Functional Requirements: A comprehensive URS must address not only operational workflows but also quality assurance, IT infrastructure, data management, and business continuity requirements that extend beyond any single operator’s purview.
4. Organizational Accountability: Regulatory authorities expect companies to demonstrate that validation activities are planned and executed under appropriate quality oversight, not delegated entirely to operational personnel.

The Regulated User as URS Author

It is the regulated user—as defined in the organizational sense described above—who should be responsible for creating (or at least owning and approving) the URS. This responsibility typically manifests through a cross-functional team approach:

Core URS Development Team typically includes:

1. Quality Assurance/Validation Lead: Ensures the URS addresses all regulatory requirements and follows the company’s validation standards
2. Process Owner/Subject Matter Expert: Defines the business and operational requirements based on process needs
3. IT/System Owner: Contributes technical requirements and ensures integration with existing infrastructure
4. Operational Representatives: Provide input on usability requirements and workflow needs
5. Data Integrity Specialist: Ensures ALCOA+ principles are addressed in system requirements

This cross-functional approach ensures that the URS is comprehensive, technically sound, regulatory compliant, and operationally feasible. The regulated user, through this team structure, maintains accountability while leveraging appropriate expertise from across the organization.

GAMP 5 Second Edition Perspective on Requirements

The GAMP 5 Second Edition, published by ISPE in July 2022, significantly updated the guidance on specifying requirements. One of the most notable changes is the consolidation of separate appendices for User Requirements Specifications (URS) and Functional Requirements Specifications (FRS) into a single Appendix D1 titled “Specifying Requirements.”

Key concepts from GAMP 5 Second Edition Appendix D1:

1. Flexible Documentation Approach: Requirements can be maintained in appropriate management tools or in traditional documents, depending on the development methodology (Agile vs. V-Model). The focus is on ensuring requirements are clear, testable, and traceable, not on prescriptive document formats.
2. Risk-Based Categorization: All requirements should be categorized and prioritized based on their criticality to patient safety, product quality, and data integrity. This allows validation efforts to focus on high-risk functionality.
3. Agile Methods Integration: The guide explicitly supports iterative and incremental development approaches, where requirements may evolve through discovery rather than being completely defined upfront. This represents a significant shift from traditional waterfall approaches.
4. Critical Thinking Emphasis: The Second Edition introduces a new appendix (M12) on critical thinking, encouraging regulated users to apply patient-centered, risk-based reasoning rather than blindly following prescriptive validation templates.
5. Avoid Over-Documentation: The guidance cautions against excessive documentation, including unnecessary screenshots for every function. The principle is to “test and document what is needed to add value.”

These updates recognize that requirements specification is not solely about creating perfect documents before development begins, but rather about maintaining clear, traceable, and appropriately detailed requirements throughout the system lifecycle in a manner commensurate with risk.

URS Content and Structure

A well-structured URS in accordance with current regulatory expectations and GAMP 5 Second Edition should address the following categories of requirements:

Table 1: Categories of User Requirements

Requirement Category	Description	Examples
Functional Requirements	What the system must do to support business processes	Data acquisition, calculations, reporting, workflow automation
Data Integrity Requirements	Controls ensuring ALCOA+ principles	Audit trails, electronic signatures, access controls, data backup
Regulatory Compliance Requirements	Specific regulatory requirements the system must meet	21 CFR Part 11 requirements, EU GMP Annex 11 requirements, patient safety controls
Integration Requirements	How the system interfaces with other systems	Data exchange formats, integration protocols, master data management
Infrastructure Requirements	Technical platform and performance needs	Server specifications, network requirements, response times, availability targets
Security Requirements	Protection against unauthorized access and cyber threats	Authentication methods, encryption, network security, disaster recovery
Usability Requirements	User interface and workflow considerations	Training requirements, error handling, accessibility features

The extent and detail of requirements should be commensurate with the system’s risk, complexity, and novelty. A simple commercial off-the-shelf (COTS) application for non-critical functions may have a relatively brief URS, while a custom-developed manufacturing execution system for sterile drug product manufacturing would require extensive, detailed requirements across all categories.

User Acceptance Testing: Who Should Perform UAT?

Defining User Acceptance Testing in the Regulated Context

User Acceptance Testing (UAT) serves as the regulated user’s final, business-led verification that a configured or developed system is fit for intended use before go-live. UAT differs fundamentally from other testing phases:

Table 2: Comparison of Testing Phases

Testing Phase	Primary Purpose	Typical Responsibility	Focus
Unit Testing	Verify individual code modules function correctly	Developer/Vendor	Technical correctness of code components
Integration Testing	Verify system components work together	Developer/Vendor/IT	Technical integration and data flow
System Testing (OQ)	Verify system meets functional specifications	Vendor/Validation Team	System functionality against specifications
User Acceptance Testing (UAT)	Verify system meets business needs and is usable	Regulated User/Business Process Owner	Fitness for intended use in real workflows

UAT is distinct because it evaluates the system from the perspective of actual business operations under GMP conditions. It verifies that trained users can execute end-to-end processes, generate compliant records, and operate the system according to approved procedures in their actual work environment.

The Regulated User as UAT Performer

Following the logic established for URS authorship, it is the regulated user who should perform—or at minimum, own and approve—UAT activities. This does not necessarily mean that individual operators cannot participate in UAT execution, but rather that regulated user representatives must design, oversee, and accept the results of UAT.

Typical UAT Execution Model:

1. UAT Planning and Script Development: Led by Quality Assurance/Validation personnel in collaboration with process owners. Test scripts are based on URS requirements and real operational scenarios.
2. Test Execution: Performed by trained operational users under observation by validation personnel. This ensures that UAT reflects real-world usage patterns while maintaining documentation rigor.
3. Deviation Management: Any failures, unexpected behaviors, or deviations from expected results are documented and assessed by the regulated user team for criticality and impact.
4. Acceptance Decision: The regulated user (typically Quality Assurance in conjunction with process owners) makes the formal determination that the system is acceptable for use based on UAT results.

GAMP 5 Second Edition and Modern Testing Approaches

The GAMP 5 Second Edition introduces significant flexibility in testing approaches, which has implications for UAT:

1. Unscripted Testing: For lower-risk functionality, the guide explicitly endorses unscripted or exploratory testing approaches. This allows UAT to be more efficient and realistic, focusing on critical thinking about what could go wrong rather than mechanically executing predetermined scripts.
2. Test Coverage Based on Risk: Rather than attempting to test every possible system function exhaustively, UAT should focus on high-risk functions that could impact product quality, patient safety, or data integrity. A risk-based test coverage matrix maps critical requirements to appropriate test methods.
3. Leverage Vendor Evidence: For commercial systems, regulated users can leverage vendor testing documentation, validation packages, and third-party certifications to reduce redundant testing. UAT then focuses on verifying that the system works as configured for the company’s specific use case.
4. Continuous Assurance: Rather than viewing validation as a one-time event, modern approaches emphasize ongoing assurance through monitoring, periodic review, and continuous verification. This aligns with the concept of continuous manufacturing and digital transformation initiatives.

UAT in the Context of FDA Computer Software Assurance (2025)

The FDA’s Computer Software Assurance (CSA) guidance, finalized on September 24, 2025, represents a paradigm shift from traditional Computer System Validation (CSV) to a more flexible, risk-based assurance model. While this guidance is specifically directed at medical device manufacturers for production and quality system software, its principles are instructive for pharmaceutical CSV as well and indicate the direction of regulatory thinking.

Key CSA Principles Relevant to UAT:

1. Focus on Intended Use: Validation efforts, including testing, should be scaled based on the software’s intended use and the risk it poses to product quality and patient safety. Not all functionality requires the same testing rigor.
2. Risk-Based Testing Methods: The guidance explicitly endorses multiple testing approaches:
   • Scripted testing for high-risk functions
   • Unscripted/exploratory testing for moderate-risk functions
   • Vendor evidence and continuous monitoring for low-risk functions
3. Agile and Iterative Approaches: CSA recognizes modern software development practices, including agile methodologies, continuous integration/continuous deployment (CI/CD), and cloud-based automatic updates. UAT in such environments may be iterative rather than a single gate event.
4. Digital Evidence: The guidance encourages using system-generated logs, audit trails, and automated verification rather than manual documentation like screenshots. This makes UAT more efficient and creates more reliable evidence.
5. Least Burdensome Principle: The goal is to establish appropriate confidence in the software without unnecessary documentation burden. UAT should be sufficient to demonstrate fitness for use, not exhaustive to the point of diminishing returns.

These principles suggest that modern UAT should be:

• Targeted at critical functionality based on risk assessment
• Executed using appropriate methods matched to risk level
• Documented efficiently using system-generated evidence where possible
• Part of an ongoing assurance strategy rather than a one-time event

Practical UAT Execution Considerations

UAT Scope Determination:

The scope of UAT should be determined by a risk assessment that considers:

1. Process Risk: What is the impact if this function fails? (Product quality, patient safety, data integrity, regulatory compliance)
2. Functional Complexity: How complex is the function? Complex algorithms, calculations, or workflows require more testing.
3. Novelty: Is this a standard function in a mature commercial product, or custom-developed functionality? Novel functions require more rigorous testing.
4. Integration Points: Functions that exchange data with other systems typically require interface-specific testing.
5. Regulatory Visibility: Functions that generate records for regulatory submission, batch release, or audit trail activities require careful testing.

UAT Test Case Design:

Effective UAT test cases should:

1. Reflect Real Workflows: Test cases should mirror how users will actually perform their jobs, using realistic data and scenarios.
2. Cover Positive and Negative Cases: Test both expected successful operations and error conditions, boundary cases, and system responses to invalid inputs.
3. Verify Data Integrity Controls: Explicitly test audit trail generation, electronic signature functionality, access controls, and data backup/recovery.
4. Include Integration Scenarios: For systems that exchange data with other systems, test end-to-end data flow and reconciliation.
5. Challenge Critical Calculations: For systems that perform critical calculations (potency, dosing, statistical analysis), include challenge tests with known inputs and expected outputs.

UAT Documentation:

In accordance with current regulatory expectations and best practices:

1. Test Protocol: Documents the UAT plan, scope, test environment, roles and responsibilities, and acceptance criteria.
2. Test Scripts/Cases: Specific procedures or scenarios to be executed, with sufficient detail for reproducibility but avoiding over-documentation.
3. Test Evidence: Results of test execution, including screenshots, system-generated reports, audit trail extracts, or log files as appropriate.
4. Deviation/Issue Log: Documentation of any failures, unexpected results, or system issues encountered during UAT, with impact assessment and resolution.
5. UAT Summary Report: Final assessment of UAT results, confirmation that acceptance criteria were met, and approval for system release.

Modern Perspectives: Risk-Based and Agile Approaches

Integration of Risk Management Throughout the Lifecycle

Current regulatory guidance emphasizes Quality Risk Management (QRM) as the foundation for all validation decisions. This approach, codified in ICH Q9 (Quality Risk Management), requires that decisions about validation scope, testing depth, and documentation level be based on a justified and documented risk assessment.

For the regulated user, this means:

1. Risk-Based URS: Requirements should be categorized by criticality (critical, major, minor) based on their impact on patient safety, product quality, and data integrity. Validation efforts focus on critical requirements.
2. Risk-Based Testing: UAT test coverage should be proportional to risk. High-risk functions receive extensive testing with multiple scenarios, while low-risk functions may receive basic verification or rely on vendor testing.
3. Risk-Based Documentation: The level of documentation detail should match the risk level. Critical functions require comprehensive documentation, while routine functions may have streamlined documentation.
4. Ongoing Risk Review: As systems evolve through changes and upgrades, risk assessments should be revisited to ensure validation strategies remain appropriate.

Agile Development and Continuous Validation

Traditional CSV approaches based on the V-Model assume that requirements are fully defined upfront, development follows a linear path, and validation occurs as a gate event before release. However, modern software development increasingly uses Agile methodologies characterized by:

1. Iterative Development: Systems are built in short sprints with frequent releases of working software.
2. Evolving Requirements: Requirements emerge and are refined through user feedback and experience.
3. Continuous Integration: Code changes are continuously integrated and automatically tested.
4. Automated Testing: Regression testing is largely automated to enable frequent releases.

The regulated user in an Agile environment must adapt their approach:

Table 3: Adapting Validation to Agile Development

Traditional Approach	Agile-Compatible Approach
Complete URS before development	Living requirements backlog, refined iteratively
Formal change control for every requirement change	Risk-based change control; minor changes managed within sprint
Validation as a gate event before release	Continuous validation integrated into sprint activities
Comprehensive test protocols executed once	Core test suite automated; risk-based manual testing each sprint
Annual periodic review	Continuous monitoring and frequent reassessment

The key is maintaining regulatory principles (patient safety, product quality, data integrity) while allowing development methodology flexibility. The regulated user ensures that appropriate controls exist, that critical functionality is verified before use, and that the system remains in a validated state throughout its lifecycle.

Cloud Computing and Software as a Service (SaaS)

The increasing adoption of cloud-based systems presents unique considerations for the regulated user. The FDA CSA guidance, GAMP 5 Second Edition, and draft PIC/S Annex 11 all explicitly address cloud computing, recognizing its prevalence and unique challenges.

Regulated User Responsibilities for Cloud/SaaS Systems:

1. Vendor Assessment: Comprehensive evaluation of the cloud service provider’s quality management system, security controls, business continuity, and change management processes.
2. Service Level Agreements (SLA): Clear contractual terms regarding system availability, data ownership, data integrity controls, audit rights, and disaster recovery.
3. Validation Strategy: Determination of which validation activities are the vendor’s responsibility (platform qualification) versus the regulated user’s responsibility (configuration verification, UAT).
4. Data Integrity Controls: Verification that cloud systems implement appropriate audit trails, access controls, data backup, and protection against data loss or corruption.
5. Change Management Visibility: Mechanisms to be notified of vendor updates and to assess their impact, even for automatic updates common in SaaS models.
6. Business Continuity: Understanding and testing of disaster recovery procedures, including data restoration and system availability during outages.

The regulated user cannot delegate ultimate responsibility for GMP compliance to a cloud service provider. Even when using fully validated commercial cloud systems, the regulated user must verify that the system, as configured and used, meets regulatory requirements and business needs.

Conclusion: The Regulated User’s Central Role in Modern CSV

The ambiguity of the term “user” in Computer System Validation discussions can lead to significant misunderstandings about roles and responsibilities. This article has established that the concept of “regulated user” as defined in PIC/S GMP Annex 11 and other regulatory guidance refers not to individual operators but to the organizational entity responsible for ensuring regulatory compliance of computerized systems.

Key Conclusions:

1. The Regulated User is Organizationally Responsible: The regulated user encompasses quality assurance, process ownership, system ownership, and validation personnel who collectively ensure that computerized systems meet regulatory requirements and business needs.
2. URS Creation is a Regulated User Responsibility: While individual operators provide valuable input on operational requirements, the formal responsibility for creating, reviewing, and approving the User Requirements Specification rests with the regulated user organization, typically through a cross-functional team.
3. UAT Must Be Performed by the Regulated User: User Acceptance Testing is the regulated user’s final verification that a system is fit for intended use. While operational users participate in test execution, the regulated user owns the UAT strategy, design, execution oversight, and acceptance decision.
4. Modern Approaches Require Adaptation: Recent regulatory developments, including FDA CSA (2025), GAMP 5 Second Edition (2022), and draft PIC/S Annex 11 (2025), emphasize risk-based approaches, critical thinking, agile methodologies, and continuous assurance. The regulated user must adapt validation strategies while maintaining core regulatory principles.
5. Technology Evolution Demands Ongoing Vigilance: Cloud computing, SaaS platforms, artificial intelligence, and continuous deployment models require the regulated user to continuously evaluate and update their oversight and validation approaches.

The regulatory landscape is shifting from prescriptive, document-heavy validation toward risk-based, efficient assurance models that accommodate modern software development and deployment practices. Throughout this evolution, however, the fundamental principle remains unchanged: the regulated user bears ultimate responsibility for ensuring that computerized systems are fit for intended use, maintain patient safety, ensure product quality, and protect data integrity.

For pharmaceutical and medical device companies implementing or maintaining computerized systems, clarity about the regulated user’s role and responsibilities is essential. This clarity enables appropriate organizational structures, clear accountability, effective vendor management, and validation strategies that are both compliant and efficient. As regulatory expectations continue to evolve, the regulated user’s central role in computer system validation will remain constant, even as the specific approaches and methodologies adapt to technological innovation and regulatory modernization.

References

American Society for Testing and Materials. ASTM E2500-13: Standard Guide for Specification, Design, and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and Equipment. 2013.

European Commission. EudraLex Volume 4 – Good Manufacturing Practice (GMP) Guidelines, Annex 11: Computerised Systems. 2011.

PIC/S. PE 009-15 (Part III) – Guide to Good Manufacturing Practice for Medicinal Products, Annexes. Pharmaceutical Inspection Co-operation Scheme. 2011.

European Medicines Agency (EMA) / PIC/S. Draft Annex 11: Computerised Systems. July 2025.

U.S. Food and Drug Administration. Computer Software Assurance for Production and Quality System Software – Guidance for Industry and FDA Staff. September 24, 2025.

International Society for Pharmaceutical Engineering (ISPE). GAMP 5 Second Edition: A Risk-Based Approach to Compliant GxP Computerized Systems. July 2022.

International Conference on Harmonisation (ICH). ICH Q9: Quality Risk Management. 2005 (revised 2023).

U.S. Food and Drug Administration. General Principles of Software Validation; Final Guidance for Industry and FDA Staff. January 2002.

U.S. Food and Drug Administration. 21 CFR Part 11 – Electronic Records; Electronic Signatures. 1997.

Medicines and Healthcare products Regulatory Agency (MHRA). GXP Data Integrity Guidance and Definitions. March 2018 (revised 2021).

PIC/S. PI 011-3: Good Practices for Computerised Systems in Regulated “GXP” Environments. September 2007 (reissued July 2021).

International Organization for Standardization. ISO 13485:2016 – Medical devices – Quality management systems – Requirements for regulatory purposes.

related product

[blogcard url= https://ecompliance.jp/qms-csv/ title=”QMS（手順書）ひな形　CSV関連” ] [blogcard url= https://ecompliance.co.jp/SHOP/CSV-5KY-LIVE-00004.html title=”【VOD】CSVセミナー【第4講】”] [blogcard url= https://ecompliance.co.jp/SHOP/L_MDCSV.html title=”【VOD】医療機器企業におけるCSV実践セミナー”] [blogcard url= https://ecompliance.co.jp/SHOP/BOOK-CSV2.html title=”【書籍】【超入門】コンピュータ化システムバリデーション”] [blogcard url= https://ecompliance.co.jp/SHOP/OST-Chonyumon-CSV.html title=”【訪問セミナー】【超入門】コンピュータバリデーションセミナー”]