What the self-check covers
The workbook has two tabs. An Instructions tab explains how to run the list, what each column means, and the four texts the rows rest on. The Self-check tab is one copy per system: thirty-six checks in eight sections, each stating what the validation record must show for the check to pass, with a Pass / Gap / N-A dropdown, a column for the evidence reference, and a notes column for what is missing and who owns closing it.
The sections follow the route itself. Section 1 asks whether intended uses are written per feature, in the site's words. Section 2 is the risk call — one per intended use, answering the CSA question rather than a general risk score, and rated neither all-high (the old scripted pack relabelled) nor all-not-high (a two-line note where the release decision needed a scripted test). Section 3 covers the assurance activities: scripted tests with expected results on the high-process-risk functions, and for the rest an unscripted pass whose record says who tested, when, on which version, what they tried, what they saw, and who signed. Section 4 is vendor evidence — assessed once, leveraged where intended uses overlap, never a substitute for the site's own call. Section 5 is the record; section 6 is what happens at each release; section 7 is the inspection rehearsal.
- Intended use per feature — capture, routing, investigation, CAPA linkage, approval to close, the audit trail, the dashboard — each on its own line
- A process-risk call per intended use with a reason, and both failure modes checked: everything rated high, everything rated not-high
- Scripted evidence for the high-risk functions; a five-part record for every unscripted pass
- Vendor evidence assessed, leveraged where the intended use overlaps, and never the only line on the record
- A record tied to the software version, reviewed and approved — and the seven questions an investigator asks, each answerable in under a minute
How to use it
Copy the Self-check tab once per system, or once per module of an eQMS, and fill the four record-header rows first — the system, the software version, who assessed and who approves. Then work the sections in order with the validation record open beside you. Each check says what the record must show: mark Pass only when you can point at it, and put the pointer — document and section, record ID, system location — in the evidence-reference column. Gap means the record does not show it. N-A needs a reason in the notes.
Section 7 is where the sheet earns its keep. Take each of the seven questions — show me the intended use for this module; how did you decide how much to test it; show me the evidence for the approval workflow; what did you do for the reporting screens; what changed in the last release and what did you re-check; who reviewed and approved this record; where is the vendor's evidence and what did you do with it — and answer it from the record with a stopwatch running. Any Gap in sections 2, 3 or 5 is a finding to close before the next release, not a note for the next periodic review. The CSV vs CSA decision tree is the one-page version of the risk call; the validation master plan template is where the approach is declared before any of this is executed.
How an inspector reads this
Investigators do not audit a methodology. They pick a function — usually the approval workflow — and pull the thread: intended use, how much testing was decided and why, the evidence on this version, what was re-checked at the last release, who approved the record. FDA's guidance Computer Software Assurance for Production and Quality Management System Software (issued 3 February 2026, superseding the September 2025 issue) defines a high process risk as a failure that may result in a quality problem that foreseeably compromises safety, accepts unscripted testing as an assurance activity, lets validation work already performed by developers and suppliers be the starting point, and lists what the record should contain — the intended use, the result of the risk-based analysis, a description of the testing, the issues found, a conclusion on acceptability, who did it and when, and review and approval. The rows in this workbook are that list, turned into questions.
What produces observations is not the absence of a script. It is a record that cannot show why light testing was reasonable for a function that decides whether product ships, or a record that says "vendor tested it" and nothing more — which reads as no assessment at all. The self-check is built to find both before an investigator does.
