Computer software assurance, explained.

Computer software assurance means testing each software function as hard as its failure could hurt

Five steps that take a software function from intended use to staying validated

1. Say what it is forThe system owner writes the intended use: this LIMS module manages stability studies and is used directly in the quality system.
2. Judge each function's riskGroup requirements into functions and ask what a failure of each could do. This step decides everything after it, and it is the step this guide is about.
3. Choose the proofRobust scripted testing, limited scripted testing, an unscripted test, the supplier's evidence or a written reason, sized to that risk.
4. Test and keep the recordRun the tests. Keep the intended use, the risk result, what was tested, what was found, who did it and when.
5. Stay validatedEvery change, patch and supplier release goes back through the same question, for as long as the software is in use.

Steps 2 and 3 are the subject of this guide. The people, company and figures in the example are fictional.

Four things newcomers get wrong about FDA's CSA guidance, starting with who it covers

Learn these first: intended use, high process risk, unscripted test and validated state

Fourteen terms are defined in the one-page summary.

Exactly what FDA's computer software assurance guidance covers, and where it stops

In shortFinal guidance, issued February 3, 2026, titled "Computer Software Assurance for Production and Quality Management System Software". It covers computers and automated data processing systems used as part of medical device production or the quality management system. It is written by FDA's device and biologics centers, in consultation with its drug center. It is nonbinding. It does not cover software that is itself a device, and it does not reach drug manufacturing or clinical systems by its own terms.

The words that decide whether FDA's CSA guidance is about your system

As of November 3, 2026, we found no counterpart to this guidance issued by CDER, FDA's drug center. Its July 2026 guidance agenda does list a planned document, "Computer Software Assurance for AI-Based Systems in Drug Manufacturing and Clinical Investigations; Supplemental Guidance". The title is all that can be read: no text is published, and CDER says it is not bound to issue what the agenda lists.12

Combination products sit in between. A single-entity or co-packaged product can show compliance with each set of good manufacturing practice rules for its parts, or follow the streamlined route in 21 CFR 4.4, which starts from either drug or device rules and adds specified provisions of the other.13 The Office of Combination Products was consulted on the guidance, and the guidance does not say how it applies to them.1 Ask your regulatory group which operating system you declared. Then say whether CSA applies directly or by analogy to the system in question.

If you make drugs or run trials: the texts that already ask for validation in proportion to risk

In shortDrug and clinical teams do not need FDA's device guidance to size validation by risk. FDA's own drug data integrity guidance says validation should be in proportion to the risk. EU GMP Annex 11 says decisions on the extent of validation should rest on a documented risk assessment. ICH Q9(R1), the international guideline on quality risk management, sets the same logic, and ICH E6(R3), the international trial guideline, and FDA's 2024 questions and answers set it for trials. Use those as your authority, and treat CSA as a useful analogy.

A qualified MES platform can still make a wrong batch record: FDA's point about workflows

The most useful sentence for a drug plant is one FDA wrote eight years ago. Qualifying a manufacturing execution system (MES) platform, the software that runs production, "ensures that it meets its relevant requirements and specifications; however, it does not demonstrate that a given MPCR generated by the MES contains the correct calculations."9 An MPCR is a master production and control record, the approved instructions for making a batch. Replace MES with LIMS and master record with stability protocol, and you have the reason why configuration stays yours to test, whatever your supplier proved.

The same answer says that controls for a system validated for intended use "address software, hardware, personnel, and documentation".9 That is why a clean test result alone does not close a validation.

How FDA separates high process risk from the rest, and why a human check moves the line

In shortFDA asks one question of each feature, function or operation: if it failed, could that cause a quality problem that foreseeably compromises safety? Yes makes it high process risk, and the testing is then scaled to the harm a device could do. No makes it not high process risk, and the testing is scaled to the process. A later check by a qualified person can move a function from one side to the other, and FDA's example shows how.

What FDA lists as generally high process risk, and what it lists as generally not

FDA's best teaching case is a pair of similar features. An enterprise resource planning system automates restocking of materials. In the first example a qualified person checks materials before use, so wrong materials should be rejected, and the manufacturer calls it intermediate, which FDA treats as not high. In the second, a similar feature in another such system also automates the check, no qualified person looks first, and the manufacturer calls it high process risk.1 The job is much the same in both, and the process around it sets the risk.

Three places a common risk grid drifts from FDA's wording

Scripted, limited, scenario, error guessing, exploratory: what each test is and what it must leave behind

In shortFDA's Table 1 gives five worked examples. Every one, including an exploratory session with no step-by-step plan, ends in a record with the intended use, the risk result, what was tested, the issues found, a conclusion and who did it when. Unscripted testing is lighter on planning. It carries the same duty to record the result.

FDA's table names two grades of scripted testing, and this guide uses its words: robust and limited. FDA says "a more robust scripted testing" is one where the test cases and evidence "may include detailed requirements for repeatability, traceability, or auditability".1 "Robust" here names that grade and says nothing about quality, and you will see the same word on screens in Part B.

For high process risk FDA says you "may choose to consider" scripted testing or a mix of scripted and unscripted; for the rest, unscripted methods may be suitable. It also says those pairings are not exclusive. Unscripted testing may suit a high-risk function better, and a manufacturer may find an automated script more effective and efficient for a function that is not high risk.1

We found no study in regulated software on whether unscripted testing finds as many defects as scripted. One academic experiment, with 51 students testing a text editor, found no difference in defect detection between exploratory and test-case-based testing, less design effort for exploratory testing, and more false defect reports from test cases. It also found a weakness in each: choosing the right level of detail for test cases, and designing and logging exploratory sessions. Its authors add that test cases have other benefits for managing testing in large organizations.23

We read the abstract only, and students on a text editor tell you little about a LIMS. So measure your own: count the defects each method finds on your next validations (section 21).

From 118 hours to 56 on one LIMS module: the arithmetic of a nine-cell risk grid

In shortThis worked example is fictional and the hours are the company's own planning estimates. Scripting all 42 requirements at about 2.8 hours each comes to about 118 hours. Grouping them into 15 functions and letting a nine-cell grid set the method comes to 55.5 hours. One procedural decision adds half an hour, for 56 hours. The grid is this company's chosen method, built on impact and likelihood, and FDA's text does not prescribe it.

How the example adds up, and the half hour one SOP clause adds

Add the cells of the first pass, left to right and top to bottom. High impact: 2 functions × 1.5 hours is 3; 2 × 3 is 6; 6 × 6 is 36. Medium impact: 1 × 2.5 is 2.5; 2 × 2.5 is 5. Low impact: 1 × 0.5 is 0.5; 1 × 2.5 is 2.5. So 3 + 6 + 36 + 2.5 + 5 + 0.5 + 2.5 = 55.5 hours. The two charts above show the plan after the decision that follows, so their limited scripts include one more function.

Then the procedure speaks. User access and roles sits in a 2.5-hour unscripted cell, because roles come from a directory and are reviewed each quarter, so a wrong role would be caught by a procedural control. The company's SOP section 6.2 says any function that controls who may approve GMP results gets a scripted test, whatever the risk result. A three-step limited script at 3 hours replaces the charter, the short brief an unscripted test would have run from. That adds 0.5 hours, for 56.

A good grid raises this kind of disagreement in the open. Reading the same function through FDA's list would give another answer again, because FDA names user authentication among the infrastructure generally outside the validation duty.1 For a drug plant that reasoning does not apply, and draft Annex 11 names "access privileges" among the things to test with increased focus.3 This is why the method belongs in your SOP, and the source of each rule in your SOP should be named.

What a supplier's test package and SOC 2 report can carry, and what stays yours to test

In shortFDA, Annex 11 and GAMP 5 all let you build on what a supplier has done, after you assess the supplier by risk. A SOC 2 Type II report tells you about the supplier's controls over its service. A supplier's test package tells you about the product as supplied. Neither says anything about your configuration or your intended use. The responsibility stays with you.

FDA says a device maker "could incorporate the software development practices, validation work, and electronic information already performed by developers of the software as the starting point", and that for some lower-risk functions "this may be all the assurance that is needed".1

FDA lists what a vendor assessment may consider: onsite audits where feasible, Service Organization Controls reports and ISO certifications, development and security practices, and the vendor's data integrity controls.1 Annex 11 says the need for an audit "should be based on a risk assessment" and that documentation supplied with commercial products should be reviewed "to check that user requirements are fulfilled".10

The draft Annex 11 puts the limit bluntly: relying on a vendor "does not change the requirements", the regulated user "remains fully responsible", and it should "carefully consider whether it covers the implemented version" and supports company processes "as is".3

SOC 2 explained for a validation team, in four plain statements

Backup is outside FDA's validation duty in one reading and on Annex 11's test list in another

FDA generally treats software for "continuity of operations (e.g., backup and restore)" as infrastructure, outside the validation duty, unless it stores quality records, in which case effort goes to the integrity of those records and Part 11.1 Annex 11 says the "ability to restore the data should be checked during validation and monitored periodically".10 The drug rule also asks that backup data be "exact and complete" and secure.8 A device maker and a drug maker reading the same supplier report may reach different plans, and both can be right. Write down which rule you are answering.

Screenshots, system logs and trace matrices: the validation record FDA and draft Annex 11 expect

In shortFDA recommends digital records such as system logs and audit trails "as opposed to paper documentation, screenshots, or duplicating results". The draft Annex 11 asks for executed test scripts and, where relevant, screen dumps, with every test traced to a requirement. A global company needs one SOP that satisfies both, which usually means a fuller record for GMP systems in the EU. Part 11's enforcement discretion does not cover device quality system validation.

The same evidence question, read against FDA's guidance and the draft EU text

Annex 11 itself, the January 2011 revision on the Commission's list, says "evidence of appropriate test methods and test scenarios should be demonstrated", and user requirements "should be traceable throughout the life-cycle".10,16

Where Part 11 enters a validation record, and what FDA's 2003 discretion leaves out

Part 11 sets the conditions under which FDA treats electronic records and signatures as equivalent to paper.1 Section 11.10(a) asks for validation of systems "to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records".14 Section 11.50 asks a signed electronic record to show the signer's printed name, the date and time, and the meaning of the signature.28

FDA said in 2003 that it would use enforcement discretion, meaning it would choose not to enforce, on some of those validation points, and recommended a risk-based approach.15 The CSA guidance adds a limit: that discretion "expressly does not apply" to validation of production or quality system software under ISO 13485.1

Both Part 11 and data integrity expectations apply to the validation record itself, once it exists in electronic form. FDA's example: documents showing that a system correctly automates checking materials are evidence for a validated state, so Part 11 generally applies to them. A routine activity log that is not needed as such evidence falls outside Part 11.1

MHRA's data integrity guidance adds the ALCOA test that records be attributable, legible, contemporaneous, original and accurate.29 A screenshot is one way to meet that. An audit trail with the same facts can be another, if your procedure and your inspector's reading allow it.

What FDA inspectors cite on computer systems: 110 drug citations in fiscal 2025, most of them about access

In shortBy our sum of FDA's rows, 21 CFR 211.68(b) drew 110 citations on drug Form 483s, the lists of observations an FDA inspection produces, in fiscal 2025, the sixth most cited paragraph. Most of those concern who can change records, more than validation as such. Device software validation under the old 820.70(i) drew 20. Warning letters show the same pattern: shared logins, deleted data and missing audit trails on the drug side, and unvalidated inspection or quality software on the device side.

Two drug letters, two device letters and a Form 483: what each says about computer systems

These records are cited for what they say, and none of them rests on computer software assurance. The two device letters predate the first final guidance, and the Form 483 predates the new quality rule.

These five records point at missing basics: what that means for risk-based testing

Read together, the records make an awkward point for anyone selling less testing. Each of those firms fell short on something more basic than the amount of testing a risk grid sets: no validation at all, no audit trail, no unique logins, or no record. The first gain from CSA is that a team has time to look at the oldest instrument PC in the laboratory, a system nobody put on the list.

Patient impact sits behind each of these. When a stability pull is missed, the data behind a shelf life is lost. When results can be changed without a trace, a release decision rests on something nobody can check.

How CSA programs go wrong: testing less with no reason, trusting the platform and losing the validated state

In shortThe expensive mistakes come from misreading the method more than from weak testing: citing the guidance outside its scope, removing scripts with no written risk call, treating a supplier's report as validation, running unscripted sessions with no record, and validating once and forgetting. Software releases are where a validated state can slip away.

How a quarterly cloud (SaaS) release stays validated, one change at a time

Cloud systems change on the supplier's calendar, often several times a year. Each release is a small validation question: what changed, which of our functions does it touch, and what proof does that need? FDA says to apply the same risk analysis to changes. For devices with approved applications, a software change that could foreseeably compromise safety goes in a 30-day notice, and others may go in an annual report.1

Annex 11 says changes to systems, including configurations, should be made "in a controlled manner" and that systems "should be periodically evaluated to confirm that they remain in a valid state".10 The draft adds that contracts should agree "the process for release of new system versions".3

Using AI to write validations: draft Annex 22, FDA's January 2025 draft and who checks the tool

In shortSoftware can read specifications, group requirements, propose a risk call and draft scripts. FDA's CSA guidance names AI tools among what it covers, when used in device production or quality systems. Draft EU Annex 22 says large language models "should not be used in critical GMP applications", and it remains a draft under active debate. In every reading, a qualified person answers for the output, and you assess the tool for what you use it for.

What software does well in validation work, and what stays with qualified people

How far CSA has spread: one vendor's surveys, rising workloads and the figures nobody publishes

In shortThe only recurring numbers we found come from annual surveys by one validation software vendor, so read them as directional. In 2024, 64% of respondents said they were using or adopting CSA and 15% said it was fully integrated. In 2025, 66% reported a higher workload. In 2026, 39% were using or evaluating AI for validation. We found no public figure for hours per system, cost per validation or defects found by method in regulated software.

The direction is clearer than the amounts. The same survey reported 57% using or adopting CSA in 2023, against 64% in 2024.47,44 The 2025 survey, with over 300 respondents, says 58% now use a digital validation system, up from 30% the year before, and places audit readiness as the top challenge for the first time.46

The 2026 sponsored article reports 614 respondents and "rising workloads against constrained resources", and 78% confident AI will be standard practice by 2030.45 Device and drug respondents are counted together in those pages, so none of these figures tells you how widely drug makers use the device guidance.

How a validation runs today: five roles, five hand-offs and where the first-draft days go

In shortA validation passes among four or five people, and we found no public figure for how its calendar divides. Teams run it on document templates, on a digital validation system, or with a consultancy. Whichever they use, the risk call may be made in a meeting and written in a form that later readers find hard to follow.

The validation lead, the engineer, the system owner, the approver and the supplier, and what each wants

Documents, a digital validation system, a consultancy or drafting software: how teams run CSA

Validation programs are often run site by site: 48% of respondents to the vendor's 2024 survey said they structure them by individual site.44 GAMP 5's categories are the usual shared shorthand for how much of a system is configured or custom: commonly 1 for infrastructure, 3 for non-configured, 4 for configured and 5 for custom software.48

VP-2614, October 7: fifteen functions placed, one SOP conflict decided and a plan signed by 9:29 am

In shortOmar Haddad, the validation lead, opens the validation with its six sources. Six agents read them, group 42 requirements into 15 functions and place each on the company's risk grid, with a reason and a citation. He decides the one conflict with the SOP, reads the plan and trace matrix, and signs as author. The system owner and IT Quality sign next, and testing has not yet begun.

1

Six sources in, and a grid that already says how each cell is proven

Validation VP-2614 opens with the requirements (URS v1.3, 38 pages), the configuration specification (v0.9, 61 pages), the intended use (v1.0, signed by Dr. Maya Chen, the system owner), the supplier's validation package 10.0 (312 pages, a 16-page summary read), the SOC 2 Type II report and the company's QA-SOP-0412 v7.

The grid is empty, and the method and hours per cell were set by IT Quality: 6 hours for a robust script where impact and likelihood are both high, 1.5 for supplier evidence, 0.5 for a written reason. "Robust" is FDA's word for the fuller grade of scripted testing, and the screen uses it.

2

"Place functions": six agents read 214 pages

The Requirements Reader finds 42 requirements with page anchors. The Intended-Use and GxP Assessor records direct use in the quality system and GAMP category 4, software as a service. The Function Risk Classifier places 15 functions. The Vendor Evidence Matcher finds that the supplier package and the SOC 2 report, for a period ended June 30, 2026, cover 2 functions and 5 requirements.

Each function lands in its cell as you watch, and nothing is final until a person signs.

3

Six functions in the high-risk corner, and one decision raised

Stability protocol set-up, pull-point calculation, result entry, out-of-specification flagging, the audit trail on result changes and the chromatography import land where both axes are high: 36 hours of robust scripts. Backup and hosting rest on supplier evidence. The lab news board needs a written reason. The strip reads 55.5 hours against about 118 if every requirement were scripted.

4

"Our SOP is stricter than the grid here"

User access and roles sits in an unscripted cell at 73% agent confidence. SOP section 6.2 asks for a scripted test of any function controlling who approves GMP results. The agent lays out two options with their citations and chooses neither. Omar can follow the SOP with a three-step limited script, for half an hour more. Or he can keep it unscripted and send a deviation request to IT Quality.

He follows the SOP. The total becomes 56 hours, and the decision is recorded under his name.

5

A plan drafted from the grid, and a trace with one closed gap

The plan's eight sections each cite what they rest on, and any section can be redrafted. Records will be digital evidence, with screenshots only where a step needs one, which is close to FDA's device wording and lighter than the draft Annex 11 text. A real Leiden lead would check that against the company's own reading of Annex 11.

The trace matrix reads 42 of 42. The first draft left URS-031, keeping records and audit trails for 10 years, with no test. The checker proposed the supplier's retention control plus an evidence review, in which the reviewer confirms that 10 years is what is set.

6

Omar signs as author, with the meaning stated

The signature covers the plan and test strategy, the risk assessment of 15 functions, the trace of 42 requirements, 9 scripts and 3 charters. He confirms the meaning: "I am the author of this validation plan, risk assessment and trace matrix." 21 CFR 11.50 asks a signed record to show name, date and time, and meaning.28

VP-2614 moves to QA approval at 9:29 am. Dr. Chen reviews next, then Dana Okafor approves it for testing.

Why a function sits where it does, the plan, scripts, charters, trace, dashboard and the rules you set

In shortBehind the grid sit the reason for each placement, the plan and its risk table, robust and limited scripts, time-boxed charters, supplier evidence reviews, the trace matrix, the audit trail and signatures, every validation in flight, a library of sources, a dashboard and the settings that hold your own rules. Each number opens its source.

The six validation agents, the three signatures and the documents a validation runs on

In shortSix agents each do one narrow job, and each has something it must never do. People decide every placement and sign every record, with maker and checker kept apart. Sources are read in place. Outcome figures here are labeled estimates and design targets, to be measured on your own files.

Requirements Reader to Trace Checker: each validation agent's job and its limit

Omar, Maya, Dana and Priya: who signs and who tests on this LIMS validation

From URS and supplier package to a signed plan, scripts and trace matrix

The 3.2-hour draft and the 53% test cut: sample figures to test on your own files

Targets are design goals, to be measured in the live solution. A pilot on your own files should test them, and section 21 shows how.

Roles, audit trail, credentials, and what you still validate yourself

Script-everything testing costs you hours; a thin validation record costs you in an inspection

In shortTwo costs sit on opposite sides. Testing everything evenly costs hours you can count, and it delays go-lives. A missing or unreadable record may be rarer, and it costs more when it shows up in an inspection. Nobody publishes the cost of a validation, so the numbers that matter most are the ones you can find in a week.

A one-week baseline for your own validations: hours by method, supplier overlap and slipped go-lives

Lost stability data, an unreadable rationale, a forgotten PC: validation costs left out of the sums

Two separate savings: risk-sized testing needs no new software, and automated drafting does

In shortPut in your own numbers. Two savings sit apart on purpose. Sizing tests to risk is a decision about method, available to you with or without new software. Faster reading, writing and tracing is what software can add. The calculator counts time alone, and takes away what the software would cost you.

Method, drafting, supplier reuse, releases: where CSA and automation can each pay

A calculator for test, writing and supplier release hours across your validation load

Score your validation program on eight points, from the rule that binds each system to the AI tool you would assess

In shortAnswer honestly, 0 to 2 on each. Your score suggests whether to fix the method first, pilot on one system, or plan a rollout. Nothing you choose leaves this page.

A low score means writing your risk method before buying anything

Vendor questions for CSA software: scope, the risk call, supplier evidence, compliance claims and proof

In shortAsk every vendor the same questions, us included. The answers show whether the tool knows where FDA's guidance stops, whether a person makes the risk call, what it does with supplier evidence, and how you would measure it on your own validations.

A ten-week CSA pilot on one closed validation and one live one, ending in five numbers

In shortStart with your method, then a validation you already closed, where you know the answers. Have your own people make the risk calls blind and compare. Then run one live validation with defects counted by method. Decide on the numbers below. If the pilot succeeds, extend system by system.

1. Weeks 0 to 2. Write your method and name the binding rule for each kind of system. Time your baseline on three past validations.
2. Weeks 2 to 4. Assess the tool as a supplier and write its intended use. Load your SOP, templates and one closed validation.
3. Weeks 4 to 6. Two of your senior people place the functions blind. Compare both with the tool, and with what was done at the time.
4. Weeks 6 to 9. Run one live validation of medium risk, with people deciding and signing. Count defects by method and by function.
5. Weeks 9 to 10. Show the record to QA and an auditor who was not involved. Decide on the numbers below, and write down why.

Risk call agreement, defects by method and citations: how to score a CSA pilot

CSA questions: FDA's final guidance, CSA vs CSV, pharma scope, unscripted testing and Part 11

In shortShort answers to what validation teams search for, each one complete on its own. Rules and statuses are as of November 2026.