The question this guide answers
A validation lead inherits a 60-requirement URS for a new quality system and a date. Somewhere in the middle of that list is a requirement like "the system shall retain a record of who approved each document revision." Another says "the system shall let a user sort the document list by title." Both are requirements. Treating them the same way is how validation projects lose three months.
That's the gap this guide is about. CSA gives you a defensible basis for treating those two requirements differently — but only if you can show the reasoning that put each one where it landed.
What actually changed, and what didn't
FDA's Computer Software Assurance for Production and Quality Management System Software became final guidance in September 2025, after the September 2022 draft, and was updated in February 2026. That update retitled it from "Quality System" to "Quality Management System" software, re-anchoring the guidance to the QMSR that took effect on 2 February 2026.
Two things are worth being precise about, because both get misread:
- CSA is a device guidance. It comes from CDRH and CBER and addresses software used in medical device production and the quality management system. Pharmaceutical teams apply its critical-thinking logic widely and sensibly, but it is not a pharma mandate — don't present it to an EU GMP inspector as though it were.
- CSA changes the how, not the what. The obligation to have confidence your software is fit for its intended use did not move. Part 11 controls for records, signatures, audit trails, and access did not move. What moved is the expectation that you spend your effort where the risk is, instead of producing uniform documentation across every requirement.
The practical shift: the burden changed from "prove you tested everything the same way" to "show why you tested each thing the way you did." That second burden is lighter in total effort and heavier in reasoning — which is why the record of the decision matters as much as the test.
The decision tree
Walk this per requirement, not per system. A single system will have requirements landing in every branch.
Question 1 — Does this feature affect patient safety, product quality, or data integrity?
No → this is where the guidance most clearly permits lighter effort. A sort control, a display preference, a cosmetic layout choice. Unscripted testing with a recorded outcome is generally proportionate. Note it and move on.
Yes → continue to question 2. Most requirements in a quality system land here, and that's expected — it doesn't mean everything needs the same depth.
Question 2 — Is the feature's correct behaviour something you rely on for a quality decision?
Direct reliance → the calculation that determines a disposition, the routing that enforces an approval, the audit trail an inspector will read. Scripted testing with documented expected results, evidence capture, and traceability to the requirement. This is the CSV-depth branch and CSA does not soften it.
Indirect reliance → the feature supports the process but a failure would be visible and recoverable before it affected a record. Risk-based scripted or robust unscripted testing, scaled to how detectable the failure is.
Question 3 — Would a failure be detected before it affected a regulated record?
This is the question teams skip, and it's the one that most changes the answer. A defect in a field that a second person reviews before release is a different risk from a defect in a background job nobody watches. Detectability is a legitimate input to assurance depth — but only if you can point to the control that does the detecting.
Question 4 — What did the supplier already test competently?
CSA expects you to leverage credible supplier evidence rather than blindly re-testing what the vendor tested. What you can't outsource is your intended use and your configuration: how you set the system up, which features you rely on for quality decisions, and whether those behave correctly in your process. Assess the supplier's development and testing discipline once; then concentrate your own effort on your configuration and your use.
Where each branch lands
| Branch | Typical assurance activity | Record the branch owes |
|---|---|---|
| No safety/quality/integrity impact | Unscripted testing — exploratory or ad-hoc, performed by someone who understands the intended use. | That the testing happened, who did it, what the outcome was, and the rationale for treating the requirement as low-risk. |
| Indirect reliance, high detectability | Robust unscripted testing, or scripted testing with lighter evidence capture. | The above, plus the specific control you are relying on to detect a failure. |
| Direct reliance on a quality decision | Scripted testing with pre-defined expected results and captured evidence. | Requirement, risk rationale, test steps, expected vs actual, evidence, reviewer, and traceability back to the requirement. |
| Supplier-tested, unchanged by you | Supplier assessment; targeted verification of your configuration and intended use. | The supplier assessment itself, and a clear boundary statement of what you verified versus what you leveraged. |
The right-hand column is the part that gets underestimated. A lighter test does not mean a lighter record of why it was lighter — under CSA, the rationale is the deliverable that makes the lighter test defensible.
Three places this goes wrong
- Treating CSA as permission to stop testing. It isn't a reduction in assurance; it's a reallocation of it. Teams that read it as "less work" tend to under-test the high-risk branch too, which is the one that gets inspected.
- Classifying once, then never revisiting. A requirement's risk classification is a decision made at a point in time. When the process changes, or the feature starts carrying a decision it didn't carry before, the classification is stale and so is the assurance behind it.
- Reasoning that lives in someone's head. The most common practical failure isn't a wrong classification — it's a right classification with no recorded rationale. Two years later, the person who made the call has moved on, and what's left is a light test with no visible justification.
Inspector perspective: the revealing request is not "show me your test scripts." It's "show me a requirement you decided was low-risk, and tell me why." If the answer is a documented rationale tied to intended use and risk, the conversation is short. If the answer is that it seemed minor, the depth of every other classification is now in question.
How Complere supports the decision
Validating a new quality system is where this decision meets reality: you're establishing confidence in software you didn't build, on someone else's timeline. Complere is built to shorten that — you inherit a validation package on day one and adapt it, rather than starting from an empty template folder, and the reasoning your team produces stays in the same system as the records it applies to.
- A validation package you can adopt — master plan, requirements, risk assessment, and qualification templates arrive with the platform as a starting evidence set, ready to extend for your own intended use.
- Traceability from requirements through to tests — what you asked the system to do stays connected to the evidence that it does it, so a classification and the testing behind it can be read together.
- Your reasoning kept as controlled records — intended-use statements and risk rationales live as version-controlled documents with role-based electronic sign-off, so the judgement behind a classification is retrievable years later.
- Change that re-opens the right questions — controlled change requests link the documents and training a change affects and carry an effectiveness review, so re-assessment is scoped to what actually moved.
- An immutable audit trail — database-enforced — audit records cannot be modified or deleted, enforced by database-level constraints, so the history behind each assurance decision stands on its own.
For the fuller picture of how we scope our own validation evidence, see the validation approach and the validation pack.