FDA Issues Computer Software Assurance Guidance: A Paradigm Shift in Medical Device Quality Systems

Introduction: A Transformative Moment for Medical Device Quality Assurance

On September 24, 2025, the U.S. Food and Drug Administration (FDA) issued a final guidance document that represents one of the most significant shifts in medical device quality assurance practices in decades. Titled “Computer Software Assurance for Production and Quality System Software,” this guidance fundamentally transforms how manufacturers approach software validation for production and quality system applications. This transformation arrives at a pivotal moment, as the industry prepares for the February 2, 2026 implementation of the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 by reference.

The guidance represents a deliberate departure from the prescriptive, one-size-fits-all validation approach symbolized by traditional Computer System Validation (CSV) methodologies. Instead, it embraces Computer Software Assurance (CSA)—a flexible, risk-based framework that enables manufacturers to focus their quality assurance resources where they matter most: on high-risk functions that directly impact patient safety and product quality. This is not merely a terminological change; it reflects a fundamental reconceptualization of quality assurance philosophy, moving from procedural compliance focused on documentation volume to substantive assurance focused on patient protection and product quality.

Three Years of Industry Collaboration Shape Final Guidance

The path to this final guidance spanned three years of intensive collaboration between FDA and stakeholders across the medical device ecosystem. The draft guidance was first published on September 13, 2022, triggering a 60-day public comment period that concluded on November 14, 2022. The docket (FDA-2022-D-0795) attracted substantial engagement from diverse stakeholders, demonstrating the guidance’s significance to the industry.

Commenters included major medical device manufacturers such as Abbott and GE Healthcare, pharmaceutical companies including GSK, Sanofi, AstraZeneca, and Daiichi Sankyo, industry associations led by the Advanced Medical Technology Association (AdvaMed), and technology service providers such as Amazon Web Services. This breadth of participation underscored how production and quality system software validation touches every segment of the healthcare product development and manufacturing landscape.

Several consistent themes emerged from these comments. Many organizations sought greater alignment with ISPE’s GAMP 5 (Good Automated Manufacturing Practice) guidance, particularly the Second Edition published in July 2022, which had already embraced many of the principles that CSA formalized. Cloud computing received substantial attention, with commenters requesting clearer guidance on validating Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS) models. Most significantly, stakeholders overwhelmingly requested concrete implementation examples, expressing a common sentiment: “We understand the concepts, but we need to see how to apply them in practice.”

FDA responded comprehensively to these requests. The final guidance includes an expanded definitions section explicitly addressing cloud computing service models and deployment models. Appendix A was substantially enhanced with four detailed implementation examples: a nonconformance management system, a learning management system (LMS), business intelligence applications, and a SaaS-based product lifecycle management (PLM) system. These examples provide practical roadmaps for manufacturers implementing CSA across diverse system types and risk profiles.

Understanding CSA: A Risk-Based Framework for Software Assurance

The Core Philosophy: Proportionate Assurance Based on Risk

The essence of CSA lies in a deceptively simple principle: assurance activities should be proportionate to the risk that software failure poses to product quality, data integrity, and patient safety. Rather than applying uniform validation requirements to all software features, CSA requires manufacturers to assess each software feature, function, or operation individually and tailor assurance activities accordingly.

Consider a manufacturing execution system that controls both critical process parameters and administrative reporting. The temperature control function for a sterilization process poses high process risk—failure could result in non-sterile products reaching patients. In contrast, the function that generates a weekly production summary report poses minimal process risk—failure would inconvenience management but would not compromise product quality. Traditional CSV approaches might subject both functions to equivalent validation rigor. CSA explicitly recognizes this as inefficient and potentially counterproductive, as excessive focus on low-risk functions diverts resources from thorough evaluation of high-risk capabilities.

The CSA Risk Framework: Binary Classification with Clear Criteria

The guidance establishes a binary risk classification framework: high process risk and not high process risk. This binary approach, while initially seeming oversimplified, provides clarity that eliminates the ambiguity inherent in multi-tiered risk scales. Manufacturers avoid debates about whether a function is “medium-high” versus “medium-low” risk and instead focus on a clear decision: does this software feature, function, or operation, if it fails to perform as intended, pose a risk to patient safety, product quality, or data integrity?

High process risk software includes functions where failure could directly result in:

Manufacturing a device that fails to meet specifications
Releasing a device that should have been rejected
Failing to detect or investigate a quality problem
Compromising data integrity for records required under quality system regulations
Inability to trace devices or investigate complaints effectively

Not high process risk software includes functions where:

Manual procedures or physical controls provide adequate backup
Failure impacts efficiency or convenience but not product quality
The function supports but does not directly control critical quality attributes
Adequate verification occurs through independent means

This risk determination must be documented with clear rationale. The guidance emphasizes that risk assessment requires deep understanding of both the manufacturing process and how software integrates into that process. It cannot be performed superficially or delegated to individuals lacking process knowledge.

Aligning Assurance Activities with Risk

Once risk is determined, manufacturers select appropriate assurance activities. The guidance provides significant flexibility while maintaining clear expectations.

For High Process Risk Software:

Scripted testing remains the primary assurance method. This includes:

Scripted Testing: Pre-defined test cases with specific inputs, expected outputs, and documented results. The guidance explicitly references IEC/IEEE/ISO 29119-1:2022 definitions of scripted testing.
Requirements Traceability: Demonstrable links between user requirements, functional specifications, and test cases ensure comprehensive coverage.
Repeatability Testing: Verifying that the software produces consistent results under equivalent conditions.
Boundary Testing: Challenging software with extreme or unusual inputs to verify it handles edge cases appropriately.

For Not High Process Risk Software:

The guidance formally endorses unscripted testing methodologies, representing a major departure from traditional CSV practices:

Exploratory Testing: Testers with deep process knowledge exercise the software without pre-written scripts, using their understanding of how users will interact with the system and where problems might emerge.
Scenario Testing: Simulating realistic user workflows to verify the software supports intended operations effectively.
Error Guessing: Applying experience from previous failures to focus testing on likely problem areas.

This flexibility does not diminish rigor; rather, it channels expertise more effectively. An experienced quality professional conducting exploratory testing on a training management system may detect usability issues and edge cases that scripted testing would miss, while consuming fewer resources than comprehensive scripted testing.

Comprehensive Table: CSA Assurance Activity Selection Framework

Risk Classification	Software Examples	Primary Assurance Methods	Documentation Expectations	Vendor Evidence Utilization
High Process Risk	• Production equipment control software<br>• Automated release decision systems<br>• Sterilization process control<br>• Critical quality attribute measurement systems<br>• Electronic batch records for GMP-critical steps	• Comprehensive scripted testing<br>• Requirements traceability matrix<br>• Boundary and stress testing<br>• Data integrity testing<br>• Repeatability verification	• Detailed validation protocol and report<br>• Complete test case documentation<br>• Requirements traceability<br>• Risk assessment with clear rationale<br>• Change control documentation	• Vendor testing as supplement only<br>• Independent verification required<br>• Vendor documentation supports but does not replace testing<br>• Vendor certifications (e.g., SOC 2) provide confidence but not assurance
Not High Process Risk	• Learning management systems<br>• Employee scheduling software<br>• Business intelligence/reporting tools<br>• Document version control for procedures<br>• Nonconformance tracking with physical segregation<br>• General inventory management	• Exploratory testing<br>• Scenario-based testing<br>• Error guessing<br>• Periodic monitoring<br>• User acceptance testing	• Assurance summary with approach rationale<br>• Evidence of testing activities<br>• Issue resolution documentation<br>• Risk assessment justifying approach	• Heavy reliance on vendor documentation acceptable<br>• Vendor test results can substitute for independent testing<br>• Vendor quality system audit may provide sufficient assurance<br>• SaaS provider certifications highly valuable

Vendor Assessment: Strategic Leverage of Supplier Capabilities

One of CSA’s most significant practical implications involves vendor and supplier assessment. Traditional CSV often required medical device manufacturers to replicate testing that software vendors had already performed, creating duplication without commensurate quality benefit. CSA explicitly recognizes that leveraging vendor capabilities and documentation represents sound risk management.

The guidance outlines a structured approach to vendor assessment:

1. Evaluate Vendor Quality Management System Review the vendor’s development processes, quality management practices, and commitment to software quality. ISO 9001 or similar certification provides confidence. For software vendors, adherence to secure Software Development Lifecycle (SDLC) practices is particularly important.

2. Review Vendor Testing and Validation Documentation Vendors often perform extensive testing during development. Rather than duplicating this effort, manufacturers should evaluate whether vendor testing adequately addresses intended use requirements. For SaaS applications, vendor-provided validation packages may significantly reduce manufacturer validation burden.

3. Assess Cybersecurity and Data Integrity Controls For cloud-based systems and SaaS applications, cybersecurity and data integrity capabilities are critical. Review vendor certifications such as SOC 2 Type II, ISO 27001, or FedRAMP. Evaluate how vendors implement access controls, audit trails, data backup, and disaster recovery.

4. Define Requirements in Service Agreements Contractual agreements should clearly specify:

Requirements for advance notification of software changes
Access to change documentation and impact assessments
Data ownership, retention, and retrieval rights
Service level agreements for uptime and performance
Data security and privacy commitments
Audit rights to verify vendor compliance with commitments

5. Establish Ongoing Monitoring Vendor assessment is not a one-time activity. Periodic review of vendor performance, change notifications, and security incidents ensures continued confidence in vendor capabilities.

This approach is particularly valuable for cloud computing services. A manufacturer using a SaaS PLM system cannot realistically validate the cloud provider’s infrastructure, redundancy systems, or security architecture. Instead, the manufacturer verifies that the SaaS provider maintains appropriate certifications, implements robust security controls, and provides necessary visibility into changes affecting intended use. The manufacturer then focuses assurance activities on configuration, integration with other systems, and verification that the software supports intended quality system operations.

Exploratory Testing: Formalizing Professional Judgment

Perhaps no aspect of CSA generated more discussion than the formal endorsement of unscripted testing methods. Under traditional CSV approaches, testing without detailed pre-written scripts was often viewed as inadequate or unprofessional. CSA reverses this perception for not high process risk software, recognizing that experienced testers can often provide better assurance through structured exploration than through mechanical execution of scripts.

The guidance references IEC/IEEE/ISO 29119-1:2022 definitions of unscripted testing, providing international standards alignment. However, it is critical to understand that “unscripted” does not mean “unplanned” or “undocumented.” Effective exploratory testing requires:

Pre-Test Planning Testers must understand:

System intended use and user workflows
Potential failure modes and their consequences
Areas of highest risk or complexity
Integration points with other systems
Applicable regulatory requirements

Structured Execution During testing, testers should:

Follow realistic user scenarios
Deliberately challenge system boundaries
Attempt unexpected inputs or sequences
Verify system behavior under various conditions
Document issues as they are discovered

Post-Test Documentation Results must include:

Summary of testing approach and scope
Issues discovered and their resolution
Assessment of system fitness for intended use
Any limitations or conditions identified
Recommendation regarding system release

For a learning management system, exploratory testing might involve a quality manager familiar with training requirements testing whether the system properly tracks training completion, prevents users from skipping required modules, generates compliant training records, and handles common edge cases like employee transfers or course prerequisites. This tester’s knowledge of how the system will actually be used, combined with their understanding of regulatory requirements for training documentation, provides assurance that may be more robust than mechanical execution of hundreds of pre-written test cases covering unlikely scenarios.

Digital Records: Embracing Technology for Enhanced Data Integrity

CSA strongly encourages manufacturers to leverage digital records and system-generated evidence rather than relying on inefficient paper-based documentation or manual screenshot capture. Modern quality systems generate extensive audit trails, system logs, and automated records that provide objective, timestamped evidence of system operation. These digital records often provide superior data integrity compared to manually created documentation.

For example, rather than capturing screenshots of each test case execution, testers can leverage system-generated audit trails showing exactly what transactions occurred, when they occurred, who performed them, and what results they produced. These audit trails are typically more difficult to alter than screenshots, include precise timestamps, and provide context that screenshots may lack.

However, manufacturers must ensure digital records meet data integrity requirements. The ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available) apply to digital records just as they do to paper records. Systems generating digital evidence must implement:

Unique user identification and access controls
Secure, computer-generated timestamps
Protection against unauthorized alteration or deletion
Retention that ensures availability throughout required retention periods
Ability to generate human-readable copies for review and inspection

Where 21 CFR Part 11 (Electronic Records; Electronic Signatures) applies, manufacturers must also ensure compliance with Part 11 requirements for audit trails, electronic signatures, and system controls. The CSA guidance does not eliminate Part 11 obligations; rather, it provides flexibility in how validation requirements under 21 CFR 820.70(i) are met while maintaining Part 11 compliance where applicable.

Understanding Part 11 in the CSA Context

Part 11 applies to electronic records required by predicate rules—regulatory requirements that mandate specific records. For medical devices, 21 CFR Part 820 (Quality System Regulation/Quality Management System Regulation) establishes predicate rule record requirements. When these required records are maintained electronically, Part 11 applies.

The CSA guidance addresses validation requirements under 21 CFR 820.70(i): “When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol.”

FDA’s 2003 Part 11 Scope and Application guidance indicated the agency would exercise enforcement discretion for certain Part 11 validation requirements, provided manufacturers met predicate rule validation requirements. Importantly, this enforcement discretion does NOT apply to validation required by predicate rules like 21 CFR 820.70(i). Manufacturers cannot rely on Part 11 enforcement discretion to avoid validating production and quality system software.

CSA provides the framework for meeting 820.70(i) validation requirements through risk-based assurance. Part 11 remains applicable for electronic signatures, audit trails, and system controls for those electronic records required by Part 820. The two regulations work in concert: CSA defines how to validate software, while Part 11 defines requirements for trustworthy electronic records and signatures.

Quality Management System Regulation (QMSR): The Broader Context

The CSA guidance cannot be understood in isolation from the broader regulatory transformation occurring in medical device quality management. On February 2, 2026, the Quality Management System Regulation (QMSR) becomes effective, fundamentally restructuring 21 CFR Part 820.

QMSR: Incorporating ISO 13485:2016 by Reference

The QMSR final rule, published on February 2, 2024 (89 FR 7496), amends the device current good manufacturing practice (CGMP) requirements by incorporating ISO 13485:2016 (“Medical devices – Quality management systems – Requirements for regulatory purposes”) by reference. This represents FDA’s most significant alignment with international quality system standards.

The revised Part 820 maintains its title and location but becomes dramatically shorter. Most subparts will simply reference corresponding ISO 13485:2016 clauses. However, FDA retained specific requirements where it determined ISO 13485 needed clarification or supplementation:

Section 820.3 – Definitions: While adopting ISO 13485:2016 and ISO 9000:2015 definitions, FDA retained specific US regulatory definitions from Section 201(h) of the FD&C Act for terms like “device” and “labeling.” FDA also added definitions for “component,” “finished device,” “lot or batch,” “manufacturing material,” and “reprocessing” to address concepts not fully defined in ISO standards.

Section 820.10 – Requirements for a Quality Management System: This section links ISO 13485 requirements to other FDA regulations, including medical device reporting (21 CFR Part 803), unique device identification (21 CFR Part 830), corrections and removals (21 CFR Part 806), and tracking (21 CFR Part 821).

Section 820.35 – Control of Records: The QMSR adds specific requirements beyond ISO 13485 for:

Complaint records including investigation criteria and documentation
Service records for devices where servicing is part of quality system requirements
Labeling and packaging records
Unique Device Identification (UDI) documentation
Confidentiality requirements for records sent to or received from FDA

Section 820.45 – Device Labeling and Packaging Controls: FDA determined ISO 13485:2016 did not adequately address labeling inspection. The QMSR requires inspection of device labels for accuracy regarding:

Intended use and identification information
Quantity, dosage, or other relevant information
Control number (if applicable)
Storage and handling instructions
Other critical label elements

This inspection must occur before release, and human visual verification is required even if automated systems are also used.

QMSR and CSA: Complementary Frameworks

QMSR and CSA work as complementary elements of medical device quality assurance. QMSR establishes the overall quality management system framework by incorporating ISO 13485:2016, while CSA provides specific guidance on validating software used within that quality management system.

ISO 13485:2016 Clause 4.1.6 requires manufacturers to validate software applications used in quality management systems. The CSA guidance provides the methodology for meeting this requirement through risk-based assurance. ISO 13485:2016 also emphasizes risk-based thinking throughout the quality management system (Clause 0.2), aligning perfectly with CSA’s risk-based assurance philosophy.

Manufacturers preparing for QMSR implementation should integrate CSA principles into their quality management system design. The risk-based approach to software validation aligns naturally with ISO 13485’s emphasis on risk management and process-based quality assurance. Organizations already certified to ISO 13485:2016 will find many quality management system elements already in place to support CSA implementation.

Timeline Considerations and Strategic Planning

With QMSR effective February 2, 2026, manufacturers face concurrent implementation of two significant regulatory changes. Strategic planning should address:

Gap Analysis: Comparing current practices against both QMSR requirements (via ISO 13485:2016) and CSA expectations to identify necessary changes.

Software Inventory and Risk Classification: Cataloging all production and quality system software and performing CSA risk assessments to determine appropriate assurance approaches.

Quality Management System Restructuring: Reorganizing quality system procedures, documents, and records to align with ISO 13485:2016 structure while incorporating CSA methodologies for software validation.

Training and Change Management: Ensuring personnel understand both QMSR requirements and CSA approaches, particularly for individuals performing risk assessments and making assurance activity decisions.

Vendor Management: Updating vendor agreements to address change notification, documentation access, and other requirements supporting CSA vendor assessment approaches.

Organizations that view this as an opportunity rather than a burden can achieve competitive advantages through improved operational efficiency, reduced validation burden, and enhanced ability to adopt innovative manufacturing technologies.

GAMP 5 Second Edition: Industry Best Practice Alignment

The relationship between CSA and ISPE’s GAMP 5 guidance merits special attention. GAMP (Good Automated Manufacturing Practice) has long served as the pharmaceutical and medical device industries’ primary reference for computerized system validation. The Second Edition, published in July 2022, was developed concurrently with the CSA draft guidance and reflects substantial alignment.

Key GAMP 5 Second Edition Principles Aligned with CSA

Risk-Based Approach to Validation: Both GAMP 5 and CSA emphasize that validation effort should be proportionate to risk. GAMP 5’s risk-based categorization of software (Categories 1-5) provides a framework for determining appropriate validation approaches that complements CSA’s binary risk classification.

Leveraging Supplier Documentation: GAMP 5 Second Edition strongly encourages leveraging supplier testing and documentation rather than duplicating vendor work. This aligns directly with CSA’s vendor assessment approach.

Flexible Testing Methodologies: GAMP 5 Second Edition explicitly recognizes both traditional waterfall and modern agile development approaches, supporting iterative testing and continuous validation. CSA’s endorsement of exploratory testing for not high process risk software fits naturally within this flexible framework.

Critical Thinking Over Procedural Compliance: Both GAMP 5 and CSA emphasize the application of scientific and engineering knowledge by qualified personnel rather than mechanical compliance with checklists. Success requires understanding of processes, software functionality, and potential failure modes.

Cloud Computing and SaaS: GAMP 5 Second Edition includes extensive discussion of cloud computing validation, providing detailed guidance on assessing cloud service providers and validating SaaS applications. This directly supports CSA implementation for cloud-based quality system software.

Practical Integration of GAMP 5 and CSA

Organizations implementing CSA should consider GAMP 5 Second Edition as a complementary resource providing:

Detailed validation lifecycle models applicable to various development approaches
Extensive appendices addressing specific technologies (AI/ML, blockchain, open-source software)
Comprehensive supplier assessment frameworks
Data integrity guidance aligned with regulatory expectations
Practical examples and case studies

GAMP 5 is not an FDA requirement, but it represents industry consensus on good practice. Leveraging GAMP 5 guidance when implementing CSA provides access to decades of collective industry experience in computerized system validation.

Implementation Roadmap: From Concept to Practice

Successfully implementing CSA requires structured planning, pilot testing, and gradual rollout. The following roadmap provides a practical approach:

Phase 1: Assessment and Preparation (2-3 Months)

Step 1: Inventory Current State Create a comprehensive inventory of all production and quality system software currently in use or under development. Include:

Commercial off-the-shelf (COTS) applications
Software-as-a-Service (SaaS) applications
Custom-developed applications
Spreadsheets and macros if used for quality system purposes
Laboratory information management systems (LIMS)
Manufacturing execution systems (MES)
Electronic quality management systems (eQMS)
Document management systems

Step 2: Assess Current Validation Approach Review existing validation practices to understand:

Current validation methodologies and standards
Resource investment in validation activities
Pain points and inefficiencies
Areas where traditional CSV may be excessive
Gaps in current validation coverage

Step 3: Define CSA Implementation Strategy Develop organization-specific strategy addressing:

CSA governance structure and decision-making authority
Training requirements for personnel performing risk assessments
Criteria and process for risk classification
Standard assurance approaches for different risk levels and software types
Documentation expectations and templates
Vendor assessment procedures
Change management process for transitioning from CSV to CSA

Phase 2: Pilot Implementation (3-6 Months)

Select Pilot Systems Strategically Choose 2-4 systems representing different software types and risk profiles:

One clearly not high process risk system (e.g., learning management system, business intelligence tool)
One high process risk system with vendor-provided assurance documentation
One legacy system requiring revalidation or update
One cloud-based SaaS application

Develop and Execute Pilot Validation Approach For each pilot system:

Document intended use comprehensively
Perform risk assessment using CSA framework
Determine appropriate assurance activities
Execute assurance activities and document results
Compare resource investment to traditional CSV approach
Identify lessons learned and refinements needed

Refine Procedures Based on Pilot Results Update CSA procedures, templates, and guidance based on practical experience from pilot systems.

Phase 3: Scaling and Integration (6-12 Months)

Gradual Rollout Rather than attempting to transition all systems simultaneously, implement CSA:

For all new system implementations
When existing systems require revalidation
When systems undergo significant changes
Opportunistically as resources permit for stable legacy systems

Build Organizational Capability Invest in training and development:

Risk assessment workshops for quality and engineering personnel
Exploratory testing training for experienced system users
Vendor assessment training for procurement and quality teams
Change management to help personnel adapt to new approaches

Monitor and Optimize Establish metrics to track:

Resource investment in validation activities
Time from project initiation to system release
Issues discovered post-implementation
Regulatory inspection findings related to software validation
Cost savings versus traditional CSV

Phase 4: Continuous Improvement and Regulatory Readiness

Establish Regulatory Inspection Preparedness Prepare to explain CSA approach to regulators:

Document CSA implementation strategy and rationale
Maintain clear risk assessment documentation
Be prepared to demonstrate adequacy of assurance activities
Show how CSA meets 21 CFR 820.70(i) requirements

Adapt to Emerging Technologies Use CSA framework to efficiently validate emerging technologies:

Artificial intelligence and machine learning applications
Advanced analytics and big data systems
Internet of Things (IoT) devices in manufacturing
Robotic process automation (RPA)

Share Knowledge Within Organization Create communities of practice to share learnings, challenges, and successful approaches across different departments and sites.

Detailed Examination of Appendix A Examples

The four examples in Appendix A provide invaluable practical guidance. Each example walks through the entire CSA process for a specific system type.

Example 1: Nonconformance Management System

This example addresses a COTS system for managing nonconforming products. The manufacturer analyzes various features:

Electronic Signature Feature – Risk Assessment: The system uses electronic signatures to approve nonconformance dispositions. The risk assessment determines this is not high process risk because physical segregation prevents nonconforming product from reaching distribution even if the electronic system fails. The signature provides traceability but does not constitute the sole control.

Assurance Approach: Scenario testing verifies that signatures are properly linked to records, include required information (user identification, timestamp), and cannot be repudiated. No comprehensive scripted testing is performed.

Product Recall Determination Feature – Risk Assessment: This feature analyzes nonconformances to determine whether recall is necessary. Failure to properly identify recall situations poses direct risk to patients. This is classified as high process risk.

Assurance Approach: Comprehensive scripted testing verifies the system correctly applies recall determination criteria, flags products meeting recall thresholds, and generates required notifications. Boundary testing challenges the system with edge cases. Repeatability testing confirms consistent decisions.

This example demonstrates how a single system can contain features with different risk profiles requiring different assurance approaches.

Example 2: Learning Management System (LMS)

LMS systems are ubiquitous in regulated industries but generally pose limited process risk. The example examines:

Training Curriculum and Tracking Features – Risk Assessment: While regulatory requirements mandate training, the LMS failure does not directly cause manufacturing defects. Personnel qualification can be verified through alternative records. Not high process risk.

Assurance Approach: Exploratory testing by a quality manager familiar with training requirements verifies the system:

Correctly tracks training completion
Prevents bypass of required modules
Generates compliant training records meeting regulatory requirements
Handles common scenarios (employee transfers, course updates)

The manufacturer also conducts vendor quality system audit verifying the vendor maintains appropriate development and testing practices.

This example shows how exploratory testing by knowledgeable users can provide robust assurance for well-understood, lower-risk applications.

Example 3: Business Intelligence Applications

Business intelligence (BI) and reporting tools present interesting CSA challenges. The example distinguishes between different report types:

Operational Dashboards – Risk Assessment: Real-time production dashboards inform management decisions but do not directly control production or quality. Decisions based on dashboard data are made by personnel who can verify data reasonableness. Not high process risk.

Assurance Approach: Vendor documentation review, configuration verification, and periodic monitoring of report accuracy. Exploratory testing verifies dashboards correctly aggregate data from source systems and refresh appropriately.

Regulatory Reporting – Risk Assessment: Reports submitted to FDA or used for batch release decisions pose higher risk. However, if source data is maintained in validated systems and reports are verified before use, the BI tool itself may still be not high process risk.

Assurance Approach: Focus assurance on ensuring reports accurately reflect source system data. Verify calculations, filtering logic, and data aggregation through sample checking and reconciliation to source systems.

This example illustrates how the same tool can be categorized differently based on intended use and surrounding controls.

Example 4: SaaS-Based Product Lifecycle Management (PLM) System

This example addresses cloud-based software with a comprehensive vendor assessment approach:

Initial Vendor Assessment:

Review vendor’s Software Development Lifecycle (SDLC) practices
Evaluate quality management system (ISO 9001 certification)
Assess cybersecurity documentation and certifications (SOC 2 Type II)
Review infrastructure support and redundancy
Evaluate data security, backup, and recovery capabilities

Service Level Agreement (SLA) Requirements:

Change management: 30-day advance notice for changes affecting intended use
Data ownership and retrieval rights
Security incident notification procedures
Uptime guarantees and remediation procedures
Audit rights to verify vendor compliance

Ongoing Monitoring:

Review change notifications and assess impact
Monitor system performance against SLA commitments
Track security incidents or data integrity issues
Periodic vendor assessment review (e.g., annually)

Manufacturer-Side Assurance: Focus on configuration, integration, and user workflows rather than validating the vendor’s infrastructure:

Verify PLM system configuration supports intended workflows
Test integration with other systems (e.g., ERP, QMS)
Confirm user permissions and access controls are properly configured
Verify reports and data exports meet quality system needs

This example demonstrates that robust vendor assessment combined with focused manufacturer testing can provide adequate assurance for complex SaaS applications without requiring the impossible task of validating a cloud provider’s infrastructure.

Change Management and PMA/HDE Implications

For manufacturers holding Premarket Approval (PMA) or Humanitarian Device Exemption (HDE) authorizations, changes to production or quality system software may trigger regulatory reporting requirements. The CSA guidance addresses this through alignment with FDA’s change management framework.

Manufacturers should evaluate software changes using the criteria in FDA’s guidance “30-Day Notices, 135-Day PMA Supplements, and 75-Day HDE Supplements for Manufacturing Method or Process Changes” (commonly called the Manufacturing Changes guidance). Generally:

Changes reportable in annual report: Software changes that do not affect device safety or effectiveness and do not require changes to labeling, may be reported in the annual report. For example, updating an LMS to a new version that improves user interface but does not change training tracking functionality.

Changes requiring 30-day notice: Changes that could affect device safety or effectiveness but do not require prior approval may be submitted as 30-day notices. For example, updating environmental monitoring software to use a new algorithm for trend analysis.

Changes requiring 135-day supplement: Significant changes to production or quality systems that could affect device safety or effectiveness typically require prior approval via supplement. For example, implementing a new automated inspection system as the primary release decision-maker.

The CSA guidance notes that risk-based assurance activities should inform the change evaluation. Software with robust CSA documentation demonstrating fitness for intended use provides evidence supporting the change assessment.

Importantly, manufacturers implementing CSA for the first time on existing systems are not making a change to production or the quality system; rather, they are changing how they establish confidence in software fitness for intended use. This validation approach change does not require PMA/HDE reporting, though manufacturers should document the rationale and approach.

Addressing Common Implementation Questions

Question 1: Can we apply CSA to legacy systems currently validated under traditional CSV?

Yes. CSA can be applied to legacy systems. Manufacturers should perform CSA risk assessment on legacy systems and determine whether existing validation documentation provides adequate assurance. For not high process risk legacy systems, existing validation may be excessive; manufacturers can document the CSA assessment and adjust ongoing maintenance and revalidation approaches accordingly. For high process risk legacy systems, existing CSV validation likely provides appropriate assurance; the CSA assessment confirms this and guides future revalidation activities.

Question 2: How does CSA affect our validation SOPs and quality management system?

CSA implementation requires updating procedures to:

Incorporate CSA risk assessment methodology and decision criteria
Define approaches for different risk levels
Address vendor assessment procedures
Update documentation expectations to reflect risk-based approaches
Revise training requirements for personnel performing risk assessments

However, fundamental validation principles remain: establish fitness for intended use through appropriate verification activities documented with objective evidence.

Question 3: Does CSA reduce regulatory inspection risk?

CSA does not eliminate inspection scrutiny of software validation. However, it provides a clear framework for explaining validation approaches and demonstrating that validation effort is appropriately focused on patient safety and product quality. Manufacturers who can clearly articulate their risk assessment rationale and show appropriate assurance activities aligned with risk are well-positioned for regulatory inspection success.

Question 4: How does CSA interact with other quality systems standards like ICH Q12?

ICH Q12 “Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management” (adopted 2019, revised 2024) establishes frameworks for managing post-approval changes to pharmaceutical manufacturing. While primarily focused on drug products, its principles apply to medical device combination products and can inform medical device change management.

CSA’s risk-based approach to software changes aligns well with ICH Q12’s emphasis on categorizing changes based on risk and establishing appropriate change protocols. For combination products, manufacturers should consider both CSA and ICH Q12 when developing software change management procedures.

Question 5: What role does continuous validation or monitoring play in CSA?

CSA explicitly recognizes that ongoing monitoring and continuous validation approaches can provide assurance, particularly for not high process risk software. Rather than treating validation as a one-time event at system implementation, manufacturers can implement:

Automated monitoring of system performance and data integrity
Periodic review of system-generated logs and audit trails
Trend analysis of system errors or performance issues
Regular user feedback collection and issue tracking

For cloud-based SaaS applications with frequent updates, continuous monitoring may be more appropriate than attempting to perform comprehensive validation for each minor release.

Global Regulatory Landscape and CSA

While CSA is FDA guidance applicable to FDA-regulated medical devices, the principles resonate globally. Many regulatory authorities worldwide are moving toward risk-based, outcomes-focused quality system requirements.

EU Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR): The MDR and IVDR require quality management systems compliant with ISO 13485. The risk-based principles in CSA align well with ISO 13485:2016 requirements for software validation (Clause 4.1.6 and 7.5.6).

Medical Device Single Audit Program (MDSAP): MDSAP, which includes FDA along with regulatory authorities from Canada, Australia, Brazil, and Japan, bases audits on ISO 13485. CSA approaches are compatible with MDSAP expectations.

Other Regulatory Authorities: Many countries align their medical device requirements with ISO 13485 and recognize risk-based approaches to validation. China’s National Medical Products Administration (NMPA), for example, has adopted similar quality management system principles.

Manufacturers serving global markets can leverage CSA as part of a harmonized quality system approach, reducing duplication across different regulatory jurisdictions.

Future Implications: AI, Machine Learning, and Advanced Technologies

The CSA framework provides flexibility to address emerging technologies that traditional CSV approaches struggle to accommodate. Artificial intelligence (AI) and machine learning (ML) systems, for example, present unique validation challenges because their behavior may change based on training data and learning algorithms.

The FDA has released separate guidance on AI/ML-enabled medical devices, but CSA principles apply when AI/ML is used in production or quality systems. Manufacturers should:

Define Intended Use Precisely: Clearly specify what decisions or processes the AI/ML system will support and what boundaries exist on its application.

Assess Risk Based on Impact: Determine whether AI/ML failure could compromise product quality or patient safety. An AI system that optimizes production scheduling for efficiency might be not high process risk; an AI system that makes final release decisions would be high process risk.

Tailor Assurance to AI/ML Characteristics: Assurance for AI/ML might include:

Validation of training data quality and representativeness
Testing against diverse scenarios including edge cases
Monitoring for model drift or performance degradation over time
Periodic retraining and revalidation protocols
Human oversight for critical decisions

CSA’s flexibility enables manufacturers to develop appropriate assurance strategies for AI/ML without forcing these advanced technologies into traditional validation frameworks designed for deterministic software.

Conclusion: Embracing the Quality Assurance Future

The FDA’s Computer Software Assurance guidance represents more than regulatory modernization; it embodies a fundamental shift in quality assurance philosophy from compliance-focused documentation to patient-focused assurance. The three years from draft to final guidance, incorporating hundreds of stakeholder comments, produced a document that balances regulatory clarity with practical flexibility.

Combined with the February 2, 2026 implementation of QMSR incorporating ISO 13485:2016, CSA positions medical device manufacturers to leverage modern technologies and practices while maintaining robust quality assurance. The exploratory testing endorsement, vendor assessment emphasis, digital records promotion, and cloud computing guidance all reflect the reality of contemporary medical device manufacturing.

Implementation requires investment: in training, procedure development, pilot testing, and organizational change management. However, manufacturers who successfully implement CSA will realize significant benefits:

More efficient use of validation resources
Faster adoption of innovative manufacturing technologies
Improved focus on truly critical quality and safety issues
Better alignment with international quality system standards
Enhanced competitiveness in global markets

The deadline of February 2, 2026 for QMSR creates urgency, but it also creates opportunity. Organizations that view these changes as chances to improve quality systems rather than merely compliance burdens will emerge stronger. The journey from traditional CSV to CSA is not just about meeting regulatory requirements—it’s about building quality systems that truly serve their fundamental purpose: ensuring that medical devices are safe, effective, and consistently manufactured to the highest quality standards.

Three years of industry dialogue shaped this guidance. Now begins the work of implementation. The path forward requires critical thinking, professional judgment, and commitment to the ultimate goal: protecting patient safety through effective quality assurance. CSA provides the framework; the medical device industry must now demonstrate the capability and commitment to use that framework wisely.

Note: This guidance document is non-binding. While it represents FDA’s current thinking, alternative approaches may be acceptable provided they comply with applicable statutes and regulations. Manufacturers should consult with FDA if they have questions about specific implementations.

Key References:

FDA Guidance: Computer Software Assurance for Production and Quality System Software (September 24, 2025)
21 CFR Part 820 Quality System Regulation / Quality Management System Regulation
FDA Final Rule: Medical Devices; Quality System Regulation Amendments (February 2, 2024, 89 FR 7496)
ISO 13485:2016 Medical devices – Quality management systems – Requirements for regulatory purposes
ISPE GAMP 5 Second Edition: A Risk-Based Approach to Compliant GxP Computerized Systems (July 2022)
21 CFR Part 11: Electronic Records; Electronic Signatures
FDA Guidance: Part 11, Electronic Records; Electronic Signatures — Scope and Application (August 2003)
IEC/IEEE/ISO 29119-1:2022 Software and systems engineering – Software testing – Part 1: General concepts

FDA计算机软件保证指南：执行摘要

文件： 生产和质量系统软件的计算机软件保证
发布日期： 2025年9月24日
生效日期： 立即生效（指南为非强制性）
关键截止日期： 2026年2月2日（QMSR实施）

核心变革：从验证到保证

FDA从根本上改变了医疗器械生产和质量系统软件验证要求。最终版计算机软件保证（CSA）指南以灵活的、基于风险的框架取代了传统的计算机系统验证（CSV），使制造商能够将资源集中在最重要的领域：影响患者安全和产品质量的高风险功能。

关键范式转变：

旧方法： 对所有软件采用统一、规范的验证，无论风险如何
新方法： 基于风险的保证，与患者安全影响成比例
目标： 更智能的资源分配，同时不损害质量或合规性

每个组织必须理解的五个关键变化

1. 二元风险分类框架

软件特性、功能和操作分为两类：

高工艺风险

故障可能危及产品质量、数据完整性或患者安全
示例：灭菌控制、自动化放行决策、关键参数监控
要求： 全面的脚本测试、需求可追溯性、详细文档

非高工艺风险

故障不直接影响产品质量或患者安全
示例：培训管理、商业智能、员工排班
允许： 探索性测试、依赖供应商文档、简化证据

影响： 制造商可以显著减少约60-70%质量系统软件的验证负担，同时增强对真正关键系统的严格性。

2. 正式认可无脚本测试

对于非高工艺风险软件，FDA明确批准：

探索性测试： 经验丰富的测试人员在没有预先编写脚本的情况下执行软件测试
场景测试： 真实用户工作流程验证
错误猜测： 利用经验专注于可能的问题领域

重要说明： “无脚本”并不意味着”无文档”。测试方法、执行和结果必须记录并提供明确的理由。

3. 战略性供应商评估和利用

制造商可以依赖供应商测试、文档和认证，而不是重复所有验证工作：

供应商评估要素：

质量管理体系评估（ISO 9001、软件开发实践）
审查供应商测试和验证文档
网络安全和数据完整性控制（SOC 2、ISO 27001、FedRAMP）
指定变更管理、数据权利、安全的服务级别协议
持续监控供应商绩效和变更

特别适用于： SaaS应用、云计算服务、具有强大供应商支持的COTS软件

4. 明确涉及云计算

该指南为以下内容提供了明确的定义和验证方法：

软件即服务（SaaS）： 通过互联网访问的应用程序
平台即服务（PaaS）： 开发/部署平台
基础设施即服务（IaaS）： 计算基础设施资源

验证策略： 专注于配置、集成和预期用途，而不是试图验证云提供商的基础设施。利用提供商认证和审计权限。

5. 强烈鼓励数字记录

现代质量系统生成广泛的客观证据：

具有安全时间戳的系统生成审计跟踪
记录所有系统活动的自动化日志
符合ALCOA+原则的电子记录

优势： 与截图和纸质文档相比，具有卓越的数据完整性，并显著提高效率。

要求： 确保电子记录在适用情况下符合21 CFR Part 11（前提规则要求的记录）。

关键监管背景：QMSR整合

2026年2月2日实施截止日期

质量管理系统法规（QMSR）生效，通过引用纳入ISO 13485:2016。这代表FDA与国际标准在质量系统方面最重要的协调。

CSA与QMSR的关系：

QMSR建立整体质量管理系统框架
ISO 13485:2016第4.1.6条要求软件验证
CSA指南提供满足该要求的方法
两者都强调在整个质量系统中采用基于风险的方法

战略意义： 组织必须为同时实施QMSR和CSA方法做好准备。

与行业标准的一致性

GAMP 5第二版（2022年7月）

在以下方面高度一致：

基于风险的验证方法
利用供应商能力
灵活的测试方法
云计算验证
批判性思维优于程序合规

建议： 使用GAMP 5作为提供详细实施框架的补充指南。

21 CFR Part 11（电子记录；电子签名）

CSA涉及验证要求（21 CFR 820.70(i)）
电子记录和电子签名的Part 11要求仍然适用
FDA执法自由裁量权不豁免验证要求
数字证据在适用情况下必须符合Part 11要求

实施路线图：四阶段方法

第一阶段：评估（第1-3个月）

清点所有生产和质量系统软件
审查当前验证方法和资源投入
定义CSA治理结构和决策权限
制定风险评估标准和程序

第二阶段：试点实施（第4-9个月）

选择2-4个不同的试点系统（不同风险级别、类型）
执行CSA风险评估和保证活动
比较与传统CSV的资源投入
根据经验教训完善程序

第三阶段：扩展（第10-18个月）

将CSA应用于所有新系统实施
将CSA整合到现有系统的再验证周期中
通过培训建立组织能力
建立监控和优化指标

第四阶段：持续改进（持续进行）

为监管检查做准备
适应新兴技术（AI/ML、物联网、高级分析）
在组织内分享知识
监控监管发展和行业最佳实践

FDA附录A的实际案例

不合格管理系统

电子签名： 非高风险 → 场景测试
召回决定： 高风险 → 全面脚本测试
教训： 单个系统可以具有不同风险特征的功能

学习管理系统

培训跟踪： 非高风险 → 质量经理进行探索性测试
方法： 利用供应商审计，专注于法规合规性验证
优势： 对于普遍存在的低风险系统显著减少验证负担

商业智能应用

运营仪表板： 非高风险 → 供应商文档、定期监控
监管报告： 风险取决于使用前的验证
关键因素： 周围控制影响风险分类

SaaS产品生命周期管理

供应商评估： 对SDLC、QMS、网络安全进行全面评估
服务协议： 变更通知、数据权利、审计访问
制造商重点： 配置、集成、用户工作流程
教训： 强大的供应商评估使SaaS验证更高效

关键成功因素

1. 高层承诺

CSA需要组织文化转变
领导层必须支持基于风险的决策
从低风险活动到高风险活动的资源重新分配

2. 人员能力

风险评估需要深入的流程和软件知识
培训员工了解CSA原则和方法
授权合格人员做出基于风险的决策

3. 文档质量

清晰、可辩护的风险评估理由
与风险成比例的适当客观证据
避免过度文档和文档不足

4. 供应商管理

更新采购流程和合同模板
建立供应商评估标准和程序
保持持续的供应商监督和监控

5. 监管检查准备

准备解释CSA方法和理由
证明保证活动如何与风险保持一致
显示符合21 CFR 820.70(i)要求

常见问题解答

问：我们可以将CSA应用于已验证的旧系统吗？
答：可以。对旧系统进行CSA风险评估，并确定现有文档是否提供足够的保证。根据风险调整持续维护和再验证方法。

问：CSA会减少监管审查吗？
答：不会。CSA提供了一个框架，用于证明专注于质量和安全的适当验证工作。检查仍将评估软件验证的充分性。

问：CSA合规是否需要GAMP 5？
答：不需要。GAMP 5是行业指南，不是监管要求。但是，它提供了与CSA原则一致的有价值的最佳实践。

问：CSA如何影响我们现有的程序？
答：必须更新程序以纳入风险评估方法、定义不同风险级别的方法、涉及供应商评估并调整文档期望。

问：AI和机器学习系统怎么办？
答：CSA框架适应新兴技术。精确定义预期用途，根据影响评估风险，并根据技术特征调整保证（训练数据验证、监控模型漂移等）。

即时行动项目

到2026年1月：

[ ] 完成软件清单
[ ] 建立CSA治理和程序
[ ] 开始针对QMSR/ISO 13485:2016的差距分析
[ ] 确定并启动CSA试点项目

到2026年2月（QMSR生效日期）：

[ ] 为新系统提供可操作的CSA方法
[ ] 完成QMSR合规准备
[ ] 培训人员了解CSA和QMSR要求
[ ] 更新供应商协议和评估流程

持续进行：

[ ] 将CSA应用于新实施和再验证
[ ] 监控行业发展和监管期望
[ ] 建立组织能力和知识共享
[ ] 测量和优化验证效率

战略机遇

将CSA和QMSR视为机遇而非负担的组织将获得竞争优势：

更快的上市时间 用于新产品和流程改进
降低合规成本 通过有效的资源分配
增强创新能力 通过消除验证障碍
改进质量重点 关注真正关键的患者安全要素
全球协调优势 通过ISO 13485一致性

2026年2月2日的截止日期正在迅速临近。现在果断采取行动的组织将能够充分利用这些监管变化获得战略优势。

更多信息：

FDA CSA指南：www.fda.gov/media/188844/download
联邦公报通知：89 FR 45945（2025年9月24日）
QMSR最终规则：89 FR 7496（2024年2月2日）
ISO 13485:2016：国际标准化组织
GAMP 5第二版：ISPE（2022年7月）

本执行摘要仅提供高级概述。有关具体实施决策，请参阅完整的FDA指南、适用法规和合格的监管专业人员。

FDA 컴퓨터 소프트웨어 보증 가이던스: 실행 요약

문서: 생산 및 품질 시스템 소프트웨어를 위한 컴퓨터 소프트웨어 보증
발행일: 2025년 9월 24일
시행일: 즉시 시행 (가이던스는 비구속적)
중요 마감일: 2026년 2월 2일 (QMSR 시행)

핵심 변화: 검증에서 보증으로

FDA는 의료기기 생산 및 품질 시스템 소프트웨어 검증 요구사항을 근본적으로 변경했습니다. 최종 컴퓨터 소프트웨어 보증(CSA) 가이던스는 전통적인 컴퓨터 시스템 검증(CSV)을 유연하고 위험 기반 프레임워크로 대체하여 제조업체가 가장 중요한 영역, 즉 환자 안전과 제품 품질에 영향을 미치는 고위험 기능에 자원을 집중할 수 있도록 합니다.

주요 패러다임 전환:

기존 접근법: 위험도에 관계없이 모든 소프트웨어에 대한 획일적이고 규범적인 검증
새로운 접근법: 환자 안전 영향에 비례하는 위험 기반 보증
목표: 품질이나 규정 준수를 손상시키지 않으면서 더 스마트한 자원 배분

모든 조직이 이해해야 할 다섯 가지 핵심 변화

1. 이진 위험 분류 프레임워크

소프트웨어 특성, 기능 및 작업은 두 가지 범주로 분류됩니다:

높은 공정 위험

고장 시 제품 품질, 데이터 무결성 또는 환자 안전을 손상시킬 수 있음
예시: 멸균 제어, 자동화된 출하 결정, 중요 매개변수 모니터링
요구사항: 포괄적인 스크립트 테스트, 요구사항 추적성, 상세한 문서화

높지 않은 공정 위험

고장이 제품 품질이나 환자 안전에 직접적인 영향을 미치지 않음
예시: 교육 관리, 비즈니스 인텔리전스, 직원 일정 관리
허용: 탐색적 테스트, 공급업체 문서 의존, 간소화된 증거

영향: 제조업체는 품질 시스템 소프트웨어의 약 60-70%에 대한 검증 부담을 크게 줄이면서 진정으로 중요한 시스템에 대한 엄격성을 강화할 수 있습니다.

2. 비스크립트 테스트의 공식 승인

높지 않은 공정 위험 소프트웨어의 경우 FDA는 명시적으로 다음을 승인합니다:

탐색적 테스트: 경험이 풍부한 테스터가 사전 작성된 스크립트 없이 소프트웨어 실행
시나리오 테스트: 실제 사용자 워크플로우 검증
오류 추측: 경험을 활용하여 가능성 있는 문제 영역에 집중

중요 사항: “비스크립트”가 “비문서화”를 의미하지는 않습니다. 테스트 접근법, 실행 및 결과는 명확한 근거와 함께 문서화되어야 합니다.

3. 전략적 공급업체 평가 및 활용

제조업체는 모든 검증 작업을 중복하는 대신 공급업체 테스트, 문서 및 인증에 의존할 수 있습니다:

공급업체 평가 요소:

품질 관리 시스템 평가 (ISO 9001, 소프트웨어 개발 관행)
공급업체 테스트 및 검증 문서 검토
사이버 보안 및 데이터 무결성 제어 (SOC 2, ISO 27001, FedRAMP)
변경 관리, 데이터 권리, 보안을 명시하는 서비스 수준 계약
공급업체 성능 및 변경 사항의 지속적인 모니터링

특히 유용한 경우: SaaS 애플리케이션, 클라우드 컴퓨팅 서비스, 강력한 공급업체 지원이 있는 COTS 소프트웨어

4. 클라우드 컴퓨팅 명시적 처리

가이던스는 다음에 대한 명확한 정의 및 검증 접근법을 제공합니다:

서비스형 소프트웨어(SaaS): 인터넷을 통해 액세스하는 애플리케이션
서비스형 플랫폼(PaaS): 개발/배포 플랫폼
서비스형 인프라(IaaS): 컴퓨팅 인프라 리소스

검증 전략: 클라우드 제공업체 인프라를 검증하려고 시도하는 대신 구성, 통합 및 의도된 용도에 집중합니다. 제공업체 인증 및 감사 권한을 활용합니다.

5. 디지털 기록 강력 권장

현대 품질 시스템은 광범위한 객관적 증거를 생성합니다:

안전한 타임스탬프가 있는 시스템 생성 감사 추적
모든 시스템 활동을 문서화하는 자동화된 로그
ALCOA+ 원칙을 충족하는 전자 기록

이점: 스크린샷 및 종이 문서에 비해 우수한 데이터 무결성과 상당한 효율성 향상.

요구사항: 해당되는 경우 전자 기록이 21 CFR Part 11을 준수하도록 보장 (전제 규칙에 따라 요구되는 기록).

중요한 규제 맥락: QMSR 통합

2026년 2월 2일 시행 마감일

품질 관리 시스템 규정(QMSR)이 시행되어 ISO 13485:2016을 참조로 통합합니다. 이것은 FDA의 국제 표준과의 품질 시스템 조화에 있어 가장 중요한 변화를 나타냅니다.

CSA와 QMSR의 관계:

QMSR은 전반적인 품질 관리 시스템 프레임워크를 설정
ISO 13485:2016 조항 4.1.6은 소프트웨어 검증을 요구
CSA 가이던스는 해당 요구사항을 충족하는 방법론 제공
둘 다 품질 시스템 전반에 걸쳐 위험 기반 접근법 강조

전략적 의미: 조직은 QMSR 및 CSA 접근법을 동시에 시행할 준비를 해야 합니다.

업계 표준과의 일치

GAMP 5 제2판 (2022년 7월)

다음 사항에 대한 강력한 일치:

위험 기반 검증 접근법
공급업체 역량 활용
유연한 테스트 방법론
클라우드 컴퓨팅 검증
절차 준수보다 비판적 사고

권장사항: 상세한 구현 프레임워크를 제공하는 보완 가이던스로 GAMP 5를 사용하십시오.

21 CFR Part 11 (전자 기록; 전자 서명)

CSA는 검증 요구사항 다룸 (21 CFR 820.70(i))
전자 기록 및 전자 서명에 대한 Part 11 요구사항은 계속 적용
FDA 집행 재량권은 검증 요구사항을 면제하지 않음
해당되는 경우 디지털 증거는 Part 11 요구사항을 충족해야 함

구현 로드맵: 4단계 접근법

1단계: 평가 (1-3개월)

모든 생산 및 품질 시스템 소프트웨어 목록 작성
현재 검증 접근법 및 자원 투자 검토
CSA 거버넌스 구조 및 의사결정 권한 정의
위험 평가 기준 및 절차 개발

2단계: 파일럿 구현 (4-9개월)

2-4개의 다양한 파일럿 시스템 선택 (다른 위험 수준, 유형)
CSA 위험 평가 및 보증 활동 실행
전통적인 CSV와 자원 투자 비교
경험을 바탕으로 절차 개선

3단계: 확장 (10-18개월)

모든 새로운 시스템 구현에 CSA 적용
기존 시스템의 재검증 주기에 CSA 통합
교육을 통한 조직 역량 구축
모니터링 및 최적화를 위한 지표 설정

4단계: 지속적 개선 (진행 중)

규제 검사 준비
신흥 기술에 적응 (AI/ML, IoT, 고급 분석)
조직 내 지식 공유
규제 발전 및 업계 모범 사례 모니터링

FDA 부록 A의 실제 사례

부적합 관리 시스템

전자 서명: 높지 않은 위험 → 시나리오 테스트
리콜 결정: 높은 위험 → 포괄적인 스크립트 테스트
교훈: 단일 시스템이 다른 위험 프로필을 가진 기능을 가질 수 있음

학습 관리 시스템

교육 추적: 높지 않은 위험 → 품질 관리자의 탐색적 테스트
접근법: 공급업체 감사 활용, 규제 준수 검증에 집중
이점: 보편적인 저위험 시스템에 대한 검증 부담 크게 감소

비즈니스 인텔리전스 애플리케이션

운영 대시보드: 높지 않은 위험 → 공급업체 문서, 정기 모니터링
규제 보고서: 위험은 사용 전 검증에 따라 달라짐
주요 요인: 주변 제어가 위험 분류에 영향을 미침

SaaS 제품 수명주기 관리

공급업체 평가: SDLC, QMS, 사이버 보안에 대한 포괄적 평가
서비스 계약: 변경 알림, 데이터 권리, 감사 액세스
제조업체 초점: 구성, 통합, 사용자 워크플로우
교훈: 강력한 공급업체 평가를 통해 효율적인 SaaS 검증 가능

핵심 성공 요인

1. 경영진 약속

CSA는 조직 문화 변화 필요
리더십은 위험 기반 의사결정 지원 필요
저위험 활동에서 고위험 활동으로 자원 재배분

2. 인력 역량

위험 평가는 깊은 프로세스 및 소프트웨어 지식 필요
CSA 원칙 및 방법에 대한 직원 교육
자격을 갖춘 인력에게 위험 기반 결정 권한 부여

3. 문서 품질

명확하고 방어 가능한 위험 평가 근거
위험에 비례하는 적절한 객관적 증거
과도한 문서화 및 문서화 부족 모두 피함

4. 공급업체 관리

조달 프로세스 및 계약 템플릿 업데이트
공급업체 평가 기준 및 절차 수립
지속적인 공급업체 감독 및 모니터링 유지

5. 규제 검사 준비

CSA 접근법 및 근거 설명 준비
보증 활동이 위험과 어떻게 일치하는지 입증
21 CFR 820.70(i) 요구사항 준수 표시

자주 묻는 질문

질문: 이미 검증된 레거시 시스템에 CSA를 적용할 수 있습니까?
답변: 예. 레거시 시스템에 대해 CSA 위험 평가를 수행하고 기존 문서가 적절한 보증을 제공하는지 확인합니다. 위험에 따라 지속적인 유지보수 및 재검증 접근법을 조정합니다.

질문: CSA가 규제 검토를 줄입니까?
답변: 아니요. CSA는 품질 및 안전에 중점을 둔 적절한 검증 노력을 입증하기 위한 프레임워크를 제공합니다. 검사는 여전히 소프트웨어 검증의 적절성을 평가할 것입니다.

질문: CSA 준수를 위해 GAMP 5가 필요합니까?
답변: 아니요. GAMP 5는 업계 가이던스이며 규제 요구사항이 아닙니다. 그러나 CSA 원칙과 일치하는 가치 있는 모범 사례를 제공합니다.

질문: CSA가 기존 절차에 어떤 영향을 미칩니까?
답변: 절차는 위험 평가 방법론을 통합하고, 다른 위험 수준에 대한 접근법을 정의하고, 공급업체 평가를 다루고, 문서 기대치를 조정하도록 업데이트되어야 합니다.

질문: AI 및 머신러닝 시스템은 어떻게 됩니까?
답변: CSA 프레임워크는 신흥 기술을 수용합니다. 의도된 용도를 정확하게 정의하고, 영향을 기반으로 위험을 평가하고, 기술 특성에 맞게 보증을 조정합니다 (훈련 데이터 검증, 모델 드리프트 모니터링 등).

즉시 실행 항목

2026년 1월까지:

[ ] 소프트웨어 목록 완성
[ ] CSA 거버넌스 및 절차 수립
[ ] QMSR/ISO 13485:2016에 대한 갭 분석 시작
[ ] CSA 파일럿 프로젝트 식별 및 시작

2026년 2월까지 (QMSR 시행일):

[ ] 새로운 시스템을 위한 운영 가능한 CSA 접근법 보유
[ ] QMSR 준수 준비 완료
[ ] CSA 및 QMSR 요구사항에 대한 인력 교육
[ ] 공급업체 계약 및 평가 프로세스 업데이트

진행 중:

[ ] 새로운 구현 및 재검증에 CSA 적용
[ ] 업계 발전 및 규제 기대 모니터링
[ ] 조직 역량 및 지식 공유 구축
[ ] 검증 효율성 측정 및 최적화

전략적 기회

CSA 및 QMSR을 부담이 아닌 기회로 보는 조직은 경쟁 우위를 얻을 것입니다:

더 빠른 출시 시간 – 신제품 및 프로세스 개선
준수 비용 절감 – 효율적인 자원 배분
향상된 혁신 능력 – 검증 장벽 제거
개선된 품질 초점 – 진정으로 중요한 환자 안전 요소
글로벌 조화 이점 – ISO 13485 일치

2026년 2월 2일 마감일이 빠르게 다가오고 있습니다. 지금 과감하게 행동하는 조직은 이러한 규제 변화를 전략적 이점으로 활용할 수 있는 좋은 위치에 있을 것입니다.

추가 정보:

FDA CSA 가이던스: www.fda.gov/media/188844/download
연방 관보 공고: 89 FR 45945 (2025년 9월 24일)
QMSR 최종 규칙: 89 FR 7496 (2024년 2월 2일)
ISO 13485:2016: 국제표준화기구
GAMP 5 제2판: ISPE (2022년 7월)

이 실행 요약은 개략적인 개요만 제공합니다. 구체적인 구현 결정은 전체 FDA 가이던스, 해당 규정 및 자격을 갖춘 규제 전문가와 상담하십시오.

FDAコンピュータソフトウェアアシュアランスガイダンス：エグゼクティブサマリー

文書： 製造および品質システムソフトウェアのためのコンピュータソフトウェアアシュアランス
発行日： 2025年9月24日
施行日： 即時発効（ガイダンスは非拘束的）
重要期限： 2026年2月2日（QMSR施行）

核心的変化：バリデーションからアシュアランスへ

FDAは医療機器の製造および品質システムソフトウェアのバリデーション要求事項を根本的に変革しました。最終版コンピュータソフトウェアアシュアランス(CSA)ガイダンスは、従来のコンピュータシステムバリデーション(CSV)を、柔軟でリスクベースのフレームワークに置き換え、製造業者が最も重要な領域、すなわち患者の安全性と製品品質に影響を与える高リスク機能にリソースを集中できるようにします。

主要なパラダイムシフト：

従来のアプローチ： リスクに関係なく、すべてのソフトウェアに対する画一的で規範的なバリデーション
新しいアプローチ： 患者安全への影響に比例したリスクベースアシュアランス
目標： 品質やコンプライアンスを損なうことなく、よりスマートなリソース配分

すべての組織が理解すべき5つの重要な変更

1. 二値リスク分類フレームワーク

ソフトウェアの特性、機能、および操作は2つのカテゴリに分類されます：

高プロセスリスク

故障が製品品質、データインテグリティ、または患者安全を損なう可能性がある
例：滅菌制御、自動化されたリリース判定、重要パラメータのモニタリング
要求事項： 包括的なスクリプトテスト、要求事項のトレーサビリティ、詳細な文書化

非高プロセスリスク

故障が製品品質や患者安全に直接影響しない
例：トレーニング管理、ビジネスインテリジェンス、従業員のスケジューリング
許容： 探索的テスト、ベンダー文書への依存、簡素化されたエビデンス

影響： 製造業者は品質システムソフトウェアの約60〜70%のバリデーション負担を大幅に削減しながら、真に重要なシステムに対する厳格性を強化できます。

2. 非スクリプトテストの正式承認

非高プロセスリスクソフトウェアについて、FDAは以下を明示的に承認します：

探索的テスト： 経験豊富なテスターが事前に作成されたスクリプトなしでソフトウェアを実行
シナリオテスト： 現実的なユーザーワークフローの検証
エラー推測： 経験を活用して可能性のある問題領域に焦点を当てる

重要な注意： 「非スクリプト」は「非文書化」を意味しません。テストアプローチ、実行、および結果は明確な根拠とともに文書化する必要があります。

3. 戦略的ベンダー評価と活用

製造業者は、すべてのバリデーション作業を重複させるのではなく、ベンダーのテスト、文書、および認証に依存できます：

ベンダー評価要素：

品質管理システムの評価（ISO 9001、ソフトウェア開発実践）
ベンダーのテストおよびバリデーション文書のレビュー
サイバーセキュリティおよびデータインテグリティ管理（SOC 2、ISO 27001、FedRAMP）
変更管理、データ権利、セキュリティを明記したサービスレベル契約
ベンダーのパフォーマンスと変更の継続的なモニタリング

特に有用な場合： SaaSアプリケーション、クラウドコンピューティングサービス、強力なベンダーサポートを持つCOTSソフトウェア

4. クラウドコンピューティングの明示的対応

ガイダンスは以下について明確な定義と検証アプローチを提供します：

Software as a Service（SaaS）： インターネット経由でアクセスするアプリケーション
Platform as a Service（PaaS）： 開発/展開プラットフォーム
Infrastructure as a Service（IaaS）： コンピューティングインフラストラクチャリソース

検証戦略： クラウドプロバイダーのインフラストラクチャを検証しようとするのではなく、構成、統合、および意図された用途に焦点を当てます。プロバイダーの認証と監査権限を活用します。

5. デジタル記録の強力な推奨

現代の品質システムは広範な客観的エビデンスを生成します：

安全なタイムスタンプを持つシステム生成監査証跡
すべてのシステムアクティビティを文書化する自動化されたログ
ALCOA+原則を満たす電子記録

利点： スクリーンショットや紙の文書と比較して優れたデータインテグリティと大幅な効率性の向上。

要求事項： 該当する場合、電子記録が21 CFR Part 11に準拠していることを確認（前提規則で要求される記録）。

重要な規制背景：QMSRとの統合

2026年2月2日施行期限

品質マネジメントシステム規則（QMSR）が発効し、ISO 13485:2016を参照により組み込みます。これはFDAの国際標準との品質システムの調和における最も重要な変更を表します。

CSAとQMSRの関係：

QMSRは全体的な品質マネジメントシステムの枠組みを確立
ISO 13485:2016条項4.1.6はソフトウェアバリデーションを要求
CSAガイダンスはその要求事項を満たす方法論を提供
両方とも品質システム全体でリスクベースアプローチを強調

戦略的意義： 組織はQMSRとCSAアプローチの同時実施に備える必要があります。

業界標準との整合性

GAMP 5第2版（2022年7月）

以下について強力な整合性：

リスクベースバリデーションアプローチ
サプライヤー能力の活用
柔軟なテスト方法論
クラウドコンピューティングバリデーション
手続き的コンプライアンスよりも批判的思考

推奨： 詳細な実装フレームワークを提供する補完ガイダンスとしてGAMP 5を使用してください。

21 CFR Part 11（電子記録；電子署名）

CSAはバリデーション要求事項に対応（21 CFR 820.70(i)）
電子記録および電子署名に関するPart 11要求事項は引き続き適用
FDAの執行裁量権はバリデーション要求事項を免除しない
該当する場合、デジタルエビデンスはPart 11要求事項を満たす必要がある

実装ロードマップ：4段階アプローチ

フェーズ1：評価（1〜3ヶ月）

すべての製造および品質システムソフトウェアの棚卸し
現在のバリデーションアプローチとリソース投資のレビュー
CSAガバナンス構造と意思決定権限の定義
リスク評価基準と手順の策定

フェーズ2：パイロット実装（4〜9ヶ月）

2〜4の多様なパイロットシステムを選択（異なるリスクレベル、タイプ）
CSAリスク評価とアシュアランス活動の実行
従来のCSVとのリソース投資の比較
学んだ教訓に基づく手順の改善

フェーズ3：スケーリング（10〜18ヶ月）

すべての新しいシステム実装にCSAを適用
既存システムの再バリデーションサイクルにCSAを統合
トレーニングを通じた組織能力の構築
モニタリングと最適化のためのメトリクスの確立

フェーズ4：継続的改善（継続中）

規制査察の準備
新興技術への適応（AI/ML、IoT、高度な分析）
組織内での知識共有
規制動向と業界のベストプラクティスのモニタリング

FDA付録Aの実例

不適合管理システム

電子署名： 非高リスク → シナリオテスト
リコール判定： 高リスク → 包括的なスクリプトテスト
教訓： 単一のシステムが異なるリスクプロファイルを持つ機能を持つ可能性がある

学習管理システム

トレーニング追跡： 非高リスク → 品質管理者による探索的テスト
アプローチ： ベンダー監査の活用、規制コンプライアンス検証に焦点
利点： 普遍的な低リスクシステムのバリデーション負担の大幅な削減

ビジネスインテリジェンスアプリケーション

運用ダッシュボード： 非高リスク → ベンダー文書、定期的なモニタリング
規制報告： リスクは使用前の検証に依存
主要因子： 周辺の管理がリスク分類に影響

SaaS型製品ライフサイクル管理

ベンダー評価： SDLC、QMS、サイバーセキュリティの包括的評価
サービス契約： 変更通知、データ権利、監査アクセス
製造業者の焦点： 構成、統合、ユーザーワークフロー
教訓： 強力なベンダー評価により効率的なSaaSバリデーションが可能

重要な成功要因

1. 経営陣のコミットメント

CSAは組織文化の変革を要求
リーダーシップはリスクベースの意思決定を支援する必要がある
低リスク活動から高リスク活動へのリソースの再配分

2. 人材の能力

リスク評価には深いプロセスとソフトウェアの知識が必要
CSAの原則と方法についてスタッフをトレーニング
資格のある人材にリスクベースの決定を下す権限を付与

3. 文書の品質

明確で防御可能なリスク評価の根拠
リスクに比例した適切な客観的エビデンス
過剰な文書化と文書化不足の両方を回避

4. ベンダー管理

調達プロセスと契約テンプレートの更新
ベンダー評価基準と手順の確立
継続的なベンダー監督とモニタリングの維持

5. 規制査察への準備

CSAアプローチと根拠を説明する準備
アシュアランス活動がリスクとどのように整合しているかを実証
21 CFR 820.70(i)要求事項への準拠を示す

よくある質問

Q: すでに検証されたレガシーシステムにCSAを適用できますか？
A: はい。レガシーシステムでCSAリスク評価を実施し、既存の文書が適切なアシュアランスを提供するかどうかを判断します。リスクに基づいて継続的なメンテナンスと再バリデーションアプローチを調整します。

Q: CSAは規制審査を減らしますか？
A: いいえ。CSAは品質と安全性に焦点を当てた適切なバリデーション努力を実証するためのフレームワークを提供します。査察は引き続きソフトウェアバリデーションの妥当性を評価します。

Q: CSAコンプライアンスにGAMP 5は必要ですか？
A: いいえ。GAMP 5は業界ガイダンスであり、規制要求事項ではありません。ただし、CSA原則と整合した価値あるベストプラクティスを提供します。

Q: CSAは既存の手順にどのような影響を与えますか？
A: 手順はリスク評価方法論を組み込み、異なるリスクレベルのアプローチを定義し、ベンダー評価に対応し、文書化の期待を調整するように更新する必要があります。

Q: AIと機械学習システムはどうなりますか？
A: CSAフレームワークは新興技術に対応します。意図された用途を正確に定義し、影響に基づいてリスクを評価し、技術特性に合わせてアシュアランスを調整します（トレーニングデータの検証、モデルドリフトのモニタリングなど）。

即時アクションアイテム

2026年1月まで：

[ ] ソフトウェアインベントリの完了
[ ] CSAガバナンスと手順の確立
[ ] QMSR/ISO 13485:2016に対するギャップ分析の開始
[ ] CSAパイロットプロジェクトの特定と開始

2026年2月まで（QMSR施行日）：

[ ] 新しいシステムのための運用可能なCSAアプローチの確保
[ ] QMSRコンプライアンス準備の完了
[ ] CSAおよびQMSR要求事項についての人材トレーニング
[ ] ベンダー契約と評価プロセスの更新

継続中：

[ ] 新しい実装と再バリデーションにCSAを適用
[ ] 業界の発展と規制の期待をモニター
[ ] 組織能力と知識共有の構築
[ ] バリデーション効率の測定と最適化

戦略的機会

CSAとQMSRを負担ではなく機会として捉える組織は、競争優位性を獲得します：

市場投入までの時間短縮 – 新製品とプロセス改善
コンプライアンスコストの削減 – 効率的なリソース配分
イノベーション能力の向上 – バリデーション障壁の除去
品質フォーカスの改善 – 真に重要な患者安全要素
グローバル調和の利点 – ISO 13485との整合性

2026年2月2日の期限が急速に近づいています。今、断固として行動する組織は、これらの規制変更を戦略的優位性のために活用できる良い位置にいるでしょう。

詳細情報：

FDA CSAガイダンス：www.fda.gov/media/188844/download
連邦官報通知：89 FR 45945（2025年9月24日）
QMSR最終規則：89 FR 7496（2024年2月2日）
ISO 13485:2016：国際標準化機構
GAMP 5第2版：ISPE（2022年7月）

このエグゼクティブサマリーは概要のみを提供します。具体的な実装決定については、完全なFDAガイダンス、該当する規制、および資格のある規制専門家に相談してください。

Data Analysis in Medical Device and Pharmaceutical Quality Management Systems Previous post