CSA validation scope planner: computer software assurance, feature by feature
List the features of one system. For each, the planner takes FDA’s computer software assurance steps in order (intended use, high or not high process risk, the assurance activity, the record to keep) and builds a scope table you can print or paste into your plan. It follows the final guidance as reissued on February 3, 2026.
The tool
Edit any field. Pre-filled with a realistic example: a cloud eQMS at a 40-person device maker.
- 01
High process risk leads to: Scripted testing: robust (or a hybrid of scripted and unscripted)
- 02
Not high process risk leads to: Unscripted testing: exploratory testing
- 03
Not high process risk leads to: Unscripted testing: scenario testing (ad hoc)
- 04
Not high process risk leads to: Unscripted testing: error guessing
- 05
Not high process risk leads to: Unscripted testing: exploratory testing
- 06
Not high process risk leads to: Vendor assessment, installation and configuration; no additional testing
- 07
Not high process risk leads to: Vendor assessment, installation and configuration; no additional testing
- 08
Not part of production or the QMS leads to: No validation required; document the decision
Risk calls for 8 features
1 high, 6 not high, 1 outside
High process risk gets scripted testing sized to the medical device risk; everything else gets the lighter activity the guidance pairs with it. The scope table below is the page to print or paste into your plan.
Validation scope: Cloud eQMS v4.2 (SaaS) at a 40-person device maker
Prepared by QA engineer, 2026-10-22
Device maker: the guidance's own scope (production and quality management system software for medical devices).
Scroll sideways for all columns
| Feature and intended use | Risk call and why | Assurance activity | Record to keep |
|---|---|---|---|
| 01 Complaint intake asks whether a correction or removal is needed for product already shippedUsed directly | High process riskIts failure to perform as intended may result in a quality problem that foreseeably compromises safety: the guidance's definition of high process risk (V.A.2). Assurance is sized to the medical device risk.Our judgement: The guidance lists CAPA routing, complaint logging and monitoring data as generally not high, but your failure answer decides; its own product-containment prompt is high. | Scripted testing: robust (or a hybrid of scripted and unscripted)Test objectives, step-by-step test cases and expected results; independent review and approval of the plan when appropriate. |
|
| 02 Document control: route, approve and release SOPs and work instructionsUsed directly | Not high process riskA failure would affect the integrity of the quality record or compliance but not foreseeably compromise safety: the guidance calls this not high process risk in its LMS, e-signature and SaaS examples (Appendix A). | Unscripted testing: exploratory testingHigh level test plan objectives with pass/fail criteria for each objective; no step-by-step procedure. |
|
| 03 Electronic signature on approvals (name, date and time, meaning)Used directly | Not high process riskA failure would affect the integrity of the quality record or compliance but not foreseeably compromise safety: the guidance calls this not high process risk in its LMS, e-signature and SaaS examples (Appendix A).Part 11 still applies to the electronic records this feature keeps; CSA sizes the assurance effort, not whether Part 11 applies (V.B). | Unscripted testing: scenario testing (ad hoc)Testing of features and functions with no test plan. |
|
| 04 Audit trail and role-based access to quality recordsUsed directly | Not high process riskA failure would affect the integrity of the quality record or compliance but not foreseeably compromise safety: the guidance calls this not high process risk in its LMS, e-signature and SaaS examples (Appendix A).Part 11 still applies to the electronic records this feature keeps; CSA sizes the assurance effort, not whether Part 11 applies (V.B). | Unscripted testing: error guessingTesting of failure-modes with no test plan. |
|
| 05 CAPA routing, owner assignment and due-date remindersUsed directly | Not high process riskA failure would not result in a quality problem: not high process risk (V.A.2). Assurance is sized to the process risk. | Unscripted testing: exploratory testingHigh level test plan objectives with pass/fail criteria for each objective; no step-by-step procedure. |
|
| 06 Supplier score dashboard for the monthly quality reviewUsed directly | Not high process riskA failure may cause a quality problem that does not foreseeably lead to compromised safety, which the guidance places under not high process risk (V.A.2). Name the control that catches it in your rationale. | Vendor assessment, installation and configuration; no additional testingNo test plan; the vendor evaluation, installation and configuration records are the evidence. |
|
| 07 Built-in test runner we use to re-test our workflows after vendor updatesSupports | Not high process riskSupporting use is on the guidance's list of features that generally are not high process risk (V.A.2). It must still be validated, but vendor evaluation, installation or configuration records may be enough and additional testing "may be unnecessary" (V.A.5). | Vendor assessment, installation and configuration; no additional testingNo test plan; the vendor evaluation, installation and configuration records are the evidence. |
|
| 08 Single sign-on through the company directoryNeither | Not part of production or the QMSThe guidance says software for general business processes (email, accounting) or infrastructure (networking, user authentication, backup and restore) is generally not used as part of production or the quality management system, so the ISO 13485 validation requirements would not apply.If the same tool stores quality records, it is used directly: re-answer the first question (V.A.1, the IaaS storage example).Part 11 still applies to the electronic records this feature keeps; CSA sizes the assurance effort, not whether Part 11 applies (V.B). | No validation required; document the decisionNo test plan. |
|
Every assurance record also carries (FDA CSA guidance, V.A.6 and Table 1): Intended use; Result of the risk-based analysis; Issues found; Conclusion declaring the software acceptable for its intended use, with the resolution or risk justification of any issue; Who performed the testing and the date; Review and approval when appropriate.
What computer software assurance asks
FDA defines computer software assurance (CSA) as “a risk-based approach for establishing and maintaining confidence that software is fit for its intended use”. The guidance runs one sequence for every feature of a production or quality system: identify the intended use, decide whether the feature is high process risk, pick assurance activities to match, and keep a record sized to what was done. The planner above is that sequence as a form.
The risk call is deliberately binary. FDA presents process risk as “high process risk” or “not high process risk”; if your SOP grades risk as moderate, intermediate or low, the guidance says the not-high portions apply. That is why the planner has two risk answers and not five. If you are new to the idea, read CSA vs CSV: what changed first; for the lifecycle it sits inside, read computer system validation for small labs.
How to use this planner
- 01Split the system into features. The guidance asks you to look at the intended use of each feature, function or operation, because one system can hold a feature whose failure can reach a patient (FDA's product-containment prompt) and one whose failure cannot (a help menu). If every feature shares one use, plan the system as one row.
- 02Say what each feature is for. Used directly (it automates production or a QMS process, or keeps a quality record), supporting (a tool that tests or monitors that software, or record-keeping outside the quality record), or neither (email, accounting, network, log-in, backup).
- 03Ask what a failure would cause. Not how likely it is. The guidance asks for failures that are reasonably foreseeable, "as opposed to likely": a power cut counts. Then decide whether that failure could reach safety, or stops at a quality problem, a record problem or a delay.
- 04Take the suggested activity, or overrule it. The planner pairs each risk call with the activity the guidance pairs with it. Overrule it where your own tests fit better; the guidance says the pairings are not exclusive.
- 05Print the scope and file it. The table is the start of your record: the intended use and the risk result are the first two lines FDA recommends every assurance record carries.
The rows feed straight into the rest of the pack: each feature becomes a numbered requirement in the URS template, and each risk call and activity becomes a row in the traceability matrix, so a reviewer can follow a feature from requirement to risk to test.
How the risk call is made
FDA calls a feature high process risk “when its failure to perform as intended may result in a quality problem that foreseeably compromises safety”. The test is the consequence of failure, not the feature’s type, which is why the planner’s second question decides the call. The guidance then gives examples of features that are generally high process risk, those that:
- keep process parameters (temperature, pressure, humidity) that affect product properties essential to device safety;
- measure, inspect, analyze or decide acceptability of product or process "with limited or no additional human awareness or review";
- correct or adjust process parameters from monitoring data or automated feedback without human review;
- produce instructions for use or other labeling needed for safe operation of the device;
- automate surveillance, trending or tracking of data the maker identifies as essential to device safety and quality;
and features that generally are not high process risk, those that:
- collect and record process data for monitoring and review with no direct impact on production.
- run CAPA routing, complaint logging and tracking, change control or procedure management.
- manage data, automate an existing calculation, add monitoring, or alert on exceptions in an established process.
- support production or the quality management system (the supporting use in step 2).
The lists are a starting point, not the answer. In FDA’s ERP examples the same restocking feature is not high when a qualified person checks the materials before use, and high when the system does that check with no person. The planner flags any calculation or parameter feature you mark not high, so the human check that justifies it gets written down.
Worked example: FDA's own cases through the planner
Fifteen features from the guidance’s worked examples and its four appendix systems (a nonconformance system, an LMS, a business intelligence tool and a SaaS PLM), entered into the planner as a user would. The planner columns are computed live by the tool.
Scroll sideways for all columns
| Guidance example | FDA's call and activity | Planner's call and activity | Compared |
|---|---|---|---|
| Nonconformance initiationApp. A, Table 2 | Not high process riskExploratory testing with high level objectives | Not high process riskUnscripted testing: exploratory testing | Same |
| Nonconformance e-signature functionApp. A, Table 2 | Not high process riskScenario testing with users | Not high process riskUnscripted testing: scenario testing (ad hoc) | Same |
| Product containment prompt (correction or removal)App. A, Table 2 | High process riskDetailed scripted test protocol with repeatability testing | High process riskScripted testing: robust (or a hybrid of scripted and unscripted) | Same |
| LMS access control, user management, notificationsApp. A, Table 3 | Not high process riskUnscripted testing, error guessing | Not high process riskUnscripted testing: error guessing | Same |
| LMS record-keeping and reportingApp. A, Table 3 | Not high process riskUnscripted testing to "break" the system; failure modes recorded | Not high process riskUnscripted testing: error guessing | Same |
| BI connectivity and data integrityApp. A, Table 4 | High process riskDetailed scripted test protocol with repeatability testing | High process riskScripted testing: robust (or a hybrid of scripted and unscripted) | Same |
| BI user help menuApp. A, Table 4 | Not high process riskNothing beyond vendor evaluation and installation | Not high process riskVendor assessment, installation and configuration; no additional testing | Same |
| BI reporting (supplier-validated)App. A, Table 4 | Not high process riskNothing beyond vendor evaluation and installation | Not high process riskVendor assessment, installation and configuration; no additional testing | Same |
| SaaS PLM project initiation and planningApp. A, Table 5 | Not high process riskConfiguration verification and exploratory UAT | Not high process riskUnscripted testing: exploratory testing | Same |
| SaaS PLM access control and traceabilityApp. A, Table 5 | Not high process riskAutomated test script for access controls plus exploratory UAT | Not high process riskUnscripted testing: error guessing | Same risk; method differs |
| Spreadsheet graphing nonconformance dataV.A.6 | Not high process riskRapid exploratory testing | Not high process riskUnscripted testing: exploratory testing | Same |
| ERP restocking, checked by a qualified personV.A.2 | Not high process risk"Intermediate (not high)"; remaining activities, method not named | Not high process riskUnscripted testing: exploratory testing | Same risk; guidance names no method |
| ERP automated material check, no personV.A.2 | High process riskActivities sized to the medical device risk, method not named | High process riskScripted testing: robust (or a hybrid of scripted and unscripted) | Same risk; guidance names no method |
| GUI test-script tool in a separate test environmentV.A.2, V.A.1 | Not high process risk"Low (not high)"; remaining activities, method not named | Not high process riskVendor assessment, installation and configuration; no additional testing | Same risk; guidance names no method |
| Email or accounting applicationV.A.1 | Not part of production or the QMSValidation requirements would not apply | Not part of production or the QMSNo validation required; document the decision | Same |
Every risk call matches FDA’s. One method differs: for the SaaS PLM’s access control and traceability functions, FDA’s manufacturer wrote an automated test script for the access controls, so it re-runs after every SaaS update, plus exploratory UAT of the reports; the planner suggests error guessing. The guidance allows both: a maker “may find it more effective and efficient to develop scripted testing and automate it for not high process risk features”. If you re-test after every vendor release, overrule the planner and choose limited scripted testing.
Less testing where the risk allows, and a lighter record
Before testing anything, the guidance asks what already protects you. It names six things a maker can lean on to cut assurance effort: established processes that control or fully verify the work the software touches, purchasing controls over the vendor (including the vendor’s own development and validation work), extra process controls, the monitoring data the software collects, life-cycle tools such as bug trackers and traceability tools, and testing repeated in iterative cycles across the software’s life. For some lower-risk features, the vendor’s work “may be all the assurance that is needed”.
The record shrinks with the risk. A robust scripted test keeps step-by-step cases, expected results and a result for each case; exploratory testing keeps objectives with pass/fail criteria and a summary; a feature resting on the vendor assessment keeps its intended use, risk result, conclusion and who assessed it when. FDA also recommends system logs, audit trails and other data the software already keeps “as opposed to paper documentation, screenshots, or duplicating results already digitally retained by the software”. The protocols for the scripted rows go in the IQ OQ PQ template.
Device makers, drug and biologics labs, and Part 11
The guidance covers “computers or automated data processing systems used as part of production or the quality management system for medical devices”. It was issued by CDRH and CBER (CBER for the devices it regulates), in consultation with CDER, and it does not cover device software functions. For device makers it now reads against the amended Part 820, which took effect on February 2, 2026 and incorporates ISO 13485:2016; software validation sits in its subclauses 4.1.6, 7.5.6 and 7.6. More on that change in the FDA QMSR guide.
FDA wrote CSA for device makers; its risk ideas are often borrowed elsewhere. A drug, biologics or GLP lab that uses this planner is using it as a reference, not meeting a guidance written for it. In our judgement the adaptation is to read “foreseeably compromises safety” against your own product and your own predicate rules, and to record why. It sits comfortably beside EU Annex 11 § 1, which asks that“decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment”, and beside GAMP 5, which FDA itself lists as a resource; see what GAMP 5 is.
CSA does not switch Part 11 off. The guidance says a document Part 820 requires, kept electronically, would generally be a Part 11 electronic record, and that FDA’s Part 11 enforcement discretion on system validation “expressly does not apply” to validation of production and quality system software under ISO 13485. Check a record with the Part 11 applicability checker; tools that run the test protocols electronically are compared in paperless validation software.
Three misreadings to avoid
Misreading: “CSA replaced CSV”
It did not. The guidance supplements FDA’s General Principles of Software Validation and supersedes only its Section 6. Validation is still required; CSA changes how much evidence a feature needs.
Misreading: “Not high process risk means no testing”
Only sometimes. In FDA’s own tables most not-high features still get scenario, error-guessing or exploratory testing; the vendor assessment alone was enough for a help menu and for reports the supplier had validated.
Misreading: “The CSA guidance is still a draft”
The draft was September 13, 2022. FDA finalised it on September 24, 2025 and reissued it on February 3, 2026 under a new title, “Computer Software Assurance for Production and Quality Management System Software”.
Where the rule says so
The rule text and guidance this planner is built from, each read on the date shown.
- Computer Software Assurance for Production and Quality Management System Software (final guidance, PDF), FDA, CDRH and CBER, February 3, 2026read 2026-10-22
- Computer Software Assurance for Production and Quality Management System Software (guidance page), FDAread 2026-10-22
- Computer Software Assurance for Production and Quality System Software, notice of availability (90 FR 45945), Federal Register, September 24, 2025read 2026-10-22
- 21 CFR Part 820, Quality Management System Regulation, eCFRread 2026-10-22
- EudraLex Volume 4, Annex 11: Computerised Systems (PDF), European Commissionread 2026-10-22
- GAMP 5 Guide, 2nd Edition, ISPEread 2026-10-22