CSV vs CSA: what's actually changing under FDA's new framework

CSA is what the FDA wants you to do. CSV is what your QMS still says to do. The gap between those two sentences is where most quality teams are stuck.

I work in quality management software for a living. The teams I see still write 80-page IQ/OQ packets for an ERP upgrade because nobody has rewritten the SOP. The FDA finalized Computer Software Assurance in 2025. The QMS still references 2002.

What CSV actually became

Computer System Validation evolved from the General Principles of Software Validation in 2002. In theory it was risk-based. In practice it became a compliance ritual. A spreadsheet that tracked deviations got the same testing rigor as the firmware running an infusion pump. Quality teams spent 70-80% of validation effort generating script-and-screenshot evidence that, in my experience, no auditor has ever read.

The cost compounded. Software changes piled up in change control queues. Engineers stopped pushing improvements because the validation cost exceeded the engineering cost. I think that's the moment the framework stopped serving its purpose.

The FDA noticed. The September 2022 draft became Computer Software Assurance for Production and Quality System Software, finalized in 2025.

What CSA asks for instead

Risk first. Evidence second. Documentation only where it adds patient safety value.

In practice that's three changes.

Intended use drives the rigor. A label printer's font rendering and a SaMD diagnostic algorithm don't get the same treatment. The team picks where to invest based on patient harm. Not on a flat policy that treats every system as if it could kill someone.

Unscripted testing counts as evidence. If exploratory testing finds the bug, that's the test record. You don't need a 40-step script to prove the same thing the engineer found in 90 seconds.

Vendor evidence counts. If your vendor tested the off-the-shelf component, you can rely on it. CSV allowed this in theory. Almost no QMS allowed it in practice.

What stays the same

Three things don't change. Getting these wrong is still how you fail an inspection.

IEC 62304 still applies to medical device software. Risk classes A, B and C still drive lifecycle requirements per §4.3. The standard hasn't been rewritten.

21 CFR Part 11 still applies to electronic records. Audit trails, electronic signatures and record retention are unchanged.

Design controls under 21 CFR Part 820.30 still require Design History File evidence. CSA changes how you generate that evidence. Not whether you generate it.

The shift is about decision logic

CSA is about critical thinking. The guidance reads like a frustrated audit response. Stop generating evidence for the sake of evidence. Start documenting why you tested what you tested, what risks you considered and what your decision logic was.

Decision logic. That phrase is doing a lot of work. Auditors under CSA read rationales, not test scripts. A four-paragraph explanation of why a Class A change required only smoke testing is more defensible than 200 pages of screenshots.

Which is also harder to write. Script execution is a procedural skill. Rationale writing is a technical writing skill. Most validators were never trained on the second one. That's the actual capability gap I see at companies trying to adopt CSA.

Where teams get stuck

Policy drift. The QMS still references CSV verbatim. SOPs still mandate IQ/OQ/PQ for every system. The validation team knows CSA is the new path, but the SOPs haven't been rewritten.

Until they are, validators keep producing CSV-style packets that nobody asked for and auditors don't expect. The fix isn't technical. It's procedural. Get the QMS updated. Train the team on the rationale-first format. Pilot CSA on one system before expanding.

The scope question matters

CSA explicitly covers production and quality system software. ERP modules, MES, eQMS, LIMS, automated test equipment, label printers, most of the infrastructure your QMS runs on.

It does not directly cover SaMD or device firmware. Those still fall under IEC 62304 and the device software lifecycle guidance. But the critical-thinking philosophy is bleeding into device validation. Auditors who got used to CSA rationales for production software ask better questions about device software too.

If your team is still writing 80-page IQ/OQ documents for an ERP upgrade, you are working harder than the FDA expects.

Three things worth doing this quarter

I'd audit the validation backlog first. Find the systems where CSA could legitimately reduce documentation effort. ERP, eQMS, label printing, automated testing. Pick the easiest win and run a small pilot.

I'd rewrite one validation SOP to incorporate rationale documentation. Get it through change control. Apply it to the next software change that fits.

And I'd train your validators on rationale writing. The skill that mattered under CSV was script execution. The skill that matters under CSA is technical writing. The QMS can shift overnight; the team's writing muscle takes longer.

The FDA gave the industry a way to validate software without burying every change under documentation nobody reads. The opportunity is wasted if the SOPs don't change.

VibeVal generates CSA-aligned validation rationales for IEC 62304 software changes. Submit a code diff and a risk class, get back a structural verdict, a written rationale and a SHA-256 attestation hash for the DHF. Pay per check.