I am not in the device CSV space myself, so treat this as the view from the auditor's chair rather than an implementer's. Under the new assurance approach the part I would watch most is the risk decision itself. When rigour is scaled to risk, that risk rationale becomes the evidence, and if the reasoning is not written down clearly, a lighter round of testing can read as a gap to whoever reviews it later even when the call was perfectly sound.
So whatever you carry over from the old validation package, I would keep the record that shows why each function landed where it did on risk. Robert's mapping table sounds like exactly that kind of artefact. When I train auditors I tell them a risk based shortcut is only as strong as the documented thinking behind it, and the same holds true here.
------------------------------
Dilawar Laghari
Auditor, Consultant and Trainer
AuditWorkshop.com
------------------------------
Original Message:
Sent: 07-09-2026 05:47 PM
From: Robert Schmitt
Subject: CSA vs CSV - Software Assurance vs Validation
Nanda, in my revised software validation package, following my risk assessment worksheet, I have added the following table due to the new CSA guidance. I find it really helpful and practical in mapping a risk conclusion to the degree of validation rigor.
Framework for Risk-Based Validation Rigor Reference: FDA Guidance – Computer Software Assurance for Production and QMS Software, Feb. 3rd, 2026 |
The level of software risk determines the rigor of the assurance activities and the amount of objective evidence necessary to establish confidence that the software is fit for its intended use. This framework provides a consistent methodology for scaling validation activities commensurate with the risk associated with the software's intended use. |
Risk Level | Validation Confidence Objective | Validation Rigor |
Low | Establish confidence that the software performs as intended under normal operating conditions. | Basic documented testing of intended use, including installation verification and functional testing of normal operating conditions. |
Medium | Establish confidence that the software consistently performs as intended and that identified risks are effectively controlled. | Expanded testing to include verification of risk controls, foreseeable user errors, and boundary conditions. |
High | Establish confidence that the software performs as intended under normal, abnormal, and reasonably foreseeable failure conditions. | Comprehensive testing as applicable, including challenge testing, verification of data integrity and security, verification of risk controls, and risk-based regression testing following changes. |
------------------------------
Robert Schmitt
------------------------------
Original Message:
Sent: 07-07-2026 12:45 PM
From: Nanda Filkin
Subject: CSA vs CSV - Software Assurance vs Validation
Thank you, Robert. I look forward to your response. -Nanda
------------------------------
Nanda Filkin
QA Scientist
Arete Biosciences
------------------------------
Original Message:
Sent: 07-06-2026 12:33 PM
From: Robert Schmitt
Subject: CSA vs CSV - Software Assurance vs Validation
Hi Nanda, I am currently upgrading my software validation processes to reflect impact of the new guidance. I will circle back to you once I have that completed. I have a current client in need of a process assurance/validation that will include software so I will be testing the impact on this project later this month.
------------------------------
Robert Schmitt
RA Manager, SIGN Fracture Care International
RA/QA Consultant, Pearl Technologies QMS Insights
------------------------------