CSA didn't lower the bar. It moved the effort to where the risk is. A year on, the most common misreading is still costing regulated companies time and defensibility.
A year on from FDA's final Computer Software Assurance guidance, the most common thing we hear is still the most wrong: "CSA means less validation." It doesn't. It means less undifferentiated validation — and for an ERP implementation, that distinction is the difference between a defensible assurance package and a thick binder that proves nothing an auditor cares about.
FDA issued Computer Software Assurance for Production and Quality System Software in final form on September 24, 2025, through CDRH and CBER. It supersedes the relevant section of the old General Principles of Software Validation and replaces a reflex that had calcified over two decades: validate every function to the same depth, document every test the same way, and treat a screenshot as the unit of evidence. CSA asks a different question. Not "have you tested everything?" but "have you put your assurance effort where the risk to patients, product, and data integrity actually is?"
CSA is a risk-based, least-burdensome approach to assuring the software used in production and the quality system. Three ideas carry it.
First, assurance effort should scale with risk. You classify a feature by the consequence of its failure — does a defect reach a patient, compromise product quality, or corrupt a regulated record? — and you size the testing to that answer. High-risk, custom-configured functionality gets rigorous, scripted testing. Low-risk, vendor-managed functionality gets a lighter, rationale-backed approach.
Second, the method of testing can vary. FDA explicitly endorses unscripted and exploratory testing, not just pre-written scripts, as long as the record of what you did is contemporaneous and defensible. The agency also points to continuous monitoring as a legitimate assurance activity.
Third, evidence you already have counts. FDA tells manufacturers to draw on vendor assessments, certifications, and digital records — system logs, audit trails — rather than re-documenting, screenshotting, or duplicating results the software already retains. The record the system keeps is the record you use.
None of this lowers the standard. It redirects the work.
"Less validation" is a comfortable misreading because it sounds like permission to do less. What CSA actually grants is permission to be proportionate — and proportionality is harder, not easier, because it requires you to defend where each thing sits. A validate-everything shop never has to justify why a given test was deep or shallow; everything is deep, and the rationale is "we always do." A CSA-aligned program has to write down why the standard financial posting routine got a light touch and the custom lot-genealogy configuration got full rigor. That rationale is the deliverable. Skip it and you have not done less validation — you have done undocumented validation, which is worse.
Risk drives depth, concretely. In a regulated ERP, not every function carries the same consequence. A standard, unmodified general-ledger posting routine that Microsoft maintains and that thousands of tenants exercise daily does not warrant the same assurance burden as a bespoke lot-genealogy configuration whose output feeds a recall decision. CSA lets you say so — provided you classify each, in writing, and tie the depth of testing to the classification. The traceability from "this is high-risk because it touches a recall" to "therefore we executed a full PQ with these acceptance criteria" is the spine of the argument.
Unscripted testing earns its place. Much of what a senior configurator does when validating an ERP workflow is exploratory by nature — exercising edge cases, probing boundary conditions, confirming an integration behaves under a malformed input. Under the old reflex, that work was invisible unless it was wrapped in a pre-written script. CSA recognizes it as assurance in its own right, as long as you capture what you did and what you saw. The effect is that real testing rigor stops being penalized for not looking like a protocol.
Vendor and platform evidence does real work. When Microsoft documents how Business Central or the finance and operations apps handle a control, that documentation is part of your assurance case, not a gap you must independently re-prove. The same goes for the platform's own audit trails and system logs: under CSA they are evidence, not something to be re-captured as screenshots and pasted into a report nobody will read at inspection. This is where CSA and the 2026 Dynamics audit features compound — the platform now records who (or what) changed a record, and CSA tells you to use that record as your evidence.
CSA rewards firms whose methodology was built around risk from the start. If your validation plan already classifies by patient-safety, product-quality, and data-integrity risk, and your traceability matrix already links each test's depth to that classification, CSA is not a change in how you work — it is the regulator catching up to it. The exposure runs the other way. The "validate everything to the same depth" shops are now doing more work to make a weaker argument, because volume of documentation has never been the thing that survives an inspection. A defensible rationale is.
This is also why CSA is not an American footnote. The 2026 revision of EU Annex 11 is explicitly aligned to CSA thinking, which means a risk-based, design-stage approach increasingly satisfies both FDA and EU expectations from a single build. Designing for proportionality is no longer a regional bet.
CSA did not lower the bar. It moved the effort to where the risk lives and asked you to defend the move. For an ERP implementation that means classifying every function by consequence, sizing assurance to that classification, letting unscripted testing and vendor evidence carry real weight, and treating the system's own audit trail as the record of truth. Do that and you produce a thinner, sharper, more defensible package than the old binder ever was. The discipline was never the page count. It was always the rationale.
Aperigon delivers Microsoft Dynamics 365 to Life Sciences companies — validated by design, inspection-ready on day one. If you are scoping an ERP build or a validation remediation, start a conversation.