Two routes to the same confidence
Computer software assurance is defined in FDA's guidance as a risk-based approach to establishing and maintaining confidence that software used in production or in the quality management system is fit for its intended use. Computer system validation, as most sites have practised it, pursues the same confidence by a different route: scripted, documented testing of the system's functions, with the depth of testing set largely by convention rather than by the risk each function carries. The objective is identical. The evidence produced is not, and neither is the conversation it supports under inspection.
The inspection question is the one to keep in view throughout: not "is this system validated?", but "how do you know it does what you rely on it for?" A binder of two hundred scripted steps executed against a version four upgrades ago answers the first question. A short record that states the functions the site depends on, the risk assigned to each and why, what was tested and how, what failed and what was done, and what was re-checked at the last release answers the second. Since September 2025 the second form of answer is the one FDA has put its name to. CSV and CSA are compared below on that basis: what changed and when, the four CSA steps applied to a real eQMS function, what process risk means, what an acceptable unscripted record contains, where vendor evidence stops, the questions an inspection puts to eQMS validation, and how to migrate an already-validated system.
What changed on 24 September 2025, and again in February 2026
FDA finalised Computer Software Assurance for Production and Quality Management System Software on 24 September 2025, three years after the 2022 draft. On 3 February 2026, the day after the Quality Management System Regulation took effect, FDA reissued it with terminology aligned to the QMSR: "quality management system" rather than "quality system", and software-validation obligations pointed at ISO 13485:2016 subclauses (4.1.6, 7.5.6, 7.6) rather than the former §820.70(i).
What the final guidance does:
- Supplements the 2002 General Principles of Software Validation and supersedes its Section 6, the part that covered validation of automated process equipment and quality-system software. Sections 1 to 5 of GPSV still stand.
- Scopes itself to software used in production or in the quality management system, which is exactly where an eQMS sits. It does not cover software that is a medical device.
- Replaces "validate everything the same way" with a four-step method: identify intended use, determine process risk, select assurance activities proportionate to that risk, and keep a record that shows the reasoning.
- Names unscripted testing as legitimate evidence where the risk justifies it, alongside scripted testing.
- Illustrates the method for automation tools, data analytics, AI/ML tools and cloud computing, including a worked example built around a SaaS system.
What it does not do: change §11.10(a), §211.68, Annex 11 §4, or the requirement that you can demonstrate a system is fit for its intended use. It is formally a device guidance from CDRH and CBER. Pharma sites adopt the method because their own rules already say "risk-based" and this is the most concrete description any regulator has published of what that looks like.
CSV and CSA: same objective, different route
Both approaches exist to answer one question, "is this software fit for its intended use, and can you show it?". The differences are in how they get there.
| CSV (as commonly practised) | CSA | |
|---|---|---|
| Starting point | The system, and a template of IQ/OQ/PQ documents | The feature and what you rely on it for |
| Risk | Often assessed once, at the system level, then applied uniformly | Assessed per intended use; high process risk vs not high |
| Evidence | Scripted test steps with expected results and screenshots, for everything | Scripted testing where risk is high; unscripted (scenario, exploratory, error-guessing) where it isn't |
| Vendor evidence | Frequently repeated in-house "to be safe" | Assessed and leveraged; repeated only where your intended use differs or the risk demands it |
| The record | The completed protocols | Intended use, risk rationale, activities chosen, results, conclusion, approval |
| Change | Re-execute the affected scripts | Re-assess the affected intended uses; re-test in proportion |
| Failure mode | Effort spent proving documents, not software | Risk rated wrongly, or reasoning not written down |
The last row matters. CSA doesn't remove the ways to get validation wrong. It swaps the paperwork failure for a judgement failure, and judgement is what the record has to show.
The four CSA steps on a real eQMS feature
Abstractions don't survive inspection. Here is the method applied to one module, deviation management, the way a site would actually do it.
Step 1: Identify the intended use. Not "we use the deviation module". The specific things the site relies on it for: capturing the initial description and classification; routing to QA for impact assessment; recording the investigation and root cause; linking to CAPA; QA approval to close; the audit trail on all of that. And, separately, the dashboard that counts open deviations by department.
Step 2: Determine process risk. For each intended use: could a failure of this feature foreseeably lead to a quality problem that compromises safety? QA closure approval: yes, a wrong closure could release an affected batch. The audit trail: yes, its failure undermines every record. Classification logic: yes if it drives escalation. The dashboard: no, a wrong count inconveniences a manager and is caught at the next review. Same module, different risk, different assurance.
Step 3: Select assurance activities. High-process-risk features get scripted testing with defined expected results, executed and recorded: the approval workflow, the signature meaning shown on the record, the audit trail's capture of before-values and reasons. Not-high-risk features get unscripted assurance: exploratory testing of the dashboard against a known set of records, an error-guessing pass on the search, with a short note of what was tried and what was seen.
Step 4: Establish the record. One document per module (or one section of the validation report) that a reviewer can read in twenty minutes: the intended uses, the risk call for each with the reason, the activities chosen, the evidence (scripts and results for the high-risk features; the notes for the rest), any failures and their resolution, and the approval. Dated. Reviewed. Tied to the software version.
That record is what the second team in the opening scenario handed over. Nothing in it is new discipline. What's new is that the effort visibly follows the risk.
What "process risk" means, and the two ways teams get it wrong
CSA's risk question is narrower than a general risk assessment. It asks whether a software failure could foreseeably lead to a quality problem that compromises safety, either directly or through a failure of the quality system to catch it. That's "high process risk". Everything else is "not high", which is not the same as "no risk"; it still gets assurance, just proportionate.
The two failure modes are mirror images:
- Rating everything high. Usually a legacy of the CSV habit and a fear of being asked "why not?". The result is CSA in name only: the same scripted pack, relabelled. Inspectors notice when a spellcheck feature has the same forty-step protocol as batch release.
- Rating everything not-high. Usually because CSA was sold internally as "less work". The result is a two-line note where the release-approval workflow should have a scripted test with evidence. This is the version that produces observations, because the record can't show why light testing was reasonable for a function that decides whether product ships.
The defensible position is the boring one: a per-feature call, written down, with a reason a stranger could follow. The CSV vs CSA decision tree is a one-page version of that call.
Unscripted testing is evidence, if it leaves a trace
The part of CSA that unsettles CSV veterans is that FDA accepts scenario (ad-hoc), exploratory and error-guessing testing as assurance activities. The condition isn't the method. It's that you can show the method was chosen deliberately and was actually performed.
An acceptable unscripted record is short:
- The feature and its intended use, and the risk call that made unscripted testing appropriate.
- Who tested, when, on which version.
- What they tried, in a few lines: "searched deviations by date range, department and status; sorted each column; opened three records from the results and confirmed they matched the filters."
- What they observed, including anything odd and what was done about it.
- A conclusion and a signature.
That's a record an inspector can read and a QA reviewer can approve. What doesn't work is "exploratory testing performed, no issues" with nothing behind it. The absence of a script is fine. The absence of evidence isn't.
Where vendor evidence fits, and where it stops
An eQMS vendor tests its own software. Under CSA (and under GAMP 5's supplier-assessment model) that testing is input you can leverage rather than repeat. Two limits apply, and both matter under inspection.
The vendor's evidence covers the vendor's intended use. If your site relies on a feature in a way the vendor didn't test, or has configured it differently, that gap is yours to assess. Leverage works where intended uses overlap; it doesn't transfer risk.
Vendor testing, including automated regression testing, informs your risk determination; it doesn't make it. A supplier's automated test results tell you that a function behaved as designed on their side, on their release. They reduce how much you need to re-test. They do not replace your intended-use assessment, your risk rationale, or your record. No vendor evidence, however extensive, makes a site's validation automatic, and a validation record that says "vendor tested it" and nothing more will be read as no assessment at all.
The practical pattern: assess the supplier once (quality system, testing practice, release discipline), leverage their evidence for the not-high-risk features, and put your own scripted effort into the handful of high-process-risk functions where your name is on the release decision.
The questions an inspection puts to eQMS validation
Investigators don't audit a methodology. They pick a function and pull the thread. For an eQMS the thread usually runs like this:
- "Show me the intended use for this module." (Do you have one, per feature, or a generic system description?)
- "How did you decide how much to test it?" (Is there a risk determination with a reason, or a template?)
- "Show me the evidence for the approval workflow." (High-risk: scripted, executed, results recorded, on this version?)
- "What did you do for the reporting screens?" (Not-high: a documented unscripted pass, or nothing?)
- "What changed in the last release, and what did you re-check?" (Is there a per-release assessment, or has the validated state quietly drifted?)
- "Who reviewed and approved this record, and when?" (Is validation a living record or an event from 2024?)
- "Where's the vendor's evidence, and what did you do with it?" (Assessed and leveraged, or filed unread?)
Every one of those is answerable from a well-kept CSA record in under a minute. Most of them are hard to answer from a CSV binder without a search.
Download the CSA readiness self-check before the next of those threads. It walks one system through intended use, the risk determination, and whether the evidence you kept matches the route you claim.
Migrating a validated system from CSV to CSA
You don't re-validate to switch. You use the next release.
- Write the intended-use list for the system as it's used today, per feature. This is the document most sites discover they never had.
- Make the risk call per feature and record the reason. Expect a minority to be high process risk.
- Map the existing protocols onto that list. Keep the scripts that cover high-risk features (they're still valid evidence). Retire the ones that over-test not-high features; replace them with an unscripted assurance note at the next release.
- Assess the vendor if you haven't, and record which of their evidence you leverage.
- Put change control on the intended-use list, not just on the software. When the site starts relying on a feature in a new way, that's a validation event.
- On the next release, re-assess only the affected intended uses, test in proportion, and write the release record. That release record, not a re-validation, is your first CSA artefact.
From then on the validated state is maintained release by release, which is what Annex 11 and the system periodic review were always asking for.
How Complere supports a risk-based validation approach
A validation pack arrives with each module, not after it. The planning, requirements, risk assessment, traceability, installation and operational test protocols, a Part 11 checklist and the acceptance summary are delivered per module on day one, so your validation starts from a complete set rather than a blank template.
The risk thinking is already in the pack. Requirements are traced to tests, and the effort behind each test reflects the risk of the function it covers, so you inherit a risk-based structure instead of imposing one on a vendor's scripts.
Your intended use stays yours. The pack is the vendor's evidence, organised so you can leverage it; the intended-use assessment, the risk calls for your site, and the record you sign remain your team's work, as CSA expects.
Each release comes with what changed. You can see what a release touched and re-assess the affected functions in proportion, so the validated state moves with the software rather than lagging four versions behind.
Which functions carry high process risk for a given site, how much testing that justifies and who approves the record are determinations the site makes and signs. Vendor evidence shortens that work; it does not replace the site's own assessment of intended use.
