CSA Checklist: Free 37-Point Computer Software Assurance Readiness Check
Check one system's assurance approach against FDA's February 2026 Computer Software Assurance guidance in about 10 minutes: 37 questions across 10 domains, each tied to its section. Get a score, a Red, Amber or Green status per domain and your top 5 gaps.
A Computer Software Assurance (CSA) checklist turns FDA's February 2026 guidance into questions you can answer for one system: is its intended use decided feature by feature, is each function classed as high process risk or not, does the testing method follow that risk, are vendor evidence and existing controls used, does the record hold the intended use, risk result, testing, issues and a conclusion, and are digital records used as evidence. Answer Yes only where your procedure and records already show it.
The 37 CSA checks
Each check restates one recommendation of FDA's final guidance Computer Software Assurance for Production and Quality Management System Software (February 2026), with the section it comes from. Three checks cite the QMSR and the ISO 13485 clauses the guidance points to. The three domains marked core are the ones the rest of the approach depends on.
01 Procedures and QMS basis
QMSR, ISO 13485.
- 1
Does your validation procedure allow validation effort to be proportionate to the risk of the software's use, as ISO 13485 requires under the QMSR?
ISO 13485 4.1.6If not: Revise the software validation SOP so the approach and depth of activities are set per feature or function by documented risk, not one template for every system.
- 2
Have your procedures been updated for the QMSR (in effect since 2 February 2026) and the February 2026 CSA guidance?
QMSRIf not: Update SOP references from the old Part 820 clauses and the superseded September 2025 guidance to the QMSR and the February 2026 CSA guidance.
- 3
Are the people who choose assurance activities trained in risk-based and unscripted testing?
ISO 13485 6.2If not: Train validation, quality and system owners on the CSA risk framework and unscripted testing methods, and keep the training records.
02 Intended use
CSA guidance V.A(1). Core domain.
- 4
Have you determined whether the software is used as part of production or the quality management system, directly or in support, and documented that decision?
V.A(1)If not: Record for each system whether it is used directly, used in support, or not used as part of production or the QMS, with the reasoning, as the guidance recommends.
- 5
Where features, functions or operations have different roles, have you looked at the intended use of each one rather than the system as a whole?
V.A(1)If not: Split complex systems into the features and functions you actually use and record the intended use of each, so effort can differ between them.
- 6
For cloud services (IaaS, PaaS, SaaS), is the decision based on what the service is used for, for example whether it stores quality records?
V.A(1)If not: Assess each cloud service by its use: storage of quality records is used directly, while storage of other data may not need validation.
- 7
Is software outside scope, such as email, accounting or general infrastructure, identified so it is not validated by default?
V.A(1)If not: Add an out-of-scope category to the system inventory for general business and infrastructure software, with the reason for each.
03 Risk-based analysis
CSA guidance V.A(2). Core domain.
- 8
Does the analysis identify reasonably foreseeable failures of each feature, function or operation, not only the likely ones?
V.A(2)If not: Add a step to the risk template that lists foreseeable failures, including rare ones such as a power outage, for each function in scope.
- 9
Is each function classed as high process risk or not, using FDA's test of whether its failure could cause a quality problem that foreseeably compromises safety?
V.A(2)If not: Apply FDA's test to each function and record the outcome, using the guidance's examples of high and not high process risk.
- 10
Does the analysis consider what could stop the software working as intended, such as configuration, security, data integrity, data storage and transfer, and operator error?
V.A(2)If not: Add these factors to the risk template as prompts, so each analysis shows they were considered.
- 11
Is this analysis kept separate from the ISO 14971 device risk analysis, with device risk used only to set rigour for high process risk functions?
V.A(2)If not: Keep the software risk analysis as its own record and reference the device risk file only where a function is high process risk.
- 12
Is the frequency of assurance activities set from the risk analysis?
V.A(2)If not: State in the risk record how often each assurance activity is repeated, for example at each release or periodically, and why.
04 Assurance activities
CSA guidance V.A(4).
- 13
Is the rigour of assurance for high process risk functions set by the device risk, and for the rest by the process risk?
V.A(4)If not: Map each risk outcome to a level of assurance in the SOP, with more objective evidence where the risk is higher.
- 14
Do you use unscripted testing (scenario testing, error guessing, exploratory testing) where it suits the risk?
V.A(4)If not: Allow unscripted methods in the SOP for not high process risk functions, with a short record of objectives, results and issues.
- 15
Do you keep scripted testing, robust or limited, for functions where repeatability, traceability or auditability matter?
V.A(4)If not: Reserve detailed scripted protocols for the functions that need them, and use limited scripts with unscripted testing elsewhere.
- 16
Is the choice of testing method deliberately based on the analysed risk and recorded?
V.A(4)If not: Record next to each function which test method was chosen and why, so the choice can be explained to an inspector.
05 Using existing controls
CSA guidance V.A(5).
- 17
Do you take credit for other controls, such as later inspection or full verification of outputs, to reduce assurance effort?
V.A(5)If not: Note in the risk analysis the downstream controls that would catch a software failure, and reduce testing where they do.
- 18
Do you use the software's own monitoring, logs and error detection after go-live as part of assurance?
V.A(5)If not: Identify the monitoring and alerts the system provides, confirm they work, and cite them as part of the assurance approach.
- 19
Do you use lifecycle tools, such as defect tracking, traceability and automated or iterative testing, instead of repeating that work on paper?
V.A(5)If not: Use the outputs of your defect, traceability and test tools as evidence rather than re-creating them in documents.
- 20
Are supporting tools, such as test automation or debugging tools, checked with a least-burdensome approach rather than full validation?
V.A(5)If not: Classify supporting tools separately and give them a short fitness-for-use check proportionate to their risk.
06 Supplier assessment
CSA guidance V.A(5).
- 21
Is there a risk-based assessment of each software vendor, scaled to the risk of what you use the software for?
V.A(5)If not: Add a vendor assessment step to purchasing controls with levels of effort tied to the software's risk.
- 22
Does the assessment use evidence such as certifications (for example ISO certificates or SOC reports) and development practices, with an on-site audit only where justified?
V.A(5)If not: List the evidence accepted at each risk level and record why an audit was or was not needed.
- 23
Does it review the vendor's cybersecurity practices, such as security risk assessment, security testing and a software bill of materials?
V.A(5)If not: Add cybersecurity questions to the vendor assessment and keep the vendor's answers with the record.
- 24
Does it review the vendor's data integrity controls: record retention and copies, audit trails, encryption, access and electronic signature controls?
V.A(5)If not: Add these data integrity controls to the vendor assessment, and test the ones you rely on during assurance.
- 25
Do you start from the vendor's own validation and testing evidence, and decide only the additional activities you need?
V.A(5)If not: Request the vendor's test evidence, review it, and record which of your intended uses it already covers before planning your own testing.
07 The assurance record
CSA guidance V.A(6). Core domain.
- 26
Does the record state the intended use and the result of the risk-based analysis?
V.A(6)If not: Start every assurance record with the intended use and the risk outcome, as FDA's recommended record does.
- 27
Does it describe the testing done, the issues found and how each was resolved or justified?
V.A(6)If not: Add sections for a description of testing, issues found, and their resolution or risk justification.
- 28
Does it include a conclusion that the software is acceptable for its intended use?
V.A(6)If not: End each record with a conclusion statement on acceptability for the intended use, including any open issues.
- 29
Does it show who performed the testing and when, with review and approval where appropriate?
V.A(6)If not: Capture tester and date for each activity, and add review and approval for higher-risk functions.
- 30
Is the evidence limited to what is needed for the risk, without extra screenshots or duplicated results?
V.A(6)If not: Remove blanket screenshot requirements from the SOP and keep evidence proportionate, enough to serve as a baseline if issues occur.
08 Digital evidence
CSA guidance V.A(6).
- 31
Do you use digital records, such as system logs, audit trails and automated test results, as objective evidence where they exist?
V.A(6)If not: Allow system-generated logs, audit trails and tool results as evidence in the SOP instead of paper copies or screenshots.
- 32
Have you confirmed those digital records are accurate, reliable, intact, available and authentic enough for their use?
V.A(6)If not: Assess each source of digital evidence for these qualities, as the guidance recommends, before relying on it.
09 Changes and validated state
CSA guidance V, V.A(3).
- 33
Are changes to the software assessed with the same risk-based approach before release, so it stays in a validated state?
VIf not: Route software changes and vendor releases through a risk-based impact assessment that decides what to retest.
- 34
For PMA or HDE devices, do you use that assessment to decide whether a software change goes in a 30-day notice or an annual report? (Answer Yes if not applicable.)
V.A(3)If not: Add the guidance's test to change control: a change that may cause a quality problem foreseeably compromising safety goes in a 30-day notice.
10 Electronic records (Part 11)
CSA guidance V.B.
- 35
Have you decided which electronic documents, including assurance records, are required under Part 820 and so fall under Part 11?
V.BIf not: Identify records required under Part 820, such as evidence of validation, and apply Part 11 controls to those kept electronically.
- 36
Do your procedures make clear that Part 11 enforcement discretion on validation does not remove the duty to validate production and QMS software?
V.BIf not: State in the SOP that the 2003 enforcement discretion does not apply to validation required by ISO 13485 under the QMSR, as the CSA guidance says.
- 37
Is assurance for systems holding Part 11 records based on a justified, documented risk assessment covering product quality, patient safety and record integrity?
V.BIf not: Make sure the risk record for these systems covers all three, and focus testing on the features that protect record integrity.
How the scoring works
Each check scores 1 for Yes, 0.5 for Partly and 0 for No, so the overall score is out of 37. Each domain gets a status:
- Green: every answer in the domain is Yes.
- Amber: one No, or some Partly answers. Give each one an owner and a date.
- Red: two or more No answers, or any No in a core domain.
Act on Red domains first, then Amber. Re-run the check once the actions are closed.
Two common situations
Moving an existing system from CSV to CSA
Record the intended use of each function you rely on, classify its risk with FDA's test, and apply the new approach from the next change or periodic review. Start with checks 4, 5, 9, 14, 26, 30 and 31.
Bringing in a SaaS eQMS or other cloud system
The vendor's own evidence is the starting point, so the supplier assessment carries much of the assurance. Decide what the service is used for, assess the vendor at a level set by that risk, and plan for vendor releases. Start with checks 6, 21, 22, 23, 24, 25 and 33.
The guidance today
FDA issued Computer Software Assurance for Production and Quality Management System Software as a final guidance in February 2026. It supersedes the first final version of 24 September 2025, which followed the September 2022 draft, and it cites the ISO 13485 clauses that the QMSR incorporates (4.1.6, 7.5.6 and 7.6 for software validation). The QMSR has been in effect since 2 February 2026. Like all FDA guidance, it is non-binding: you can use another approach if it meets the regulation.
The guidance covers software used in medical device production or the quality management system, including cloud services, automation, data analytics and AI tools used in those roles. It does not cover software that is itself a device. Our CSA guide walks through it section by section, and the 21 CFR Part 11 checklist covers the electronic records side.
A practical aid for self-assessment. It is not regulatory or legal advice and does not replace the guidance, the QMSR, your own procedures or a qualified compliance review.
Sources
Primary documents referred to on this page, from their official publishers.
- 21 CFR Part 11: Electronic Records; Electronic Signatures · eCFR (US)
- Part 11, Electronic Records; Electronic Signatures: Scope and Application (guidance, August 2003) · US FDA
- Quality Management System Regulation (QMSR) · US FDA
- Computer Software Assurance for Production and Quality Management System Software (final guidance, February 2026) · US FDA
- ISPE GAMP 5 Guide, Second Edition · ISPE
What is Computer Software Assurance (CSA)?
FDA defines computer software assurance as a risk-based approach for establishing and maintaining confidence that software is fit for its intended use. The risk to device safety or quality if the software fails to perform as intended sets how much assurance effort and evidence is appropriate, so the burden of validation is no more than necessary to address the risk. The current text is the final guidance Computer Software Assurance for Production and Quality Management System Software, issued in February 2026.
Who does the CSA guidance apply to?
It covers computers and automated data processing systems used as part of medical device production or the quality management system, under the QMSR (21 CFR Part 820, in effect since 2 February 2026). It does not cover device software functions. Drug and biologic manufacturers are not its audience, but many apply the same risk-based reasoning under GAMP 5 Second Edition, which the guidance points to as a resource.
Does CSA replace computer system validation?
No. Validation is still required; CSA changes how the effort is spent. The guidance applies the risk-based approach of FDA's General Principles of Software Validation to production and quality system software and supersedes only Section 6 of that guidance. High process risk functions still get rigorous, often scripted, testing; lower risk functions can rely on unscripted testing, vendor evidence and existing controls.
How is the readiness score calculated?
Each of the 37 checks scores 1 for Yes, 0.5 for Partly and 0 for No. A domain is Green when every answer is Yes, Red when it has two or more No answers or any No in one of the three core domains (intended use, risk-based analysis and the assurance record), and Amber otherwise. The overall score is the total as a percentage of 37.
Is unscripted testing acceptable evidence under CSA?
Yes, where it suits the risk. The guidance describes scenario testing, error guessing and exploratory testing, and its Table 1 shows the record each one needs: intended use, the risk result, a summary of what was tested, issues found, a conclusion on acceptability, and who tested and when. It also recommends using system logs, audit trails and other digital records as evidence instead of screenshots.
Does CSA change how Part 11 applies?
No. Section V.B tells manufacturers to use FDA's 2003 Part 11 Scope and Application guidance to decide whether Part 11 applies. Documents required under Part 820 and kept electronically, such as evidence of validation, are generally electronic records under Part 11. The 2003 enforcement discretion on validation does not apply to the validation of production and quality system software required under the QMSR.