Picture the validation binder for a label-printing script: four hundred pages, each one a screenshot of a test step with a signature underneath. The script prints lot numbers. The team spends more time photographing tests than writing code, and an auditor still finds the gap nobody tested: what happens when the printer runs out of labels mid-batch.
FDA's Computer Software Assurance guidance was written to end that binder. Computer software assurance (CSA) is FDA's risk-based approach to confirming that software used in device production and quality systems does what it should. FDA finalized the guidance in September 2025. It asks you to spend testing effort where a failure could hurt a patient or product quality, and to accept lighter evidence everywhere else, including the output of your automated tests.
What does FDA's computer software assurance guidance cover?
The guidance, Computer Software Assurance for Production and Quality System Software, applies to software that a medical device manufacturer uses in production or in its quality system: MES, LIMS, complaint handling, CAPA tools, label printing, test equipment scripts. It does not apply to software that is itself a device or runs inside one. It supersedes section 6 of FDA's 2002 General Principles of Software Validation.
Under QMSR, which took effect February 2, 2026, ISO 13485 requires validation of software used in the quality system (clause 4.1.6) and in production (7.5.6). CSA is how FDA expects you to scale that work to risk.
CSA vs CSV: what changes for a development team?
| Traditional CSV | Computer software assurance | |
|---|---|---|
| Starting question | "Did we document every test?" | "What happens to patients or quality if this fails?" |
| Effort | Same depth for every function | Deep on high-risk, light on low-risk |
| Test style | Scripted, step by step | Scripted for high risk; unscripted and exploratory for the rest |
| Evidence | Screenshots and signatures per step | Summary records, test logs, CI output |
| Vendor and tool assurance | Re-test everything | Rely on supplier evidence where justified |
Our CSA vs CSV comparison goes deeper on the quality side. For a developer, the practical shift is this: a green CI run with a stored log counts as evidence, if you can tie it to a requirement and a risk level.
How do you classify risk under computer software assurance?
The guidance draws one line. A software feature carries high process risk when its failure could compromise safety, such as a wrong value released on a label or a missed sterilization parameter. Everything else is not high process risk.
Use three questions per feature:
- If this function fails silently, can a nonconforming product reach a patient?
- Does a person or another system catch the failure before release?
- Does the function create or change a regulated record?
A yes to the first and a no to the second puts the feature in the high-risk tier.
What evidence does FDA accept under CSA?
For high-risk functions, keep scripted tests with expected results and a pass or fail record. For everything else, the guidance accepts unscripted testing such as exploratory or ad hoc tests, with a short record of what you tested, when, who, and the outcome.
That maps onto a CI pipeline:
# .ci/assurance.yml
assurance:
high_risk: # scripted, traced to requirement IDs
- test: tests/label/test_lot_number_matches_batch.py
requirement: REQ-LBL-004
risk: high
standard: # unscripted / automated, summary record
- suite: tests/ui
risk: not-high
record:
store: s3://qa-evidence/{release}/
keep: [junit.xml, coverage.xml, commit_sha, reviewer]
Store the log, the commit, the requirement IDs and the name of the person who reviewed the result. That set is your validation record.
Does skipping software assurance show up on Form 483s?
Yes, and under QMSR it carries ISO clause numbers. Form 483s issued since February 2026 in the Atlas Form 483 directory cite production and service provision (ISO 13485 7.5), which includes validation of processes (7.5.6). Three examples:
- Klarity Medical Products, Heath, Ohio, May 2026: 8 observations, including procedures for validation of processes not documented.
- Marlen Manufacturing & Development, Bedford, Ohio, May 2026: 4 observations, including the same process validation finding (7.5.6).
- Light Age, Somerset, New Jersey, May 2026: 18 observations, starting with QMS documentation under clause 4.
On the drug side, the equivalent finding cites 21 CFR 211.68. Our post on 21 CFR Part 11 audit trail requirements covers that, and the audit trail tests used in computerized system validation list what a reviewer will try.
A CSA checklist for your next release
- Write the intended use of each feature in one sentence.
- Tag each requirement with a risk tier.
- Script and trace tests for high-risk features only.
- Keep CI logs, commit SHA and reviewer as the record for everything else.
- Use supplier evidence for platforms and libraries, and document why you trust it.
- Re-assess risk when intended use changes, not on every commit.
FAQ
What is computer software assurance?
Computer software assurance is FDA's risk-based approach to establishing confidence that software used in medical device production or quality systems works for its intended use. It focuses testing on features whose failure could affect patient safety or product quality and accepts lighter, unscripted evidence elsewhere.
When did FDA finalize the CSA guidance?
FDA finalized "Computer Software Assurance for Production and Quality System Software" in September 2025, after a 2022 draft. It supersedes section 6 of the 2002 General Principles of Software Validation for this type of software.
What is the difference between CSA and CSV?
Computer system validation applies the same scripted, documented testing to every function. Computer software assurance scales effort to risk: scripted tests for high process risk, unscripted or automated testing with summary records for the rest.
Does CSA apply to software that is a medical device?
No. The guidance covers software used in production and the quality system, such as MES, LIMS or CAPA tools. Software in a medical device or software as a medical device follows separate premarket guidance.
Can CI test logs count as validation evidence?
Under CSA, yes for features that are not high process risk, as long as the record shows what you tested, the result, the date and who reviewed it. High-risk features still need scripted tests traced to requirements.
I work on Atlas Compliance, which tracks FDA inspections and Form 483 observations for pharma and medical device quality teams. The FDA inspection directory is free to browse.
Top comments (0)