Compliance
CSA vs CSV: What Changes, and Which Guidance Applies?
Compare FDA computer software assurance guidance with established validation principles, then scope a register assurance plan to its intended use and applicable requirements.
Computer software assurance (CSA) versus computerised system validation (CSV) is not a choice between assurance and no assurance. First identify the software’s intended use, the process it supports, and the requirements that apply. FDA’s CSA guidance addresses software used in medical-device production or a medical-device quality management system. Risk-based assurance principles can also inform work on a pharmaceutical quality management system, but a pharmaceutical GMP team must establish its applicable requirements rather than assume that FDA’s device-sector guidance changes its obligations.
The practical difference is one of scope and method: the FDA guidance describes a risk-based approach and possible activities for establishing confidence in in-scope automation. It does not make the word “CSA” a general exemption from validation, nor does it replace the need to identify the applicable quality-system requirements.
Start with scope, not the software label
CSV is often used as shorthand for planning and documenting assurance that a system is fit for its intended use. It is not one universal regulation with identical requirements in every industry and jurisdiction. Risk-based validation principles also predate the FDA’s CSA guidance.
The FDA’s February 2026 Computer Software Assurance for Production and Quality Management System Software guidance describes recommendations for computers and automated data-processing systems used as part of medical-device production or a quality management system. FDA says it supersedes the September 2025 version and aims to help manufacturers comply with the Quality Management System Regulation (QMSR), 21 CFR Part 820. FDA guidance describes the agency’s current thinking; it is not itself a regulation.
The QMSR became effective on 2 February 2026 and applies to finished medical-device manufacturers that intend to commercially distribute devices. It incorporates ISO 13485:2016 by reference, subject to applicable FDA requirements. The QMSR is a regulation; the CSA document is guidance. Keep those source types distinct when writing a plan.
For a pharmaceutical GMP system, identify the jurisdiction, product and process scope, applicable GMP requirements, and local quality procedures. FDA’s device CSA guidance does not apply merely because the software is a register or because a team calls its work “CSA”. For example, the European Commission’s EudraLex Volume 4 page lists Annex 11 (Computerised Systems) as revised in January 2011 and separately lists the 2025 consultation draft. A consultation draft is not the final guideline. Applicability and any local adoption or transition arrangements still need qualified assessment.
What should an Australian medicines manufacturer check?
Start with the TGA’s PIC/S adoption and applicability guidance, not the latest overseas publication alone. The TGA identifies PIC/S PE 009-17, dated 25 August 2023, as applying from 1 September 2025 to the manufacture of medicines, active pharmaceutical ingredients and sunscreens, subject to exemptions. Annexes 4, 5 and 14 are not adopted in Australia. Assess the relevant product scope, manufacturing principles and any applicable phased implementation arrangements with the responsible Quality / Regulatory owner.
For an Australian pharmaceutical register, this means checking the locally applicable GMP framework before selecting assurance activities. FDA device-sector CSA guidance and EU consultation drafts do not, by themselves, change Australian requirements. This comparison is not a determination of the requirements for an individual site or system.
What changes in the assurance conversation?
Distinguish CSA as an assurance approach from the scope of FDA’s specific CSA guidance. For a medical-device or pharmaceutical quality management system, intended use, risk and evidence remain useful starting points for assurance planning. FDA’s guidance describes recommendations for its device-sector scope; it does not make a pharmaceutical QMS subject to that guidance merely because the team adopts similar methods.
CSA is not the opposite of CSV. Focusing on the activities that provide confidence in automation is compatible with established lifecycle and risk-based validation thinking; it does not justify caricaturing all CSV as exhaustive scripting or paperwork.
| Question | Device production or QMS software | Pharmaceutical GMP software |
|---|---|---|
| What must be scoped first? | Whether the system is used in medical-device production or the QMS, and whether the manufacturer and software are within the relevant FDA scope. | The product, process, jurisdiction, applicable GMP requirements, and the organisation’s procedures. |
| What source can inform the approach? | The current FDA CSA guidance can inform a risk-based assurance approach for in-scope software; QMSR requirements remain regulatory requirements. | The applicable local GMP framework and procedures. FDA’s device CSA guidance is not a substitute. |
| What does the plan need to explain? | Intended use, credible failure consequences, selected activities, results, issues, and the basis for acceptance. | The same decision logic, mapped to the applicable pharmaceutical requirements and site responsibilities. |
| What must not be assumed? | That a supplier package or a “low-risk” label proves the configured use is suitable. | That a device-sector recommendation or a different jurisdiction’s draft changes local GMP duties. |
The table is a scoping aid, not a legal determination. A quality or regulatory owner must confirm which requirements apply before a team approves its assurance plan.
Worked example: a register that says “closed” too soon
Suppose a register shows deviation DEV-2026-0001 as closed while its linked corrective-action
record CR-0001 remains open. This is an illustrative failure scenario, not a test result or a
claim that a particular system has failed.
The same visible mismatch can have different assurance implications depending on how the register is used:
| Planning item | Device manufacturer example | Pharmaceutical GMP example |
|---|---|---|
| Intended use to confirm | Does the register only help track work, or does a production/QMS process rely on its status or reports? | Does the register only support follow-up, or do staff rely on it for a GMP decision, escalation, or controlled record? |
| Foreseeable failure | A missed follow-up leaves a required quality action open while the system presents it as closed. Consider effects on the device QMS and downstream decisions. | A missed follow-up obscures an open deviation or action. Consider effects on the pharmaceutical quality process and the records or decisions that rely on it. |
| Applicable source | If in scope, assess the FDA QMSR and use the current FDA CSA guidance as a recommendation for the assurance approach. | Establish the applicable GMP framework and site procedure first. Do not import FDA device guidance as an exemption. |
| Evidence to plan | Trace the status requirement to the configured workflow and select checks that can reveal the mismatch. Review relevant supplier evidence, configuration, interfaces, and reports. | Trace the procedure and intended use to the configured controls and checks. Review relevant supplier evidence, configuration, interfaces, records, and reports. |
| Decision record | Document scope, risk rationale, chosen activities, actual results, unresolved issues, and authorised acceptance. | Document the applicable requirements, scope, rationale, activities, actual results, issues, and authorised acceptance. |
Do not assign a risk score from the example alone. Establish the actual use, possible consequences, existing manual or technical controls, and responsible decision-makers. If the register merely displays status, that may change the assessment; it does not automatically make the use low-risk. If the register triggers a quality or release decision without an independent check, the team should reassess its assumptions and controls.
A practical planning sequence
- Describe the use. Name the process, users, information, outputs, and decisions that rely on the system. “Quality register” is not a sufficient intended-use statement.
- Confirm the applicable framework. Record product and jurisdiction scope, applicable requirements, and the quality owner who confirms them. Separate regulations, final guidance, local procedures, and consultation drafts.
- Describe credible failures. For each important requirement, ask what could happen if the function fails, gives an incorrect result, or is unavailable. Consider how the failure could be detected and what other controls exist.
- Choose proportionate activities. Use the scope and risk rationale to select supplier evidence, configuration review, testing, or other checks. Explain why each activity provides useful evidence for this use; do not select a method only because the team calls it CSA or CSV.
- Record what actually happened. Keep expected outcomes separate from observed results. Record deviations, unresolved issues, review, acceptance authority, and any limitations.
- Maintain the decision. Define which changes to intended use, configuration, data, reports, interfaces, or procedures trigger impact assessment and possible further assurance.
For the example above, a planning record could start with this blank row and be completed by the responsible team:
| System and intended use | Requirement and failure scenario | Applicable source | Selected activity and rationale | Actual evidence and result | Issue / acceptance owner |
|---|---|---|---|---|---|
| To be completed by the system owner | To be assessed against the actual process | To be confirmed by Quality / Regulatory | To be selected and justified | Not performed in this article | Named authorised owner required |
This article does not supply an executed protocol, test evidence, risk classification, or acceptance decision. Those belong to the organisation’s controlled process.
Keep the claim proportionate
The useful question is not “Can CSA replace CSV?” It is: Which requirements apply to this intended use, and what evidence supports the organisation’s acceptance decision? A risk-based approach is not permission to omit evidence; nor does a larger document set, by itself, establish that the important failure modes were addressed.
For background on risk-based validation principles, read Practical Risk-Based Computerised System Validation. For a worked register context, see Validating a SharePoint Quality Register. When you are ready to turn the scope into a practical plan, explore validation planning for sustainable teams.
Further reading and training
For an industry perspective on risk assessment and supplier evidence, see PharmOut’s computer system validation overview. This is a commercial service-provider resource, not regulatory authority.
For structured learning on validation, risk management and data integrity, consider the GxP Computerised Systems course from Online GMP Training. This is a commercial training option. Confirm the syllabus and source currency with the provider; course completion does not establish that a particular system is validated or compliant. Use the primary regulatory sources below to determine applicable requirements.
Sources and scope notes
- U.S. Food and Drug Administration, Computer Software Assurance for Production and Quality Management System Software, final guidance, February 2026. Scope and status checked 22 October 2026.
- U.S. Food and Drug Administration, Quality Management System Regulation (QMSR). Effective 2 February 2026; applicability checked 22 October 2026.
- Therapeutic Goods Administration, Complying with the PIC/S Guide to Good Manufacturing Practice for medicinal products. Australian adoption, product scope and exceptions checked 22 October 2026; assess applicable implementation arrangements before relying on the guidance.
- European Commission, EudraLex Volume 4, Annex 11 listing checked 21 October 2026.
- European Commission, consultation on revised Chapter 4 and Annex 11 and new Annex 22. Draft/consultation status checked 21 October 2026.
- U.S. Food and Drug Administration, General Principles of Software Validation, final guidance, January 2002. Historical context only; the 2026 CSA guidance supersedes its Section 6 for the production and QMS software in its scope.
Scope limits: This is general education, not legal advice, a jurisdiction-specific applicability decision, or a validated solution design. Confirm the relevant local requirements and transitions with the responsible Quality / Regulatory owner before relying on the comparison.