FDA’s final guidance on Computer Software Assurance for Production and Quality System Software published in the Federal Register on 24 September 2025, and a year later, a lot of sites are still validating software the way they did before it existed. Not because the guidance is unclear. Because the old approach, exhaustive scripted testing of every function regardless of risk, is deeply embedded in procedure, training, and habit, and habit doesn’t update on a publication date.
What actually changed, stated plainly
Computer System Validation, the traditional approach, treats validation as a documentation exercise built around comprehensive scripted test cases: every function tested, every step scripted in advance, every result documented in detail, regardless of whether that function has any bearing on product quality or patient safety. It’s thorough. It’s also expensive, slow, and, critically, it spends the same rigor on a low-risk cosmetic feature as it does on a function that directly controls a release decision.
Computer Software Assurance replaces that uniform rigor with a risk-based one. The core shift is captured in the guidance’s own framing: assurance effort should be proportional to risk. High-risk functions, the ones with a direct line to product quality, patient safety, or data integrity, still get rigorous, often scripted testing. Lower-risk functions, features that don’t touch product quality even if they fail, can be assured through unscripted or exploratory testing, critical thinking documented in a lighter-weight way, without the full scripted test-case burden the old approach demanded uniformly.
This isn’t a loosening of standards. It’s a redirection of effort toward where the risk actually is, and away from where it isn’t.
Why this maps onto a manufacturing principle you already know
Liker’s account of the Toyota Production System in The Toyota Way describes jidoka, one of the system’s two central pillars alongside just-in-time, as building quality into the process at the point where a problem can occur, rather than relying on inspection afterward to catch it. A line stops the moment a defect condition is detected, not after a batch of defective units has already been produced and now has to be sorted and dispositioned.
CSA is applying roughly the same logic to software validation. The old CSV model behaves like end-of-line inspection: validate everything exhaustively, after development, using the same scripted rigor regardless of where the actual risk sits. CSA asks a Toyota-style question instead: where does a software failure actually create risk to product quality or patient safety, and where does it just create risk to a feature nobody’s release decision depends on. Assurance effort follows the answer, concentrated where it matters, lighter where it doesn’t.
That reframing matters for anyone doing this work, because it changes the skill the validation function actually needs. CSV rewarded thoroughness and procedural discipline in generating scripted evidence. CSA rewards risk assessment: the ability to correctly identify which functions are genuinely high-risk before deciding how much rigor to apply, which is a harder and more judgment-dependent skill than executing a comprehensive test script.
What this changes specifically for e-QMS and EBR validation
Electronic quality management systems and electronic batch records are exactly the category of production and quality system software this guidance targets, and they’re also exactly the systems where the old approach was most expensive to run under CSV, because they touch a large number of functions across a wide range of actual risk levels.
Under a CSA-aligned approach, a few practical shifts follow directly.
Workflow routing that determines whether a deviation escalates correctly, or a release decision requires the right approvals, sits squarely in high-risk territory and keeps rigorous, likely scripted validation. Cosmetic configuration, dashboard layout, a report’s visual formatting, does not carry the same risk and can be assured through documented exploratory testing instead.
Data integrity controls, audit trail capture, access permissions, electronic signature enforcement, stay high-risk regardless of how the surrounding feature is categorized, because these functions protect the record’s trustworthiness itself, independent of what the record is about.
Configuration changes and periodic updates to an e-QMS or EBR platform can be assessed individually, at the risk level appropriate to what actually changed, rather than triggering a full revalidation cycle every time, which was often the default under a CSV-driven change control process built around uniform rigor.
The documentation burden shifts from proving exhaustive test coverage to demonstrating sound risk assessment. That’s arguably the harder discipline to build well, and it’s also the one most CSV-trained validation teams have the least practice at, because the old model never required them to make that judgment call explicitly. It just required them to test everything.
A worked comparison: the same feature, two validation approaches
Take a single, concrete feature inside an e-QMS: a configurable email notification that alerts a supervisor when a deviation is logged against their line. Under strict CSV, this feature gets the same scripted test rigor as everything else in the system, formal test scripts covering every notification trigger condition, every recipient configuration, every failure path, fully documented regardless of what happens if the feature fails silently. If the notification doesn’t fire, a supervisor finds out about the deviation a few hours later than they otherwise would have, an inconvenience, not a risk to product quality or patient safety.
Under CSA, the same feature gets assessed on that basis directly: does a failure here create risk to product quality, data integrity, or patient safety. It doesn’t, on its own, because the deviation itself is still captured, tracked, and actionable through the core system regardless of whether the notification fires. That reclassifies the feature as lower-risk, appropriate for documented exploratory testing rather than full scripted validation, freeing up the rigor budget CSV would have spent here to go instead toward something like the workflow logic that determines whether a deviation requires QA disposition before batch release, a function where a silent failure genuinely could let a product move forward incorrectly.
That’s the redirection this guidance is actually asking for, made concrete: not less assurance overall, but assurance concentrated where a failure would actually matter.
Where sites get this wrong in practice
The most common failure mode isn’t resisting CSA outright. It’s adopting the language of CSA, risk-based, critical thinking, proportional effort, without actually building the risk assessment discipline underneath it. A validation plan that says “risk-based approach applied” without a documented, defensible method for how risk was actually assessed for each function isn’t CSA. It’s CSV with a new cover page.
A close second failure mode: treating CSA as blanket permission to reduce rigor across the board, rather than as a redirection of rigor toward the functions that genuinely warrant it. The guidance doesn’t say to test less overall. It says to stop spending scripted-test-level effort on functions where that effort isn’t buying any actual assurance against a real risk, and to make sure the effort saved there gets applied more deliberately where the risk is real.
Conclusion
CSA isn’t a shortcut, and treating it as one is exactly how a site ends up with a validation program that looks modernized on paper and hasn’t actually changed where the assurance effort goes. The real work is building a defensible, documented risk assessment discipline, the same discipline Toyota’s own model depends on: knowing precisely where a failure creates real risk, and building assurance in at that point, rather than applying the same effort everywhere out of habit.
If your e-QMS or EBR validation approach hasn’t genuinely shifted since the final guidance published, that’s a fast thing to check, and it’s exactly the kind of gap a Rapid Diagnostic is built to find.
Key Takeaways
CSA redirects effort. It doesn’t reduce it. High-risk functions still get rigorous, often scripted testing. What changes is the rigor applied to functions that carry little or no product quality risk.
The final guidance published 24 September 2025, in the Federal Register (2025-18468). A year on, procedure and habit at many sites haven’t caught up to it.
This mirrors jidoka, not a compliance loophole. Building assurance in at the point of actual risk, rather than applying uniform effort regardless of where risk sits, is the same logic behind stopping a line at the first sign of a real defect.
Data integrity and workflow-critical functions stay high-risk regardless. Audit trails, e-signatures, access controls, and release-decision routing don’t get the lighter treatment, no matter how CSA is applied elsewhere.
The real skill CSA requires is risk assessment, not test execution. A validation plan that claims “risk-based” without a documented, defensible method behind that judgment is CSV wearing new language.