FDA Computer Software Assurance: What Changed and What Didn't

FDA finalized the Computer Software Assurance (CSA) guidance on September 24, 2025, and issued a revised version on February 3, 2026. The draft had circulated since September 2022, which means industry spent about three years operating under the draft’s principles, and now those principles carry the full weight of final FDA guidance. If you work in computer system validation, you need to understand exactly what this guidance says, because “critical thinking over documentation” is no longer an industry aspiration. It is what FDA expects.

Here is what the guidance actually requires, what it changes in practice, what questions the finalization answered, and which ones are still being worked out in inspection practice.

The reference document is FDA Computer Software Assurance for Production and Quality Management System Software, Final Guidance for Industry and FDA Staff, issued 3 February 2026. That version supersedes the 24 September 2025 final guidance, which carried the shorter title “Computer Software Assurance for Production and Quality System Software.” The February 2026 revision is a terminology and citation alignment with the Quality Management System Regulation (21 CFR Part 820), effective 2 February 2026; it did not change the risk-based assurance approach. Cite the current title and date carefully, because reciting the draft title for the final guidance is a common tell.

This article applies across pharmaceuticals, biologics, medical devices, combination products, and the broader life sciences. The CSA logic is the same whether the software runs a tablet press, a bioreactor, an analyzer, a device-manufacturing line, or a quality management system. The examples below are drawn from across those settings on purpose.

The Problem CSA Was Meant to Solve

The traditional CSV (computer system validation) approach that evolved through the 1990s and 2000s became, in many organizations, a documentation exercise. The focus shifted from “proving the system works for our use” to “producing a thick binder of test scripts that looks like validation.” Companies wrote exhaustive test scripts for every function, executed them, and generated validation reports, regardless of whether the functions tested were critical to GxP use.

FDA had been seeing this for years: expensive, time-consuming validation efforts that generated large documentation packages but did not actually reduce the risk of system failures in use. There is a well-known failure pattern behind this. When validation is measured by page count, teams optimize for page count. A login screen gets the same twelve-step scripted protocol as the audit trail engine, a screenshot is captured for every step, a second person reviews every screenshot, and at the end the binder is thick and the genuinely risky behavior of the system has been tested no more carefully than the trivial behavior. Worse, the cost of this exercise discourages teams from making system changes at all, so improvements that would reduce risk get deferred because revalidation is too expensive.

The 21st Century Cures Act (Public Law 114-255, signed December 2016) included a directive to FDA to reduce burdens from unnecessary or duplicative records and to modernize how the agency thinks about software. CSA was one of the responses. The agency had also published its “General Principles of Software Validation” guidance through the Center for Devices and Radiological Health back in January 2002, and CSA supersedes Section 6 of that guidance (“Validation of Automated Process Equipment and Quality System Software”) and supplements the remainder, carrying its risk-based logic specifically into production and quality management system software. The final CSA guidance is formally a device and quality-system document, implementing 21 CFR 820.70(i), so its principles apply directly to medical device production and the quality management system; in drug and biologic computerized-system validation those same principles are adopted by analogy rather than as the governing FDA guidance. The critical-thinking logic now also runs through 21 CFR Part 820 as revised by the Quality Management System Regulation, which harmonizes with ISO 13485. See the pharmaceutical quality system.

The CSA guidance is framed explicitly as a mechanism to reduce the level of unnecessary documentation and testing burden while maintaining an appropriate level of assurance.

For readers new to the term

If you are early in a GxP quality career, two definitions will keep the rest of this article readable. “Assurance” is the confidence that a system does what you intend it to do for your regulated use. “Validation” is the documented activity that produces and records that confidence. CSA does not replace validation. It is a way of thinking about how much and what kind of evidence each function actually needs. For the broader framework that CSA sits inside, see the GAMP 5 CSV framework and GxP computerized systems operations.

Scope: what CSA covers and what it does not

The title of the guidance is precise. CSA addresses “production and quality management system software” (the 2022 draft omitted “management”), which the document defines as software used as part of production or the quality system. That includes a manufacturing execution system, a laboratory information management system, a quality management system, a deviation or CAPA tracking tool, an automation layer on production equipment, a label management system, and the data acquisition software on an analytical instrument.

CSA does not cover, and the guidance says so explicitly, software that is itself a medical device or part of a device (Software as a Medical Device and software in a device follow IEC 62304, device design controls, and device software cybersecurity). It also does not address the validation of the manufacturing process itself, which is process validation. Knowing the scope boundary is an interview question in its own right: CSA is about the software that supports making and assuring product, not the product, and not the process.

What CSA Actually Says

The core argument of the CSA guidance is that the purpose of validation is to provide confidence that a system performs as intended, and that documentation-heavy test scripts are not the only way to achieve that confidence. In some cases they are not even the best way.

Intended use is the anchor. The CSA guidance emphasizes that assurance activities should be calibrated to the intended use of the software and the risk that incorrect operation would create. This is not a new idea. GAMP 5 has said this for years. But CSA formalizes it as FDA’s stated expectation, and it ties the scope of testing directly to a two-step question: what is this feature used for, and what happens if it is wrong.

Testing approaches exist on a spectrum. The guidance describes a graduated set of testing methods:

• Scripted testing: Test steps, expected results, and acceptance criteria are predefined before execution. This is the traditional CSV approach. The guidance further distinguishes rigorous scripted testing (independent review, detailed evidence) from limited scripted testing (less independent oversight for lower-risk items).
• Unscripted testing, including exploratory testing: A tester exercises the system based on expertise and judgment, documenting what was tested and what was found, without predefined step-by-step scripts. Useful for discovering unexpected behavior that a fixed script would never look for.
• Ad hoc testing: Informal testing during regular use, without specific documentation objectives, suitable only for the lowest-risk situations.

CSA’s contribution is the pairing of method to risk. For lower-risk functions, or well-established software with extensive prior use history, unscripted or ad hoc testing may provide adequate assurance. For high-risk functions, those directly affecting product quality, patient safety, or the integrity of GxP records, scripted testing with documented acceptance criteria remains appropriate.

The guidance does not say “you can stop scripting tests.” It says you should apply testing rigor in proportion to risk.

Use supplier activities. If a software vendor has a mature development process, documented testing, and regulatory compliance documentation, that evidence can be incorporated into the site’s assurance activities. The site does not need to re-execute tests the vendor has already performed rigorously. This is consistent with GAMP 5 supplier assessment guidance and with the use-vendor-evidence logic of supplier and vendor qualification and software supplier assessment under CSA.

Critical thinking over documentation. This is the phrase that appears in every CSA presentation. What it means in context is that the mere creation of documentation does not add to the assurance of a system’s suitability for its intended use. A validation that produces documentation without demonstrating critical thinking about risk, what could go wrong, how the testing addresses that risk, and why the evidence is sufficient, is not what FDA is looking for.

The four-step method the guidance lays out

The guidance is unusually concrete about the sequence it expects. It is worth memorizing because it is the skeleton of any CSA-aligned validation plan, and because interviewers ask for it by name:

1. Identify the intended use of the software feature, including whether it is part of production or the quality system.
2. Determine the risk the feature poses. The guidance splits this into whether the feature has a direct or indirect impact, and then the probability and severity of harm if it fails.
3. Determine the appropriate assurance activity and select the testing method that matches the risk.
4. Establish the record that captures the activity, keeping it proportionate to the risk rather than uniform across all features.

The sequence only runs one direction. A record cannot justify itself backward into a risk decision that was never written down, which is the failure mode the finalized guidance is most concerned with.

Notice that risk determination sits at step two, not buried in an appendix. The risk decision drives the testing decision, and the record exists to document both. For the mechanics of doing step two well, see CSV risk assessment methodology and the broader quality risk management approach.

A useful way to internalize the four steps is to write them as a single sentence the auditor can read off your plan: “This feature is used to X (intended use), a failure would Y with severity/probability (risk), so we applied Z testing (assurance method), recorded as W (record).” Every feature in a CSA-aligned plan should be expressible in that one sentence. If you cannot finish the sentence, you have not finished the analysis.

A small numeric example of the risk step

The guidance does not mandate a scoring scale, but most programs use a two-axis judgment of severity and probability of detection or failure. A simple, defensible matrix looks like this:

The point of writing the matrix down is not the number. It is that two reviewers given the same feature should land in the same cell, and an inspector reading the cell should agree the method matches it. A scale nobody can reproduce is decoration. Keep it coarse, keep it justifiable.

Direct vs Indirect Impact: The Distinction That Does the Work

Most of the practical savings in CSA come from one classification: does a software feature have a direct or an indirect impact on product quality or safety.

A direct impact feature does something where a failure could affect the product, the GxP record, or the patient with no intervening human check. A manufacturing execution system that calculates a yield, enforces a recipe parameter, or releases a batch step has direct impact. An electronic batch record that captures the official record of manufacture has direct impact. A laboratory system that performs a specification comparison and flags an out-of-specification result has direct impact. A device-history-record system that enforces a required inspection step before a unit advances has direct impact. These features sit in the high-assurance lane, and they get scripted testing with documented acceptance criteria.

An indirect impact feature supports the work but does not by itself determine quality, because a human or another control stands between the feature and the outcome. A feature that schedules a report, sorts a worklist, or formats a label preview is usually indirect. A failure there is annoying but is caught downstream before it can reach the product or the record.

The honest difficulty is that this line is not always obvious, and inspectors will challenge a classification that conveniently routes a risky feature into the easy lane. The defensible move is to write down the reasoning. State the feature, state what depends on it, state what catches a failure if the feature is wrong, and conclude direct or indirect from that chain. A classification that carries a visible chain of reasoning gives a reviewer something concrete to engage with, and it lets you explain the call months later when nobody remembers the meeting where it was made. A bare assertion leaves you with nothing to offer beyond repeating the label. Neither approach guarantees any particular outcome in a given inspection, and the expectations that apply to your products, markets and regulators are yours to confirm, but the difference in how much of the decision you can actually defend is substantial.

A practical test for the borderline cases: ask “if this feature silently produced the wrong output, what is the next thing that would notice?” If the answer is “a person who reviews the output as part of an existing control” or “another system check,” the feature leans indirect, and you record that control as the reason. If the answer is “nothing, the wrong output flows straight to the batch record, the release decision, or the patient,” it is direct. Write the answer in the risk assessment. The control you name becomes load-bearing, so make sure it actually exists and is itself reliable.

A decision tree for the classification

Each branch produces a written answer, not just a label. An inspector reading the trail should be able to follow the same path to the same conclusion from the same facts.

What CSA Doesn’t Change

Validation is still required. The CSA guidance explicitly states that it does not apply to or modify requirements for process validation or the validation of computerized systems used to produce drug products, as those requirements are set forth in current good manufacturing practice. The predicate rules under 21 CFR Part 211 (and the device equivalent in 21 CFR Part 820), and the electronic records and signatures requirements of 21 CFR Part 11, are unchanged. CSA changes how you decide to generate evidence, not whether the underlying legal obligation exists. The same point holds in the EU, where EU Annex 11 and 21 CFR Part 11 still set the computerized-systems expectations regardless of how you scope your testing.

High-risk functions still need scripted testing. For any function that directly determines product release, patient safety, or the integrity of GxP records, scripted testing with documented acceptance criteria is still the standard. The CSA flexibility applies to the low- and mid-risk portions of the testing scope, not to the critical controls.

Audit trails, electronic signatures, and access controls. These Part 11 and Annex 11 requirements are not relaxed by CSA. The testing approach for these controls should remain scripted and documented. If anything, CSA sharpens the expectation here, because by freeing effort from trivial features it removes any excuse for thin testing of the controls that matter. For how to design and review these specifically, see audit trail design and review, electronic signatures implementation, and CSV cybersecurity and access control.

Change control. Any change to a validated system requires documented assessment, testing proportionate to the risk of the change, and updated validation records. CSA actually makes change control more sustainable, because a smaller, risk-focused validation footprint means a change is cheaper to assess and re-test, which removes the perverse incentive to avoid beneficial changes. See change control for validated systems and IT change and configuration management in GxP.

Data integrity expectations. Nothing in CSA loosens ALCOA+ or the data integrity obligations behind it. A risk-based testing approach still has to demonstrate that records are attributable, legible, contemporaneous, original, accurate, and complete. See data integrity foundations and ALCOA+ in detail.

The Practical Shift: What Changes in Practice

If you apply CSA principles correctly, the change is primarily in how you allocate validation effort.

Less exhaustive scripted testing of low-risk, well-established functions. Proving that a login screen accepts valid credentials is vendor-tested functionality in every commercial laboratory information management system, and re-proving it at the site adds cost without adding assurance.

More focused, documented critical thinking about high-risk functions: what could fail, what the consequence would be, and how the testing provides confidence that it will not.

More explicit documentation of the reasoning behind testing scope decisions: why was this function tested at depth, and why was that function addressed through vendor documentation alone.

More use of exploratory testing for discovering unexpected behavior, supplementing scripted tests rather than replacing them for critical functions.

A concrete example. A LIMS has 200 configurable features. Under traditional CSV you might write scripted tests for all 200, even though 160 of them have nothing to do with GxP data management. Under CSA principles you identify the 40 features that are GxP-critical, audit trail, electronic approval, result storage, specification checking, write thorough scripted tests for those, and address the remaining 160 through exploratory testing or vendor documentation. The validation package is smaller. The evidence for the critical functions is just as strong, or stronger.

A worked example, function by function

Take a single GxP-critical function in that LIMS: the out-of-specification flag that fires when a numeric result falls outside a configured limit. A CSA-aligned plan would record the following:

• Intended use: the system compares an entered result against the approved specification and flags results outside the limit so they enter the out-of-specification investigation process.
• Risk: direct impact, because a missed flag could let a failing result pass as conforming, with high severity to product and patient.
• Assurance method: rigorous scripted testing with independent review, covering values below the lower limit, above the upper limit, exactly on each limit, just inside each limit, and edge cases such as rounding behavior, null entries, and unit mismatches.
• Record: the executed protocol with expected and actual results, a deviation log for any discrepancy, and traceability back to the requirement in the requirements traceability matrix.

Now take an indirect function in the same system: the column order in a results grid. Intended use is display convenience, risk is indirect and low because the underlying data is unchanged, the method is a brief exploratory check, and the record is a one-paragraph test summary stating what was explored and that it behaved as expected. Two functions, the same system, two very different evidence footprints, each justified by a written risk decision. That contrast is the whole point of CSA.

A sample scripted test case for the direct-impact function

The OQ test case for the out-of-specification flag is where “acceptance criteria” stops being abstract. A defensible test case has predefined inputs, a predefined expected result, and a pass/fail criterion stated before execution. A sample row set:

Each row carries an expected result and a clear acceptance criterion, the tester records the actual result and a pass or fail, and any fail goes to test failure management rather than being quietly re-run until it passes. The boundary values (on the limit, one increment inside, one increment outside) are the rows an inspector will look for. A test that only checks an obviously-passing and an obviously-failing value has not tested the limit, it has tested the middle of the range.

Acceptance criteria: how you know the CSA approach was done right

A CSA-informed validation generally holds together when these are all true, and the list works well as a self-check to run before you call a package finished. Treat it as a starting point to adapt against your own products, procedures and regulatory context rather than as a fixed compliance test:

• Every GxP function in scope has a documented intended-use statement and a documented direct/indirect risk decision with reasoning, not just a label.
• The testing method for each function matches its risk per a written rule, and the highest-risk functions carry rigorous scripted testing with independent review.
• Acceptance criteria for scripted tests were defined before execution, including boundary and negative cases for the critical functions.
• Where supplier evidence reduced site testing, a documented supplier assessment supports it, and the boundary of what the site still verified is explicit.
• Unscripted and exploratory testing has a purposeful written record of what was tested, what was sought, and what was found.
• The validation summary ties the package back to the risk decisions so the logic is reconstructable end to end.
• Part 11 / Annex 11 controls (audit trail, e-signature, access control) were tested with scripted rigor regardless of how the rest of the system was scoped.

A package missing several of these is not really applying the guidance, it is just a smaller binder. The gap between a genuinely risk-scoped package and a merely thinner one is the thing to watch for in your own program, because the reduced testing is easy for anyone to see and the reasoning that would justify it is exactly the part that tends to go unwritten.

What a defensible risk-rationale paragraph actually looks like on paper

“Critical thinking over documentation” is easy to say and hard to write down. The difference between a defensible risk rationale and a weak one is not length. It is whether the four elements from the one-sentence method earlier, intended use, risk, method, record, are each stated as a specific fact rather than asserted as a conclusion.

Take a vision-based label verification system on a packaging line that compares the printed lot number and expiration date on each carton against the batch record values before the carton is allowed to proceed to case packing.

A weak rationale, the kind that shows up in a rushed validation package:

“The label verification feature is classified as direct impact per CSA and was tested with a scripted OQ per SOP-CSV-004. Testing confirmed the feature functions as intended.”

Read that back as an inspector would. It states a classification without the reasoning behind it, it does not say what “functions as intended” was actually checked against, and the word “per CSA” is doing the work that a risk statement should be doing. Nothing in it could be challenged, because nothing in it is falsifiable.

A defensible rationale for the same feature:

“The vision system compares the printed lot number and expiration date on each carton against the batch record values before the carton is released to case packing. If the comparison silently accepted a mismatched carton, nothing downstream would catch it: cartons are not visually re-checked before shipment, and the case-pack process obscures the individual carton label. This is direct impact, high severity, undetected. We applied rigorous scripted testing with independent review, including a correct-match case, a single-character lot mismatch, an illegible or smeared print, and a camera-fault condition where no read is possible. Evidence is executed protocol OQ-014, referenced in RTM-22.”

The second version survives the follow-up question an inspector actually asks, which is never “was it tested,” it is “why did you decide to test it that way.” The first version has no answer to that question beyond repeating the classification. The second one hands the inspector the exact chain: what the feature does, what fails to catch a wrong output, the resulting classification, the method chosen because of that classification, and where to find the evidence. Nothing in the second paragraph is longer than it needs to be; it is not more documentation, it is documentation of the reasoning that the first paragraph skipped.

Roles and Responsibilities

CSA does not change who is accountable, but it does change what each role has to produce, because the reasoning now has to be visible. A workable RACI looks like this:

Two role points matter most under CSA. First, the system owner owns the intended-use and risk statements, because they understand what the feature does for the business and what depends on it; validation owns the method and the execution. When the risk decision is wrong, it is almost always because the method-owner guessed at intended use instead of asking the owner. Second, QA approves the risk logic, not just the signatures. Under traditional CSV, QA could approve a package by confirming every script was executed and reviewed. Under CSA, QA has to confirm that the scoping reasoning is sound, which is a harder and more valuable review. For how these roles map across a quality organization, see GxP roles and responsibilities and data governance roles and careers.

Applying the Four-Step Method to an AI/ML-Enabled Feature

The CSA guidance was written with deterministic software in mind: a feature does the same thing every time given the same input, so a scripted test executed once stays valid until the configuration changes. An AI or machine learning feature breaks that assumption. Its output is probabilistic, it was shaped by training data rather than written requirements, and its accuracy can drift after go-live even when nobody touched the configuration. The four-step method still applies, the guidance’s logic of intended use, risk, method, record does not become optional, but each step needs an extra question that a deterministic feature never raises. This article’s own scope is the production and quality system software CSA addresses, not the model-lifecycle detail; for the deeper model-specific work see validating AI-enabled GxP systems and the GxP machine learning model lifecycle. What follows is how the four steps translate.

A worked example: two ML features in the same deviation-management system

A deviation-management system adds a machine-learning feature that reads the free-text description of a new deviation and predicts a likely root-cause category, to help route the deviation to the right subject-matter expert. A second proposed feature would use the same kind of model to auto-close deviations the model scores as low-risk and administrative, with no human review. Running both through the four-step method side by side shows why the same underlying model produces two very different assurance pictures.

Feature A, triage routing (indirect impact). Intended use: suggests a likely root-cause category and routing target to speed up assignment; the deviation owner reviews and can override the suggestion before any investigation step begins. Risk: indirect, because a wrong suggestion only misroutes the initial assignment, a person reviews every deviation regardless of the suggestion, and no deviation is closed or dispositioned based on the model’s output alone. Method: an initial challenge-set evaluation against a labeled historical sample, reported as an overall accuracy figure with performance broken out by category, plus a lighter exploratory check of the routing screen itself. Record: the challenge-set evaluation report, and a routine (for example quarterly) accuracy check against newly closed deviations, referenced in the model’s monitoring log.

Feature B, autonomous closure (direct impact). Intended use: closes a deviation without human review when the model scores it below a defined risk threshold. Risk: direct, and high severity, because a false “low-risk” score closes a deviation that should have been investigated, with no downstream check, the review step that Feature A relies on has been removed entirely. Method: this is where the honest answer is that a challenge-set evaluation, however thorough, is not sufficient assurance for an unreviewed, direct-impact decision; the guidance’s own logic (scripted rigor for direct-impact features, no downgrade for convenience) argues against removing the human check at all for this use, or, at minimum, for a staged rollout that keeps a human reviewing every auto-closed deviation for an extended period before the model is trusted to close without any check. Record: if the feature proceeds, the validation record has to include the challenge-set results, the shadow-mode comparison against human decisions during the review period, the drift-monitoring plan, and an explicit, QA-approved statement of when and how the human check can be removed, tied to a predetermined change control plan style governance mechanism rather than a one-time sign-off.

The point of the pair is not that AI features are always indirect or always direct. It is that the same classification discipline CSA applies to a specification-limit check applies to a model, and a model that removes a human check needs a materially stronger assurance case than one that only informs a human’s decision, exactly the same logic the guidance already uses for a scripted limit check versus a worklist sort order. See AI governance for GxP for how the routing and closure decisions above map to a governance and change-control structure, and the ML model monitoring and drift SOP and retraining challenger acceptance form for the ongoing-record piece that a deterministic feature never needs.

What Finalization Means for Your Program

The CSA guidance is now final FDA guidance, which means inspectors are expected to apply it, and companies can cite it as the basis for their assurance approach. This resolves several uncertainties that existed under the draft, but some questions are still being answered through inspection practice.

The uncertainty around draft versus final is gone. For the past three years companies faced the question of whether to apply draft guidance principles or risk an inspector rejecting them. That is settled now. CSA-informed approaches are the expected approach, not an experimental one. If your validation program is still generating documentation-heavy test packages for low-risk configured software, it is worth asking what that effort is actually buying, because the cost is real and the assurance it adds on trivial features is thin. Whether it is also a compliance problem depends on your products, your markets, and the procedures you have already committed to in writing, so that assessment belongs with your own quality and regulatory functions rather than with a general reference article.

Documentation of critical thinking is now a clear requirement. The guidance requires that critical thinking, the reasoning behind scope decisions, the risk logic, the rationale for using supplier evidence, be documented. Not in a prescribed format, but demonstrably present. An inspector reviewing your validation package should be able to reconstruct why you scoped testing the way you did and what risk factors drove that decision. A validation plan that says “scripted OQ testing was applied to the following functions based on risk” needs to be backed by the risk analysis, not just the assertion. The risk that comes with CSA is the inverse of the old one: under traditional CSV you risked over-documenting, under CSA you risk under-documenting the reasoning that justifies a lighter touch.

Supplier evidence has clearer standing but still needs assessment documentation. Using vendor test documentation to reduce site-level scripted testing is one of the most practically important CSA principles. The final guidance supports it, but the mechanism requires a documented supplier assessment. You cannot simply point to a vendor’s SOC 2 report and call it sufficient. The assessment needs to answer whether the vendor’s development and testing process meets the quality bar required to justify relying on their output. For well-established GxP software vendors, this assessment is usually favorable and substantially documented. For niche or emerging vendors it requires more work, and for cloud-delivered software the shared-responsibility boundary needs to be explicit, which is the subject of cloud and SaaS validation and software supplier assessment under CSA.

Unscripted testing documentation remains judgment-dependent. The guidance endorses unscripted and exploratory testing for lower-risk functions but does not mandate a specific record format. In practice, a written test summary, what functions were explored, what the tester was looking for, what was found, and a statement that the system met expectations, is the minimum defensible record. Some organizations use screen recordings for specific functions. Others use structured exploratory test templates. All of these are defensible if they demonstrate purposeful, documented testing rather than activity with no record.

The transition for legacy validation programs. If your organization has established procedures that require complete scripted testing for all functions regardless of risk, those procedures are worth revisiting. An SOP that mandates 100 percent scripted OQ coverage for every Category 4 system commits you to effort that is not tied to any risk judgment, and it is worth remembering that your own approved procedures bind you whatever a guidance document says, so changing them is a change-control activity with its own assessment and approvals rather than a memo. A sensible sequence is to update the validation master plan first, then the validation SOPs, then the qualification approach templates, so that risk-based scope decisions with documented rationale flow down from the governing document instead of appearing inconsistently at project level. See the validation master plan and periodic review.

My view: apply CSA principles fully for new validations and system upgrades. For existing validated systems, a retrospective risk assessment determining which functions actually warranted scripted testing is reasonable documentation of CSA alignment. You do not need to re-execute testing that was already done, but documenting the risk logic ties your historical validation to the current guidance framework. For systems with thin or missing original validation, that effort grows into a remediation question, covered in retroactive validation of legacy systems.

A worked example: retrofitting CSA reasoning onto a system that was already properly validated

The case above, a system that already has a sound, complete traditional CSV validation and just needs its reasoning tied to the current guidance, is a lighter exercise than the never-validated or thin-validation remediation the retrospective legacy templates handle, and it is worth walking through separately so the two do not get confused.

Before. A manufacturing execution system was validated nine years ago under a traditional CSV program. The validation summary report states “OQ-001 through OQ-220 executed and passed” across 220 configured functions, with no risk tiering anywhere in the package: recipe parameter enforcement, batch record capture, and electronic signatures received the identical scripted-test treatment as a report footer format and a dashboard color scheme. The system has run under change control since, so the original test evidence is current.

After. The validation lead runs a retrospective risk assessment against the existing function inventory, using the direct/indirect method from this article, without touching the system or re-executing a single test. The assessment finds 34 functions are direct impact (recipe enforcement, batch record capture, electronic signature binding, audit trail, access control) and 186 are indirect (report formatting, dashboard layout, non-GxP administrative screens, scheduling). For the 34 direct-impact functions, the retrospective assessment simply confirms the existing scripted OQ evidence already meets or exceeds what CSA would require going forward, no action needed beyond the record. For the 186 indirect functions, the team does not retract or invalidate the original passing test scripts; that would serve no purpose and would look, to an inspector, exactly like the reduced-testing-without-reasoning trap this article warns against. Instead, each of the 186 gets a short retrospective rationale on file stating why it was originally tested at that depth and confirming its current low or indirect risk, and the validation master plan is updated so that any future change to one of those 186 functions is scoped by risk going forward rather than automatically re-scripted.

Net effect. Nothing about the system’s validated state changed. What changed is that the next 220 change requests are no longer treated identically: a change to the audit trail configuration still gets full scripted rigor and independent review, while a change to a report footer gets an exploratory check with a written record. The retrospective assessment did not reduce yesterday’s evidence, it changed how tomorrow’s changes are scoped, and it gave the validation package a documented reason a reviewer can follow instead of an unexplained gap between a nine-year-old binder and today’s guidance.

This is a different exercise from a system with no or unreliable original validation, where the question is not “how do we scope future changes” but “can we trust the system’s history at all.” That heavier case is covered by the legacy system classification and remediation risk assessment and the retrospective IQ/OQ protocol for a legacy system, which score the system’s condition first and only then get to function-level risk.

How CSA Sits Beside GAMP 5 Second Edition

A common point of confusion is whether CSA and GAMP 5 compete. They do not. GAMP 5 Second Edition, published by ISPE in July 2022, was revised specifically to align with risk-based, critical-thinking principles, and it predates the final CSA guidance by several years. If your program already follows GAMP 5 Second Edition faithfully, you are already most of the way to CSA alignment.

The cleanest way to hold the two together is by role. GAMP 5 gives you the engineering framework: software categories, the specification and verification approach, supplier assessment, the lifecycle deliverables, and the language for describing configured versus custom software. CSA gives you FDA’s stated expectation about how to scale testing within that framework and the assurance the agency wants to see for production and quality system software. GAMP 5 is the how-to, CSA is the regulatory why and how-much. Use GAMP 5 categories to describe the software, use the CSA four-step method to decide the evidence each feature needs, and document the link between the two.

A quick refresher on the GAMP category numbering, since interviewers pair it with CSA constantly. Go to the ISPE guide for the definitions it publishes; described in my own words, the scheme sorts software by how much of what the system does was decided by you rather than by the supplier. Category 1 is the platform layer you install and patch but do not shape, the operating system or a database engine acting purely as a host for something else. Category 3 is bought software taken exactly as it ships, where nothing about how it behaves came from you. Category 4 is bought software that was built to be set up differently at every site, and where those setup choices are yours. Category 5 is code written for you, whether by a supplier, an integrator, or your own team. An early firmware category from the original numbering was dropped when the guide was revised, which is why the sequence has a gap in it. The practical consequence of the ladder is simple. The further up you go, the more of the system’s behavior exists only because of decisions your organization made, and decisions your organization made are decisions nobody else has verified on your behalf.

One practical caution. GAMP categories describe the nature of the software, not its risk. A Category 4 configured product can contain both direct-impact and indirect-impact features. Do not let the category alone set the testing depth. The category tells you how much could be unique to your configuration, the risk assessment tells you which of those configured features actually matter. CSA is the discipline that keeps those two ideas separate. A Category 5 custom script that only reformats a report for human review can be lower-effort than a Category 4 configuration that enforces a release rule, and CSA lets you say so out loud and defend it.

CSV vs CSA: The Honest Comparison

The right answer for most organizations is to apply GAMP 5 Second Edition principles, which already incorporate CSA-aligned thinking, document risk decisions explicitly, and maintain scripted testing for critical controls. Then monitor FDA inspection outcomes for emerging expectations under CSA, because the body of inspection precedent is still forming.

CSA and Combination Products

The introduction to this article notes that CSA is formally a device and quality-system guidance, implementing 21 CFR 820.70(i), applied to drug and biologic computerized systems by analogy. For a genuine combination product regulated under 21 CFR Part 4, that is not always analogy, and getting the distinction right matters for how you classify a feature.

Part 4’s streamlined approach lets a combination product manufacturer run one base operating system in full, either the drug cGMPs (21 CFR Parts 210/211) or the device quality system (21 CFR Part 820, now the Quality Management System Regulation), and add a defined set of provisions from the other rather than implementing both regulations completely (21 CFR 4.4). See Combination Products: cGMP Compliance Under 21 CFR Part 4 for the full framework. If a manufacturer’s chosen base is the device system, CSA is the FDA guidance that directly governs the production and quality-system software supporting that base, no analogy required. If the base is the drug cGMP system with device provisions added under 4.4(b)(1) (management responsibility, design controls, purchasing controls, and CAPA among them), CSA still applies by analogy to the drug side of the operation, the same framing this article uses throughout, while the added device provisions carry their own design-control expectations.

The genuine wrinkle shows up in software that spans both constituents. Take an assembly-and-fill line control system for a prefilled autoinjector, a drug-led combination product built on a streamlined Part 211 base with 820.30 design controls and 820.100 CAPA added per 4.4(b)(1). One function on that line is an automated crimp-force and container-closure integrity check that gates whether an assembled unit proceeds to packaging, writing its pass or fail result directly to the device history record.

Classify that function against the device-constituent consequence chain and it is direct impact: a false pass lets a compromised container-closure proceed with no further check before the device history record closes on that unit. Classify the same function against the drug-constituent consequence chain, batch disposition, and it looks indirect at first glance, because the disposition decision is a separate human batch-record review that considers the lot’s aggregate crimp-force pass rate rather than any single unit’s result. A classification written only against the drug-release consequence chain would call this function indirect and under-test a control that is, in fact, the only thing standing between a leaking container and a patient.

The working rule: when one feature’s output feeds two different regulatory consequence chains (a drug release decision and a device history record, for example), classify it against each chain separately, and let the more stringent classification govern the assurance method actually applied. Note both classifications and both reasons in the risk assessment, not just the one that was easier to write. For the device-constituent side of that reasoning, including where cybersecurity and premarket submission content intersect with the design-control record, see Software as a Medical Device in Pharma and Combination Products.

CSA and Cybersecurity Assurance Evidence

The CSA guidance itself does not discuss cybersecurity, but the four-step method still has to account for it, because a security failure on a GxP system is a data-integrity failure by another name: an unauthenticated or unauthorized write to a record produces exactly the kind of unreviewed, direct-impact consequence the whole framework exists to catch. Audit trail, electronic signature, and access-control enforcement are already in the scripted-rigor override lane under this article’s “What CSA Doesn’t Change” section; the extension here is what evidence actually demonstrates that those controls hold against a deliberate attempt to defeat them, not only against an ordinary user clicking the wrong thing.

Two places in the four-step method are where cybersecurity evidence belongs, and neither is a new step:

• Step 3, assurance method. Vendor-supplied security evidence, a software bill of materials, static and dynamic scan results, a penetration test report, a documented patch cadence, is a form of supplier evidence under the same principle CSA already applies to functional test evidence: it can reduce what the site needs to independently verify, provided a documented supplier assessment establishes that the vendor’s process meets the bar and the site still confirms its own configuration. A clean penetration test result says the system resisted the specific attacks attempted; it does not say the audit trail is complete or that the site’s role matrix matches its procedures. Neither substitutes for the other, and treating a vendor’s security certificate as if it covered functional correctness (or the reverse) is the same “supplier evidence as automatic” trap the guidance and this article already warn against, applied to a different kind of evidence.
• Step 4, the record. For any feature classified direct-impact because a security failure would compromise it, the assurance record should show that access enforcement, encrypted transmission where applicable, and logging of unauthorized attempts were actually tested, not merely configured. A configuration screenshot showing a security setting turned on is not evidence that the setting was tested to hold under an actual unauthorized attempt.

For a device constituent specifically, FDA’s premarket cybersecurity guidance, “Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions” (current version issued 3 February 2026, superseding the version issued 27 June 2025, which itself superseded the original final version issued 27 September 2023 under the shorter title “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions”), sets the documentation bar for the device’s own secure design and premarket submission content. That guidance governs the device, not the production or quality-system software around it, but the same secure-design and threat-modeling discipline is a reasonable model for the assurance case a CSA-aligned validation should build for a direct-impact feature where the risk is a security failure rather than a functional bug. See Cybersecurity and Access Control for Validated GxP Systems for the practical mechanics of testing these controls, and Software as a Medical Device in Pharma and Combination Products for the device-specific premarket content.

Common Ways CSA Goes Wrong

Adopting CSA badly is its own failure mode, and inspectors have started to see the pattern. A few traps to avoid:

Using CSA as a cost-cutting label without the risk work. The most dangerous version of CSA is a program that cuts scripted testing in half and writes “per CSA, risk-based approach” with no risk assessment behind it. That is not CSA. That is reduced testing with a slogan attached, and it is more exposed at inspection than the old over-documented binder, because the absence of reasoning is now visible.

Routing direct-impact features into the easy lane. When budgets are tight, there is pressure to call a borderline feature indirect. Resist it, and document the call honestly. A defensible direct or indirect decision has a written chain of reasoning, an undefensible one has a convenient conclusion.

Treating supplier evidence as automatic. A vendor certificate is an input to a supplier assessment, not a substitute for one. The assessment is where you decide whether the vendor’s process actually justifies relying on their testing. A SOC 2 Type II report tells you about the vendor’s IT controls, not about whether the specific GxP feature you configured behaves correctly in your environment.

No record at all for unscripted testing. Exploratory testing without a record is just clicking around. The whole defensibility of unscripted testing rests on a purposeful, written account of what was tested and what was found.

Skipping negative and boundary cases on critical functions. A frequent finding pattern: the scripted test for a critical limit check verifies that a clearly-passing value passes and a clearly-failing value fails, but never tests the boundary or an invalid entry. The defect almost always lives at the boundary. Critical functions need the on-limit, just-inside, just-outside, blank, and bad-unit cases.

Inconsistent application across the system inventory. Two analysts scoping similar systems land on wildly different testing depth because there is no written risk rule. Inspectors notice inconsistency. A documented, reproducible risk method (even a coarse one) is what keeps scoping defensible across a portfolio.

Configuration drift after go-live. A risk-scoped validation is only as good as the controlled state it leaves behind. If configuration changes after release without change control, the original risk decisions no longer describe the system. CSA does not reduce the need for change control and periodic review; a leaner footprint makes both cheaper, not optional.

For an inspection-oriented checklist of these issues, see the CSV and CSA audit checklist, and for how these gaps surface in regulatory findings, FDA warning letter patterns.

Interview and Inspection Questions

These are the questions that come up in CSV/CSA interviews and in front of an inspector. The answers below are how an experienced practitioner handles them.

“What is CSA and how is it different from CSV?” CSV is the activity of validating a computerized system. CSA is FDA’s risk-based, critical-thinking framework for scaling the assurance effort within that activity, finalized in September 2025 for production and quality system software and revised in February 2026, when the title picked up the word “management” to align with the QMSR. CSA does not remove validation. It says: anchor on intended use, decide direct versus indirect impact, match the testing method to the risk, and keep the record proportionate. The difference shows up as less scripted testing on trivial features and more documented reasoning everywhere.

“Walk me through the four steps.” Identify intended use; determine risk (direct or indirect impact, then severity and probability); determine the assurance activity by matching method to risk; establish a proportionate record. Then I would give a concrete feature and run it through all four in one sentence.

“Give me an example of a direct-impact feature and an indirect one in the same system, and how you would test each.” In a LIMS, the specification limit check that flags an out-of-specification result is direct impact, so rigorous scripted testing with boundary and negative cases and independent review. The column ordering in the results grid is indirect, so a brief exploratory check with a short written summary. Same system, two evidence footprints, each tied to a written risk decision.

“When can you reduce site testing using supplier evidence, and when can you not?” When a documented supplier assessment shows the vendor’s development and testing process meets the bar to rely on their output, and the boundary of what the site still verifies is explicit. You cannot rely on a vendor certificate alone, you cannot use it to skip testing of how you configured the product, and for cloud software you have to draw the shared-responsibility line.

“Does CSA relax Part 11 or data integrity requirements?” No. Audit trail, electronic signature, and access controls stay scripted and documented, and ALCOA+ still governs the records. CSA reallocates effort toward those controls, it does not lower the bar on them.

“How do GAMP categories relate to CSA risk?” They are independent axes. The category describes how much of the software is unique to you. The risk decision describes which of those features actually affect product, patient, or record. A Category 4 system contains both direct and indirect features, so the category alone never sets testing depth.

“How would you defend a lighter testing approach to an inspector?” By showing the reconstructable chain: intended-use statements, the documented direct/indirect decision with reasoning, the written rule that maps risk to method, the rigorous evidence on the critical functions, and the supplier assessment where vendor evidence was used. The defense is the documented reasoning, not the lighter binder.

“What is the biggest risk in adopting CSA?” Under-documenting the reasoning that justifies the lighter touch. Reduced testing without a visible risk basis is more exposed at inspection than the old over-documented approach, because the gap in reasoning is now the finding.

“Does the four-step method still work for an AI or machine learning feature?” The logic transfers, the assumptions do not. Intended use now has to state the data scope the model was trained and evaluated on, not just the function. Risk determination has to account for drift, not only a single point-in-time failure. The assurance method usually needs a challenge-set evaluation plus ongoing performance monitoring rather than a one-time scripted pass, because a model can meet its acceptance criteria at validation and drift out of them later with no configuration change to trigger a re-test. And a feature that removes a human check entirely, an autonomous decision rather than a suggestion a person reviews, needs a materially stronger assurance case than one that only informs a human’s decision.

“How do you classify a feature in a combination product that touches both the drug and the device constituent?” Separately, against each regulatory consequence chain, and let the more stringent classification govern. A function can be indirect for the drug-release decision, because a person reviews the aggregate result before disposition, while being direct for the device history record, because no downstream check exists on that specific unit’s device data. Classifying it once against whichever chain is more convenient under-tests the other.

For broader interview preparation across the discipline, see GxP quality interview preparation and the GxP/CSV/data integrity glossary.

The Validation Deliverable Set

For a Category 4 configured system following GAMP 5 and CSA-informed principles, the core deliverable set is:

• Validation Plan, including scope, approach, and risk rationale
• User Requirements Specification (URS)
• Supplier Assessment
• Configuration Specification
• Requirements Traceability Matrix (RTM)
• IQ protocol and report
• OQ protocol or protocols and report or reports
• PQ or UAT protocol and report
• Validation Summary Report

Under CSA the contents of these documents change more than the list does. The Validation Plan carries the risk rationale that drives scope. The OQ reports show rigorous scripted testing for direct-impact features and lighter records for indirect ones. The Validation Summary Report ties the whole package back to the risk decisions so that an inspector can read the logic, not just the results.

The validation deliverables guide covers what each document is actually for and what makes each one defensible at inspection. For the electronic records and signatures controls that sit underneath all of this, see the Part 11 and Annex 11 practical guide. And if your scope includes software that learns or adapts, the assurance questions change again, which is the subject of validating AI in GxP systems and the GxP machine learning model lifecycle.