Computer Software Assurance (CSA) is a risk-based approach to establishing confidence that software is fit for its intended use. FDA's current guidance, Computer Software Assurance for Production and Quality Management System Software, was revised in February 2026 and formally applies to software used in medical-device production and quality management systems under 21 CFR Part 820. Its emphasis on intended use, risk-based analysis, and proportionate assurance is consistent with broader risk-based practices used in GAMP 5 across life sciences.
CSV is the established lifecycle practice of demonstrating that a computerized system is fit for intended use. CSA is not a universal replacement for CSV; it is a risk-based assurance approach centered on intended use, risk-based analysis, and proportionate assurance evidence. In the FDA's formal scope, the February 2026 guidance applies to medical-device production and quality management system software. Across pharma and biotech, similar risk-based practices are commonly implemented through GAMP 5 and the applicable GxP regulations.
FDA issued final CSA guidance in September 2025 and revised it in February 2026 to align with the amended 21 CFR Part 820 Quality Management System Regulation (QMSR). The current guidance recommends a risk-based approach to establishing confidence in software used in medical-device production and quality management systems. The February 2026 revision supersedes the September 2025 final guidance; the core risk-based assurance approach remains.
FDA guidance is nonbinding and does not replace the underlying regulatory requirements. For medical-device production and quality management system software, FDA's February 2026 guidance recommends a risk-based CSA approach. Pharmaceutical and biotech organizations are not directly governed by that guidance merely because software is GxP; they should apply risk-based principles through the regulations and guidance applicable to their operations, commonly supported by GAMP 5.
'Critical thinking' is common GAMP and industry language for the expert judgment used in risk-based validation. FDA's February 2026 CSA guidance itself uses terms such as intended use, risk-based analysis, process risk, and assurance activities rather than defining 'critical thinking' as a regulatory requirement. In practice, the reasoning asks what can fail, what the consequence is, and what assurance activity is proportionate to that risk.
FDA's CSA approach supports using supplier activities and evidence when they are relevant and sufficient for the intended use and risk. Supplier evidence does not transfer accountability: the regulated organization still needs to understand the intended use, evaluate supplier capability, assess risk, and determine what additional assurance is necessary. In broader life sciences, GAMP 5 provides practical supplier-assessment guidance for applying the same principle.
FDA's CSA guidance recognizes different assurance methods, including scenario-based testing where appropriate, rather than requiring every activity to use a detailed step-by-step script. The method should match the intended use and risk, and the record should preserve sufficient evidence of what was assessed, the result, and any issues. In pharma and biotech, the same principle can be applied through a documented GAMP 5 risk rationale.
FDA CSA and GAMP 5 Second Edition are complementary, but they are not the same document and have different scopes. GAMP 5 Second Edition (2022) is an industry guide used broadly across life sciences. FDA's current CSA guidance, revised in February 2026, formally addresses medical-device production and quality management system software. Both support risk-based, proportionate assurance and appropriate use of supplier information, while GAMP 5 provides the broader life-sciences lifecycle framework.
FDA CSA does not prescribe one fixed document set. For software within the guidance's scope, the record should provide objective evidence appropriate to the assurance activity and make the intended use, risk-based analysis, assurance performed, results, issues, and conclusion understandable. FDA also identifies information such as who performed the activity and when, with review or approval where appropriate. Organizations can use different record formats as long as applicable documentation requirements are met and the evidence is proportionate to risk.
No. FDA's CSA guidance does not change 21 CFR Part 11. When electronic records or electronic signatures fall within Part 11 scope, the applicable controls still need to be addressed, such as system validation, access controls, audit trails where required, record protection and retrieval, and electronic-signature controls. CSA concerns the assurance approach for software within its formal scope; Part 11 applicability is determined separately from the records and signatures involved.
CSA itself does not reference GAMP software categories directly, but the GAMP 5 Second Edition framework shares a risk-based philosophy and continues to use software categories as one input to lifecycle planning. Category 3 (non-configurable software), Category 4 (configurable software), and Category 5 (custom software) still provide useful starting points for risk assessment. Under CSA, category assignment informs but does not dictate the validation approach — the actual intended use, process risk, GxP impact, system characteristics, and available evidence should drive the assurance strategy.
For cloud or SaaS software within FDA CSA's scope, supplier information can be one source of assurance evidence when it is relevant and credible. The manufacturer still remains responsible for establishing confidence in its intended use. A practical approach can include supplier assessment, intended-use and risk analysis, configuration and integration verification, review of available supplier evidence, and targeted assurance of functions whose failure could create higher process risk.
FDA CSA guidance is a US document and does not formally apply in the EU. It also has a specific FDA scope: medical-device production and quality management system software. EU GMP Annex 11 remains an important European requirement for computerized systems in GMP environments. Multinational organizations can harmonize risk-based assurance practices, but each programme should map controls and evidence to the regulations and guidance actually applicable to the site and product.
Adopt risk-based assurance practices systematically rather than treating CSA as a wholesale replacement for CSV. Define whether the FDA guidance is formally applicable, update procedures to document intended use, risk-based rationale, proportionate assurance, issues and conclusions, strengthen supplier-evidence processes, and train teams on appropriate testing methods. Existing validation records do not need to be rewritten solely because FDA revised the guidance; changes should follow the organization's normal lifecycle and change-control process.
For software within the formal scope of FDA's CSA guidance, a clear record should make the intended use, risk-based analysis, assurance activities, results, issues, and conclusion understandable. Inspectors may also review how supplier information, changes, access, records, and procedures are controlled under the applicable quality-system requirements. Outside that formal scope, the organization should demonstrate compliance with the regulations and guidance that actually apply to its operation.
FDA's CSA guidance does not prescribe IQ/OQ/PQ as a universal format. Assurance activities should be selected based on intended use and risk. IQ/OQ/PQ can remain an appropriate structure where it efficiently demonstrates fitness for intended use; simpler or lower-risk functions may be supported by supplier evidence, configuration verification, or scenario-based testing when the rationale is documented and the applicable regulations permit it.
FDA's CSA guidance asks manufacturers within its formal scope to analyze reasonably foreseeable software failures and the resulting process and medical-device risk. Not all failures have the same consequence, so assurance activity should be proportionate to risk. In broader life-sciences validation, the applicable GxP requirements and GAMP 5 can be used to apply similar risk-based reasoning to product quality, patient safety, and data integrity.
CSA does not explicitly mandate an RTM, but traceability between user requirements, risk assessments, and test evidence is a logical outcome of the critical thinking approach. An RTM — or equivalent structured documentation — provides the clearest audit trail showing that each identified risk was addressed by proportionate testing. For complex systems with many GxP-impacting functions, an RTM remains best practice. For simpler configurations, a summary document mapping risks to testing outcomes may be sufficient.
In a CSA-aligned risk-based lifecycle, change control should reassess intended use, affected functions, and risk rather than automatically repeating the original validation package. When a system changes, the relevant question is: does this change affect any function with GxP impact, and if so, what is the risk and what level of revalidation is proportionate? Not every update triggers a full requalification. Configuration changes, vendor patches, and feature additions must each be assessed for their specific impact on validated functions — with the assessment documented as part of the change control record.
FDA's CSA guidance does not by itself require organizations to rewrite historical CSV records. Existing systems should continue to be maintained under the organization's approved lifecycle, change-control, and periodic-review processes. When a legacy system changes, reassess intended use, affected functions, risk, and existing evidence, then decide what additional assurance is appropriate. Organizations can adopt more proportionate CSA-aligned practices prospectively where the guidance is applicable.