Computer software assurance that puts scripted testing only where the risk is
Testing sized to each function's risk, every line linked to its source.
See one case, screen by screen ↓Computer software assurance (CSA) is the risk-based approach FDA describes in its Computer Software Assurance for Production and Quality System Software guidance, final in September 2025: scripted testing, robust or limited, where a function's failure could compromise safety, unscripted testing for the rest, and the supplier's own testing leveraged where it applies. The Computer Software Assurance solution applies it per function, on a grid your IT Quality team approves.
How to choose AI solutions for life sciences →
Updated
Every computerised system used for GxP work — a LIMS, an eQMS, a batch release console, a validated spreadsheet — has to be proven fit for its intended use before go-live and after every change. In practice validation teams still script and screenshot every requirement. By the solution's own estimate, scripting all 42 requirements of one new LIMS module comes to about 118 hours of testing, and most of it proves again what the supplier already tested: the audit-trail engine, the e-signature engine, backup and hosting.
FDA's Computer Software Assurance guidance (final, September 2025) and GAMP 5, 2nd edition, ask for effort sized to the risk of each function: scripted testing where a failure could compromise safety, unscripted testing for the rest, and the supplier's own testing and audits leveraged where they apply. But the risk call per function is made by hand, differs between engineers and is rarely written down in a form an inspector can follow — so the shelf-life calculation and the lab news board get the same depth.
Our estimated split for one new module of a configured GxP system, by hand and with the solution. The dashboard puts a first draft by hand at about 5 working days.
Six agents read the requirements and supplier evidence, place every function on a risk grid and draft the scripts and trace matrix; the validation lead decides every placement.
Northwind Bio is adding the stability module of Kelvora LIMS 10 at Plant 3 — Leiden, where its results support shelf-life assignment for Veltrimab 150 mg/mL solution for injection. Go-live is Nov 16, 40 days out. Here is what happens next, screen by screen, in the working solution.
Validation VP-2614 opens with its sources attached: URS v1.3 (38 pages), configuration spec v0.9 (61 pages), the intended use v1.0 signed by Dr. Maya Chen, Kelvora's validation package 10.0 (312 pages), the SOC 2 Type II report and Northwind Bio's QA-SOP-0412 v7. The grid already says how each cell is proven: robust scripts at 6 h where impact and likelihood are both high, supplier evidence at 1.5 h, a recorded rationale at 0.5 h.
“6 sources in · 42 requirements · 15 functions to place. The agents group the requirements into functions and place each one by impact and likelihood. You decide every placement.”
The Requirements Reader splits the sources into 42 requirements with page anchors. The Intended-Use & GxP Assessor records direct use in the quality system, GAMP category 4, SaaS. The Function Risk Classifier places 15 functions, and the Vendor Evidence Matcher finds that the supplier package and the SOC 2 report (period ended Jun 30, 2026) cover 2 functions and 5 requirements. The functions land on the grid cell by cell.
“Each function lands in the cell its impact and likelihood point to. The cell sets the method and the hours; nothing is final until you sign.”
Stability protocol set-up, pull-point schedule calculation, result entry against specification, OOS and OOT flagging, the audit trail on result changes and the CDS result import land where both impact and likelihood are high: 36 h of robust scripts. Backup, restore and retention, and hosting and installation, rest on supplier evidence. The lab news board needs only a rationale. In all, 55.5 h against 118 h if every requirement were scripted. One function is flagged: F-09 user access and roles sits in an unscripted cell, at 73% agent confidence.
“Our SOP is stricter than the grid here.” The cell says unscripted, but the procedure asks for a script whenever a function controls who can approve GMP results.
Two options are on screen. Follow QA-SOP-0412 §6.2 with a limited script — three steps proving only Reviewers can approve results, +0.5 h — or keep it unscripted and send an SOP deviation request to IT Quality. Omar takes the recommended option. TS-2614-09 is drafted, F-09 moves to scripted, limited, and the total becomes 56 h.
“Decided by you: F-09 follows QA-SOP-0412 §6.2 — limited script TS-2614-09 added.”
The plan's eight sections — purpose and scope, system and intended use, risk determination, assurance approach, supplier evidence, records, roles, acceptance — each cite the passage they rest on. The supplier evidence section records 1,146 supplier tests with 0 open deviations and a SOC 2 report with no exceptions, and says plainly that customer configuration is tested by Northwind Bio. Any section can be redrafted; the plan exports to Word.
Results are recorded as digital evidence — test logs, system audit trails and exported reports — without screenshots unless a step needs one.
Pull-point schedule calculation is scripted because a miscalculated pull window means samples tested out of window, and the stability data behind the shelf life is lost. Five steps on template TPL-TS-03: the 3-month pull due Jan 1, 2027 with its ±7-day window, the 18-month pull due Apr 1, 2028 with ±14 days, a start-date change blocked without a reason, and the audit trail recording old value, new value and reason when one is given.
Every step names the requirement it proves. No step is written without one.
Sample login and labels is medium impact, medium likelihood: a wrong label is caught by the scan-to-confirm step at the chamber. So it gets charter UC-2614-01 on template TPL-UC-01 — explore logging and labelling a full 6-month pull for two conditions, trying wrong-sample scans and reprints — 45 minutes, tester Priya Raman, recorded as notes, issues and a conclusion.
Every requirement traces to a script, a charter, supplier evidence or a recorded rationale, with its grid cell and proof id. The first draft had one gap: URS-031, keep records and their audit trail for 10 years. The checker closed it with the supplier's SOC 2 retention control C1.1 and evidence review VE-2614-01, in which the reviewer confirms that 10-year retention is configured. The matrix filters by method and exports to Excel.
An untraced requirement blocks signing.
The signature covers the validation plan and test strategy, the risk assessment of 15 functions, the trace matrix of 42 requirements, 9 scripts and 3 charters. Omar chooses the meaning — “I am the author of this validation plan, risk assessment and trace matrix” — and enters his password.
“Your name, the date and time, and the meaning are recorded with the signature and shown on every exported page.”
All five checks before signing are green: every function placed with its cited passage, 42 of 42 traced, the SOP conflict decided, supplier evidence current, the intended use signed by the system owner. VP-2614 moves to QA approval. Dr. Maya Chen is next to sign, as reviewer — “I confirm the intended use and every grid placement” — then Dana Okafor, who approves it for testing. People and agents are on the same audit trail.
“Signed — VP-2614 moved to QA approval; Dr. Maya Chen and Dana Okafor notified.”
The same validation, seen by the four people who carry it — what their weeks looked like, and what they look like now.
Six agents read the requirements and supplier evidence, place every function on a risk grid and draft the scripts and trace matrix; the validation lead decides every placement.
Reads the URS, specifications, supplier packages and SOC reports in place, and splits them into numbered requirements with page anchors.
States the intended use, GxP impact and GAMP category from the signed intended-use statement and the system inventory.
Groups requirements into functions and places each on the risk grid by impact and likelihood of failure, with a one-line reason and the cited passage; raises a decision when the company SOP is stricter.
Matches the supplier validation package and SOC 2 controls to the requirements they already prove, and checks the SOC 2 period against the acceptance window.
Drafts the validation plan, robust or limited scripts as each function's grid cell asks, and time-boxed charters for the rest, on the company templates.
Builds the requirement-to-test trace matrix, flags gaps, proposes the cheapest sufficient proof to close each one and checks the plan against the risk grid.
Decides every placement. The agents propose; a named person decides.
Ask about any function, risk placement, requirement or source — or say what to change. Every answer points to the passage it rests on.
Why is the pull-point calculation in the robust-script cell?
Because it sits at high impact, high likelihood. Impact: a miscalculated pull window means samples tested out of window, and the stability data behind the shelf life is lost. Likelihood: the windows are our own configuration, not supplier-tested. Script TS-2614-02 proves the ±7 and ±14-day windows and the reason-for-change rule in 5 steps.
Is the supplier SOC 2 report still acceptable?
Yes — the Kelvora SOC 2 Type II report covers Jul 1, 2025 to Jun 30, 2026, which ended within our 12-month window. Backup and restore (control A1.2) and retention (C1.1) were tested with no exceptions. The supplier package covers the signature engine and installation, but never our configuration.
How is the e-signature on result approval tested?
E-signatures are high process risk and always scripted. The signature engine itself is supplier-tested (OQ-ES-01 to 14), so TS-2614-07 is a limited script of our configuration: the meaning on the report and no approval of your own results.
Add a rule: every unscripted charter needs a named tester and a 45-minute time box
Done. Every unscripted charter now needs a named tester and a 45-minute time box, as our SOP asks for unscripted records. The open validations already comply. The rule is on in Settings and recorded in the audit trail.
13 screens from the working solution, on its sample data. Pick one to see it large.
The risk grid and the rules every validation is placed against are settings, approved by IT Quality and on the audit trail. Changing a cell re-places every open validation.
| Setting | Default | Choose from |
|---|---|---|
| High impact, high likelihood | Scripted, robust · 6 h | Scripted, robust · Scripted, limited · Unscripted · Supplier evidence · Rationale only — for each of the nine cells |
| High impact, low likelihood | Supplier evidence · 1.5 h | Any of the five methods |
| Scripted testing for every Part 11 electronic-signature function | On | Required by QA-SOP-0412 |
| Raise a decision when our SOP is stricter than the guidance | On | On · Off |
| Block signing while any requirement is untraced | On | Required by QA-SOP-0412 |
| Accept SOC 2 Type II reports whose period ended within | 12 months | 6 months · 12 months · 18 months |
| Customer configuration is always ours to test | On | Supplier evidence never covers protocols, specifications, roles or interfaces we configure |
| Approvals | Author · reviewer · approver | Validation lead signs as author, the system owner reviews, IT Quality approves |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample validation data · “target” = the design goal, measured in the live solution · “estimated” = the solution's own estimate on its sample module, or our estimate where noted · Sources: FDA, Computer Software Assurance for Production and Quality System Software (final guidance, September 2025) · ISPE GAMP 5, 2nd edition · 21 CFR Part 11. People, companies, systems and products named on this page are fictional — characters and sample data in the working solution.
Computer software assurance (CSA) is the risk-based approach FDA describes in its Computer Software Assurance for Production and Quality System Software guidance, final in September 2025: scripted testing, robust or limited, where a function's failure could compromise safety, unscripted testing for the rest, and the supplier's own testing leveraged where it applies. The Computer Software Assurance solution applies it per function, on a grid your IT Quality team approves.
CSV usually scripts and screenshots every requirement. Here each function is placed on a grid of impact against likelihood of failure, and the cell sets the method and hours. On the sample LIMS module, 6 of 15 functions get robust scripts, and the plan comes to 56 h of testing against an estimated 118 h for scripting every requirement.
The Vendor Evidence Matcher links requirements only to supplier tests and SOC 2 controls that prove the same behaviour, and checks that the report period ended within your window — 12 months by default. Functions it covers, such as backup or hosting, get a supplier evidence review. Configuration you own — protocols, specifications, roles, interfaces — is always tested by you.
The agent raises a decision instead of choosing. On the sample module, user access sat in an unscripted cell, but the SOP asks for a script for any function that controls who approves GMP results. The validation lead chose a limited script; the other option was to keep it unscripted and request an SOP deviation from IT Quality.
Yes. It drafts the validation plan, scripts and charters on your templates and a requirements traceability matrix in which every requirement reaches a script, a charter, supplier evidence or a recorded rationale. The record exports with the audit trail and, once signed, the signature manifest.
Yes. The agents place and draft; the validation lead decides every placement and can move any function, the system owner confirms the intended use and placements, and IT Quality approves before testing starts. Every change is on the audit trail, and a validation cannot be signed while a requirement is untraced.
Yes. The method and hours for each of the nine cells, the SOP-stricter decision, the supplier evidence window, signers, templates and connections are settings. Changing a cell re-places every open validation.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your CSV/CSA procedure, templates and a sample of past validations — and it goes live once every quality gate has passed. We will walk you through it on one of your own systems first.
Every audit-trail period reviewed on schedule and signed, rows cited
1-min demoAI Use Case Risk ClassificationEvery new AI idea classified in minutes, each conclusion tied to its clause.
1-min demoVendor Security AssessmentA cited vendor risk rating with gaps and controls, ready to sign
1-min demoWe'll run Computer Software Assurance on one of your own upcoming validations.