DEV Community: Shivanshu Tripathi

Computer Software Assurance (CSA) for Developers: What FDA's Risk-Based Testing Means for Your CI Pipeline

Shivanshu Tripathi — Wed, 28 Oct 2026 13:00:00 +0000

Picture the validation binder for a label-printing script: four hundred pages, each one a screenshot of a test step with a signature underneath. The script prints lot numbers. The team spends more time photographing tests than writing code, and an auditor still finds the gap nobody tested: what happens when the printer runs out of labels mid-batch.

FDA's Computer Software Assurance guidance was written to end that binder. Computer software assurance (CSA) is FDA's risk-based approach to confirming that software used in device production and quality systems does what it should. FDA finalized the guidance in September 2025. It asks you to spend testing effort where a failure could hurt a patient or product quality, and to accept lighter evidence everywhere else, including the output of your automated tests.

What does FDA's computer software assurance guidance cover?

The guidance, Computer Software Assurance for Production and Quality System Software, applies to software that a medical device manufacturer uses in production or in its quality system: MES, LIMS, complaint handling, CAPA tools, label printing, test equipment scripts. It does not apply to software that is itself a device or runs inside one. It supersedes section 6 of FDA's 2002 General Principles of Software Validation.

Under QMSR, which took effect February 2, 2026, ISO 13485 requires validation of software used in the quality system (clause 4.1.6) and in production (7.5.6). CSA is how FDA expects you to scale that work to risk.

CSA vs CSV: what changes for a development team?

	Traditional CSV	Computer software assurance
Starting question	"Did we document every test?"	"What happens to patients or quality if this fails?"
Effort	Same depth for every function	Deep on high-risk, light on low-risk
Test style	Scripted, step by step	Scripted for high risk; unscripted and exploratory for the rest
Evidence	Screenshots and signatures per step	Summary records, test logs, CI output
Vendor and tool assurance	Re-test everything	Rely on supplier evidence where justified

Our CSA vs CSV comparison goes deeper on the quality side. For a developer, the practical shift is this: a green CI run with a stored log counts as evidence, if you can tie it to a requirement and a risk level.

How do you classify risk under computer software assurance?

The guidance draws one line. A software feature carries high process risk when its failure could compromise safety, such as a wrong value released on a label or a missed sterilization parameter. Everything else is not high process risk.

Use three questions per feature:

If this function fails silently, can a nonconforming product reach a patient?
Does a person or another system catch the failure before release?
Does the function create or change a regulated record?

A yes to the first and a no to the second puts the feature in the high-risk tier.

What evidence does FDA accept under CSA?

For high-risk functions, keep scripted tests with expected results and a pass or fail record. For everything else, the guidance accepts unscripted testing such as exploratory or ad hoc tests, with a short record of what you tested, when, who, and the outcome.

That maps onto a CI pipeline:

# .ci/assurance.yml
assurance:
  high_risk:            # scripted, traced to requirement IDs
    - test: tests/label/test_lot_number_matches_batch.py
      requirement: REQ-LBL-004
      risk: high
  standard:             # unscripted / automated, summary record
    - suite: tests/ui
      risk: not-high
  record:
    store: s3://qa-evidence/{release}/
    keep: [junit.xml, coverage.xml, commit_sha, reviewer]

Store the log, the commit, the requirement IDs and the name of the person who reviewed the result. That set is your validation record.

Does skipping software assurance show up on Form 483s?

Yes, and under QMSR it carries ISO clause numbers. Form 483s issued since February 2026 in the Atlas Form 483 directory cite production and service provision (ISO 13485 7.5), which includes validation of processes (7.5.6). Three examples:

Klarity Medical Products, Heath, Ohio, May 2026: 8 observations, including procedures for validation of processes not documented.
Marlen Manufacturing & Development, Bedford, Ohio, May 2026: 4 observations, including the same process validation finding (7.5.6).
Light Age, Somerset, New Jersey, May 2026: 18 observations, starting with QMS documentation under clause 4.

On the drug side, the equivalent finding cites 21 CFR 211.68. Our post on 21 CFR Part 11 audit trail requirements covers that, and the audit trail tests used in computerized system validation list what a reviewer will try.

A CSA checklist for your next release

Write the intended use of each feature in one sentence.
Tag each requirement with a risk tier.
Script and trace tests for high-risk features only.
Keep CI logs, commit SHA and reviewer as the record for everything else.
Use supplier evidence for platforms and libraries, and document why you trust it.
Re-assess risk when intended use changes, not on every commit.

FAQ

What is computer software assurance?
Computer software assurance is FDA's risk-based approach to establishing confidence that software used in medical device production or quality systems works for its intended use. It focuses testing on features whose failure could affect patient safety or product quality and accepts lighter, unscripted evidence elsewhere.

When did FDA finalize the CSA guidance?
FDA finalized "Computer Software Assurance for Production and Quality System Software" in September 2025, after a 2022 draft. It supersedes section 6 of the 2002 General Principles of Software Validation for this type of software.

What is the difference between CSA and CSV?
Computer system validation applies the same scripted, documented testing to every function. Computer software assurance scales effort to risk: scripted tests for high process risk, unscripted or automated testing with summary records for the rest.

Does CSA apply to software that is a medical device?
No. The guidance covers software used in production and the quality system, such as MES, LIMS or CAPA tools. Software in a medical device or software as a medical device follows separate premarket guidance.

Can CI test logs count as validation evidence?
Under CSA, yes for features that are not high process risk, as long as the record shows what you tested, the result, the date and who reviewed it. High-risk features still need scripted tests traced to requirements.

I work on Atlas Compliance, which tracks FDA inspections and Form 483 observations for pharma and medical device quality teams. The FDA inspection directory is free to browse.

21 CFR Part 11 Audit Trail Requirements: A Developer's Guide Built on FDA 483 Data

Shivanshu Tripathi — Wed, 21 Oct 2026 07:12:50 +0000

Picture a QC lab at 23:58. An analyst signed in as shared01 deletes a failing assay result and reruns the sample. The rerun passes, and the batch ships. Eight months later an FDA investigator opens the lab system, filters the audit trail for deletions, and asks one question: who is shared01? Nobody can answer, and the question goes onto a Form 483.

21 CFR Part 11 audit trail requirements exist to make that question answerable. They come from one clause, 11.10(e). Your system must write a secure, computer-generated, time-stamped record each time someone creates, changes or deletes a regulated electronic record. The trail must keep the old value visible and must last as long as the record.

If you build software that pharma, biotech or medical device companies use to make, test or release product, your customers will ask you about Part 11 compliance before they sign. This guide covers what the rule asks for, how often software gaps land on FDA Form 483s, and what your team should build.

What do 21 CFR Part 11 audit trail requirements say?

Part 11 applies when a regulated company keeps a required record in electronic form or signs it with an electronic signature. Batch records, lab results, deviation reports, complaint files and training records all count. If a regulation requires the record and your system stores it, your system sits in scope.

Section 11.10 lists the controls. Read it as a feature spec:

Clause	What FDA requires	What you build
11.10(a)	Validation for accuracy, reliability, consistent performance	Requirements, risk assessment and test evidence for each release
11.10(b)	Accurate, complete copies in human-readable and electronic form	Exports that carry metadata and the audit trail
11.10(c)	Record protection for the retention period	Backups, restore tests, retention rules
11.10(d)	Access limited to authorized people	Named accounts, roles, session timeouts
11.10(e)	Secure, time-stamped audit trail; old values not obscured	Append-only change log with who, what, when, old and new value
11.10(f)	Operational checks on the order of steps	Workflow states that block steps out of sequence
11.10(g)	Authority checks	Permission checks on sign, edit and approve

Electronic signatures carry their own Part 11 electronic signature requirements. Section 11.50 asks for the signer's printed name, the date and time, and the meaning of the signature, such as review or approval. Section 11.70 binds the signature to its record so nobody can copy it onto another one. Section 11.200 requires two distinct components, such as a user ID and a password, for any signature that is not biometric.

How often do software gaps show up on FDA Form 483s?

One in four drug 483s, in our data. We looked at 212 Form 483s issued to drug, biologic and animal-drug facilities in 2025 and 2026 in the Atlas Form 483 directory.

17.5% cite 21 CFR 211.68, the CGMP rule on computerized systems. Most of these cite 211.68(b), which covers controls that let only authorized people change records and that check the accuracy of inputs and outputs.
9.9% cite 21 CFR 211.194, complete laboratory records.
1 in 4 cite one or both.

The 483s that cite these sections run longer. They average 7.0 observations, against 4.3 across all 212. A facility with weak system controls tends to have weak controls elsewhere, and investigators find both.

Few drug 483s cite Part 11 by section number. Investigators cite the predicate rule, most often 211.68 or 211.194, and describe the software behaviour underneath. To an engineer, the cause looks the same: the system let a record change without a trace you could trust.

Which real 483s cited computer system controls?

Five recent examples from the directory, each with the observation list public:

American Regent, Shirley, New York, April 2026: 10 observations. 211.68(b) sits beside investigations (211.192), environmental monitoring and cleaning.
Baxter Healthcare, Round Lake, Illinois, November 2025: 5 observations, including 211.68(b) and 211.194(a)(1) on sample identification in lab records.
Emergent BioSolutions, Winnipeg, May 2026: 9 observations. Both 211.68(a), on calibration and checking, and 211.68(b) appear.
Chartwell Pharmaceuticals, Congers, New York, November 2025: 15 observations, with 211.68(b), batch record completeness (211.188) and annual record review (211.180(e)).
Eugia Pharma Specialities, Sangareddy, India, February 2026: 11 observations, including 211.194(a)(8), the second-person sign-off on lab records. That is the paper version of an electronic signature control.

A short 483 can carry the same finding. Bestco, Mooresville, North Carolina, August 2025 received 2 observations, and 211.68(b) is one of them.

What should an audit trail record contain?

Write one immutable row for each create, update or delete on a regulated record. Store these fields:

{
  "record_id": "batch-B1042/assay",
  "record_version": 7,
  "action": "update",
  "field": "assay_result",
  "old_value": "98.6",
  "new_value": "99.1",
  "reason": "transcription error, see deviation DV-311",
  "user_id": "m.chen",
  "timestamp_utc": "2026-10-21T11:02:47Z",
  "client": "lims-web/4.2.0"
}

Four rules keep that trail defensible:

Server time only. Stamp entries with time from a controlled source. If a user can change the clock on the machine that stamps the record, the timestamp proves nothing.
Append-only storage. Your application should have no update or delete path into the audit table. Restrict even admins to read access.
Reviewable views. An audit trail nobody reads fails the control. Give QA a filtered view: changes after approval, deletions, edits outside working hours, edits by admin accounts. The audit trail tests used in computerized system validation list what a reviewer will try.
Same retention as the record. If the batch record lives ten years, its trail lives ten years.

How do you meet Part 11 electronic signature requirements?

Show the signer's name, the date and time, and the meaning (reviewed, approved, authored) on the signed record and on every printout or PDF export. Ask the user to re-authenticate at the moment of signing. Bind each signature to a hash or version number of the record, so any later edit breaks the signature in a visible way.

Second-person review is where most signature gaps start. Eugia's 211.194(a)(8) observation above concerns a second signature on lab records. If your workflow lets one person act as both analyst and reviewer, expect that finding.

Part 11 compliance checklist for engineering teams

One person, one login. No shared or generic accounts on instruments or workstations.
Separate roles. People who create data cannot delete or approve it. System admins cannot edit GxP data.
Append-only audit trail with old and new values and a reason field.
Audit trail review built into the release workflow, with an approval of its own.
Signatures with name, time and meaning, bound to the record version.
Server-controlled time across every component.
Exports that include metadata and the trail.
Validation evidence per release. FDA's move to computer software assurance favors risk-based testing over screenshot evidence, which suits teams with automated tests. The CSA vs CSV comparison covers the change.

Do AI features change Part 11 compliance?

The same rules cover anything a model writes into a regulated record. Treat a model's output as an unsigned draft. The human who reviews and signs it performs the regulated act, and your audit trail must show what that person changed before signing. The longer argument sits in can LLM-based quality systems pass a Part 11 audit.

FAQ

What are the 21 CFR Part 11 audit trail requirements?
Section 11.10(e) requires secure, computer-generated, time-stamped audit trails that record the date and time of operator entries and actions that create, modify or delete electronic records. Changes must not obscure earlier values, and you must keep the trail for at least as long as the record and make it available to FDA.

Does Part 11 apply to every system in a pharma company?
Part 11 applies to electronic records that a predicate rule requires, such as the CGMP rules in 21 CFR 211 or the device rules in 21 CFR 820, and to electronic signatures on those records. An HR tool holding no GxP records sits outside it.

What does FDA cite when software controls fail?
On drug inspections, investigators cite the predicate rule more often than Part 11. 21 CFR 211.68(b) covers computer system access and data checks. 211.194 covers complete laboratory records. In 212 drug and biologic 483s from 2025 and 2026, one in four cited one or both.

Is a Part 11 certificate from a software vendor enough?
No. FDA holds the regulated company responsible for its records. A vendor can provide features and validation support, but the customer must validate the system for its intended use and run its own audit trail reviews.

What are Part 11 electronic signature requirements?
The signed record must show the printed name of the signer, the date and time, and the meaning of the signature (11.50). The signature must link to the record so nobody can copy it (11.70). Non-biometric signatures need two distinct components such as an ID and a password (11.200).

I work on Atlas Compliance, which tracks FDA inspections and Form 483 observations for pharma and medical device quality teams. You can search any facility's Form 483 history or read what an FDA Form 483 is.