Risk-based computer software assurance: every validation pack composed from its sources, with testing sized to the risk
Every system's validation pack composed from its requirements and supplier evidence, with testing sized to the risk of each function.
See one case, screen by screen ↓Every new system, module, change and SaaS release needs its pack before go-live: a risk assessment per function, a validation plan and test strategy, test scripts, and a trace matrix that takes every URS line to its proof. The sources are already there — the URS, the configuration specification, the signed intended use, a 312-page supplier validation package, a SOC 2 report and your own CSV/CSA procedure. Reading them, and keeping them consistent with each other, is where the week goes.
Under time pressure the safe-looking answer is to script everything. It costs testing hours on management reports and news boards, and it hides the functions that really need the rigour — the pull-window calculation, the specification check, the audit trail. Computer software assurance asks for testing sized to the risk; doing that by hand means arguing each risk call from the guidance, the SOP and the supplier evidence, then rebuilding the trace matrix every time one call moves.
Estimated split for one new module, in working days, by hand and with the solution. The first five rows are the first draft (about 5 working days by hand; the 3.2 h target with the agents).
Six agents read the requirements, intended use and supplier evidence, then draft the plan, scripts and trace matrix; the validation lead decides every risk call.
Northwind Bio is adding the stability module of Kelvora LIMS 10 at Plant 3 — Leiden, live on Nov 16. Here is the pack being composed, decided and signed, screen by screen, in the working solution.
Seven packs in flight, four waiting on Omar, CourseLedger going live in 7 days. One chart follows 40 functions from their pack, through the risk call, to how each is proven: 10 high process risk, 21 not high risk, 7 vendor-covered, 2 with no GxP impact. 128 h of testing is planned, against 212 h if every requirement were scripted.
One amber band runs from “not high risk” to “scripted testing”: our SOP is stricter than the guidance.
VP-2614 opens with its sources attached: URS v1.3, the configuration specification v0.9 (still a draft), the intended use v1.0 signed by system owner Dr. Maya Chen, Kelvora’s validation package 10.0, its SOC 2 Type II report and QA-SOP-0412 v7. The intended use says why it matters: the module’s results support shelf-life assignment and the annual stability commitment.
The intake reader splits 214 pages into 42 requirements with page anchors. The intended-use assessor states direct use in the quality system, GAMP category 4, SaaS. The risk classifier groups 15 functions, 8 of them high process risk. The supplier package and SOC 2 report (period ended Jun 30, 2026) cover 2 functions. Then the plan, 8 scripts and 7 charters and evidence reviews are drafted, and the trace is checked.
“42 of 42 traced · 1 gap closed (URS-031) · 1 SOP conflict for you”
Fifteen functions in four columns: scripted testing, unscripted testing, vendor evidence and rationale only. 61.5 h of testing against 118 h if every requirement were scripted; 47 % of functions proven without a full script. Open any card to see why — for user access, the cited URS passage on the four roles sits beside the call.
The agent proposes unscripted testing for F-09 user access, and stops: “Our SOP is stricter than the guidance.”
The guidance allows unscripted testing for a function that is not high process risk. QA-SOP-0412 §6.2 asks for a script whenever a function controls who can approve GMP results. Omar has two choices: follow the SOP with a limited scripted test, or keep unscripted and request an SOP deviation from IT Quality. He follows the SOP; TS-2614-09 is drafted and the plan moves to 65 h.
“Decided by you: F-09 user access follows QA-SOP-0412 §6.2 — scripted (limited) test TS-2614-09 added.”
Eight sections — purpose and scope, system and intended use, risk determination, assurance approach, supplier evidence, records, roles, acceptance — with citations to the guidance, the SOP or the supplier documents, and a Redraft on each. The plan already records Omar’s call on user access, and exports to Word with the citations as footnotes.
TS-2614-02 proves the pull-point schedule in five steps on template TPL-TS-03: storage start Oct 1, 2026; the 3-month pull due Jan 1, 2027 within ±7 days; the 18-month pull due Apr 1, 2028 within ±14 days; a start-date change blocked without a reason. Each step names the requirement it proves. Sample login and labels gets a 45-minute charter for Priya Raman instead.
Every URS line maps to its function, its risk call and the script, charter, evidence review or rationale that proves it. The first draft left URS-031 — keep records and audit trail for 10 years — without a test; the checker closed it with the supplier’s SOC 2 retention control C1.1 and evidence review VE-2614-01, and marked the row.
Before signing: every function has a risk call, every requirement reaches proof, SOP conflicts are decided, supplier evidence is current, and the intended use is signed by the system owner. Omar signs with his password and the meaning “I am the author of this validation plan, risk assessment and trace matrix”.
Name, date, time and meaning are recorded with the signature and shown on every exported page.
The pack moves to QA approval, and the system owner and IT Quality are notified. Dr. Maya Chen is next to sign as reviewer — “I confirm the intended use and the risk calls” — then Dana Okafor as approver — “I approve this pack for testing”. Beside the signatures, the audit trail lists every agent step and every human decision, and cannot be edited.
The same pack, seen by the four people who author, test, review and approve it — what their week looked like, and what it looks like now.
Six agents read the requirements, intended use and supplier evidence, then draft the plan, scripts and trace matrix; the validation lead decides every risk call.
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 proposes high or not-high process risk with a one-line rationale and the cited passage; raises a decision when the SOP is stricter than the guidance.
Matches the supplier validation package and SOC 2 controls to the requirements they already prove, and checks the report period against the acceptance window.
Drafts the validation plan, scripted tests for high-risk functions 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 says so, and checks the plan against the board.
Decides every risk call. The agents propose; a named person decides.
Ask about any pack, function, requirement or source — or say what to change. Answers cite the passage they rest on.
Why is the pull-point calculation scripted?
Because it is high process risk: a miscalculated pull window means samples tested out of window, and the stability data behind the shelf life is lost. The module is used directly in the quality system. 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 (A1.2) and retention (C1.1) were tested with no exceptions. The supplier package covers the signature engine and installation, but never our configuration.
What in QualiNest 26R3 touches our validated functions?
Nine changed functions, two need scripts: the CAPA effectiveness due dates and the new “hold batch” field are high risk; the intake form, search, reports and digest get unscripted testing; the database and sign-on updates are covered by vendor evidence. The release goes live Oct 19 — in 12 days.
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. All the charters in the open packs 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.
Risk rules, supplier evidence and approvers are settings, applied to every pack.
| Setting | Default | Choose from |
|---|---|---|
| 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 · 12 · 18 months |
| Customer configuration is always ours to test | On | Required by QA-SOP-0412 §8.1 |
| Author — signs the plan, risk assessment and trace matrix | Omar Haddad | Omar Haddad · Priya Raman |
| Reviewer — confirms intended use and risk calls | System owner of the pack | System owner of the pack · Dr. Maya Chen · Sam Patel |
| Approver — approves before testing starts | Dana Okafor | Dana Okafor · Lena Ortiz |
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 data · “target” = the design goal, measured in the live solution · “estimated” = our estimate, before deployment · “typical” = published validation cost benchmarks (one GMP system takes 6–12 weeks) · Guidance: FDA, Computer Software Assurance for Production and Quality System Software (final guidance, Sept 2025). People, companies and products named on this page are fictional — characters and sample data in the working solution.
A risk-based approach to proving that software used in production and quality systems is fit for its intended use, set out in FDA’s final guidance of September 2025. Functions with high process risk get rigorous assurance such as scripted testing; the rest can be proven with unscripted testing, supplier evidence or a recorded rationale. The Assurance Pack Composer drafts that risk call and the pack that follows from it.
The Function Risk Classifier groups the requirements into functions and asks whether a failure could create a quality problem that foreseeably compromises safety, citing the requirement and the intended use. Each call shows its reason, its source passage and the agent’s confidence. The validation lead can move any function, and the plan, scripts and trace matrix update with it.
The agent raises a decision instead of choosing. It cites the guidance and the SOP clause, recommends an option and shows the cost in testing hours. The validation lead decides — follow the SOP, or keep the lighter approach and send an SOP deviation request to IT Quality.
Yes, where the supplier tested the same behaviour. The Vendor Evidence Matcher links requirements to supplier tests and SOC 2 controls, and accepts a SOC 2 report only if its period ended within your window (12 months by default). Your own configuration — protocols, specifications, roles and interfaces — is never covered by supplier evidence.
The validation plan and test strategy, the function-level risk assessment, scripted tests and unscripted charters, the requirements traceability matrix and the audit trail, with a signature manifest once signed. It exports to Word, Excel and PDF, or as a package for your validation tool.
Yes. The agents draft and propose; a qualified person makes every risk call and signs. The validation lead signs as author, the system owner as reviewer and IT Quality as approver, and every agent step and human change is in an audit trail that cannot be edited.
Yes. Packs cover new systems, new modules, changes, upgrades, SaaS releases and spreadsheets. For a SaaS release it maps each release note to the validated functions it touches and plans regression before release day.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your CSV/CSA SOP, script and charter templates — and it goes live once every quality gate has passed. We will compose a pack from one of your own systems first.
Every audit-trail row screened on its risk schedule, each finding explained with its log rows cited.
1-min filmAI Use-Case IntakeEvery new AI idea classified against the rules in minutes, each conclusion tied to its clause.
1-min filmVendor Cyber RiskEvery vendor’s security evidence read and mapped to your controls, with a cited risk rating ready to sign.
1-min filmWe’ll compose a pack from one of your own systems’ URS, supplier package and SOP.