Computer Software Assurance in practice
FDA's Computer Software Assurance (CSA) guidance replaces the habit of testing and screenshotting everything with a simpler question: what could go wrong for product quality or patients if this feature failed, and how much assurance does that call for?
What it is, and what it covers
FDA finalized its Computer Software Assurance guidance in September 2025, after a 2022 draft. On 3 February 2026 it replaced it with Computer Software Assurance for Production and Quality Management System Software, in line with the Quality Management System Regulation (QMSR), the version to use now. It covers software used as part of production or the quality system (such as a quality management system, a LIMS, or a spreadsheet tool used for quality records), not software that is itself part of a medical device. It supersedes Section 6 of FDA's 2002 General Principles of Software Validation.
It's written for device manufacturers, but its risk-based approach matches GAMP 5 (second edition) and is widely used by pharma and biotech teams too.
The four steps
- Identify the intended use. For each feature, function or operation, decide whether it's used directly in production or the quality system, or supports them. Software that only supports them (such as a training reminder) usually needs less assurance.
- Decide the risk-based approach. FDA distinguishes features with high process risk (where a failure could foreseeably compromise safety, for example by letting a nonconforming product be released) from features without it.
- Choose the assurance activities. Scripted testing for high process risk; for the rest, unscripted testing (ad hoc, error-guessing or exploratory) is often enough. Use what the vendor has already done: its testing, its development process and its records.
- Keep an appropriate record. The intended use, the risk decision, what was done, issues found and how they were resolved, the conclusion, and who did it and when. Digital records and system logs are fine; screenshots of every step aren't needed.
A worked example: a configurable quality system
Say you set up a deviation and CAPA process in a configurable system. A CSA-style assessment might look like this:
| Feature | Process risk | Assurance |
|---|---|---|
| Electronic signatures and the approval workflow for deviations | High: a wrongly approved deviation could release affected product | Rely on the vendor's tests of signing and audit trails; run a short scripted test of your workflow (right signers, right order, locked after approval) |
| Required fields and choices on the deviation form | Not high | Unscripted test: try to save incomplete records and wrong values |
| Reminders before CAPAs fall due | Not high (supports the process) | Ad hoc check that a reminder arrives |
| Dashboards of open deviations | Not high | None beyond a quick look; they don't change records |
The record of this is a few pages, not a binder, and it's quick to update when you change the configuration: the change and its assessment go through your change control.
Common mistakes
- Treating every feature as high risk, which recreates the old binder.
- Re-testing what the vendor already tested, instead of reviewing the vendor's evidence and testing your configuration.
- Forgetting that configuration changes need assessment too, not only software releases.