How to Document Critical Thinking Under FDA CSA

How do you document critical thinking under FDA's CSA guidance?

FDA's February 2026 CSA guidance does not prescribe one fixed five-item template. Its examples of assurance records include intended use, the result of the risk-based analysis, testing performed and results, issues found, a conclusion on acceptability, who performed the activity and when, and review or approval when appropriate.

Two teams run the exact same scenario-based test on the exact same low-risk feature. One writes "Pass." The other writes why that level of testing was enough. Only one of them can defend the decision six months later.

What FDA's Guidance Shows in an Assurance Record

FDA's current CSA guidance was revised in February 2026. The guidance uses the term risk-based analysis; it does not use the phrase "critical thinking" as a defined requirement. In its assurance-record examples, FDA shows information such as intended use, the result of the risk-based analysis, a description or results of testing performed, issues found, a conclusion on acceptability, a record of who performed the activity and when, and review or approval when appropriate. FDA also states that alternative documentation approaches may be used when applicable legal documentation requirements are satisfied. In industry practice, the reasoning behind these risk-based decisions is often described as critical thinking.

The Difference a Documented Rationale Makes

Here's the same low-risk feature — a report export button with no GxP data or decision behind it — documented two different ways.

Weak — Status Only

Feature: PDF export button. Testing: scenario-based. Result: Pass.

Strong — Rationale Included

Feature: PDF export button on the internal review dashboard.

Intended use: Internal review only; no GxP decision or record depends on this output.

Risk rationale: No product quality, patient safety, or data integrity impact if this fails — a failed export is immediately visible to the user and does not feed any downstream decision.

Assurance activity: Scenario-based testing, three representative export scenarios.

Result: Correct output in 3/3 scenarios. No issues found.

Conclusion: Adequate assurance for intended use given no GxP impact. Approved: J. Reyes, QA, 2026-08-04.

Both records describe the same testing. The second record makes the basis for the assurance decision easier to review because it connects intended use, risk, activity, results, and conclusion.

Where to Put the Rationale

Keep it as close to the test activity as possible. The practice that holds up best is listing the risk statement directly next to the corresponding test module in the assurance plan, rather than filing it in a separate risk assessment document a reviewer has to go find. If someone has to leave the test record to understand why the testing was scoped the way it was, the documentation isn't doing its job yet.

Common Documentation Mistakes

Risk tier assigned with no reasoning behind it. "Low risk" is a conclusion, not a rationale — the record needs to show what made it low risk.
Rationale copy-pasted across systems. Similar systems can share similar reasoning, but a paragraph duplicated verbatim reads as boilerplate, not judgment applied to this specific feature.
No named reviewer or date. A conclusion without an accountable person and timestamp isn't a record — it's an unattributed opinion.
Documenting the activity but not the "why enough." Recording what was tested without recording why that was sufficient leaves the exact gap an inspector is trained to probe.

How GoVal Supports Critical Thinking Documentation

GoVal captures the risk-based rationale as a structured field tied directly to each test activity, alongside the testing summary, issues, conclusion, and approval, so the reasoning behind every assurance decision lives exactly where the decision itself is recorded. Risk classification at the system level pre-populates the expected depth for each element, keeping rationale consistent across a portfolio without collapsing into copy-pasted boilerplate.

Frequently Asked Questions

How do you document critical thinking under FDA's CSA guidance? +

Capture five elements for each assurance activity: the risk-based rationale explaining why this level of testing is appropriate for this feature, a summary of the testing performed, any issues found, a conclusion on fitness for intended use, and a named approval with a date. FDA's February 2026 guidance illustrates assurance records with intended use, risk-based analysis, testing information, issues, a conclusion, who performed the activity and when, and review or approval when appropriate.

What information does FDA show in its CSA assurance-record examples? +

FDA's examples include intended use, the result of the risk-based analysis, the testing performed and its results, issues found, a conclusion on acceptability, who performed the activity and when, and review or approval when appropriate. The exact record can vary with the assurance activity and applicable documentation requirements.

What's the difference between documenting critical thinking and just writing a test report? +

A test report records what was done and what happened. Documented critical thinking records why that was the right amount of testing to do — the risk factors considered, the intended use of the feature, and the reasoning connecting them to the assurance activity chosen. A report without the rationale shows the what without the why, which is exactly the gap that makes a sound risk-based decision indistinguishable from an arbitrary shortcut at inspection.

Can the same risk rationale be reused across similar systems? +

Only if it's genuinely re-derived for that system, not copy-pasted. Two systems can share a similar risk profile and legitimately warrant similar rationale language, but the record should reflect that the specific system's intended use and risk factors were actually considered, not that a paragraph was duplicated to save time. Reviewers and inspectors can generally tell the difference.

Where should the risk rationale be documented — in the risk assessment or the test plan? +

As close to the test activity itself as possible. Industry practice following FDA's final guidance favors listing the risk statement directly next to the corresponding test module in the validation or assurance plan, rather than filing it in a separate risk assessment document a reviewer has to cross-reference. The goal is that anyone reading the test record can see the reasoning without leaving the page.

What happens if critical thinking isn't documented, even if the testing itself was appropriate? +

The testing decision becomes indefensible even when it was correct. An inspector reviewing an assurance record with no rationale has no way to distinguish a genuinely risk-based decision to use lighter testing from a corner cut to save time — both look identical on paper. Poorly documented reasoning can make it harder to demonstrate why the chosen assurance activity was proportionate to the risk.

How does GoVal support critical thinking documentation? +

GoVal captures the risk-based rationale as a structured field tied directly to each test activity, alongside the testing summary, issues, conclusion, and approval — so the reasoning behind every assurance decision lives exactly where the decision itself is recorded, rather than in a separate document nobody cross-references. Risk classification at the system level pre-populates the expected depth, keeping rationale consistent across a portfolio without becoming boilerplate.

Make every assurance decision defensible, not just correct

Risk-based rationale, testing summary, and approval — captured as one structured record, in GoVal.

Book a Free Demo →