Checklist: Before You Call a New Tool Non-GxP

Spreadsheets, scripts, and low-code apps are the systems that hide. Nobody builds a shadow-IT program on purpose; someone just needed a calculation faster than the change request queue could deliver one, and eighteen months later that spreadsheet is quietly feeding a disposition decision. This checklist screens a new or newly discovered tool before you write “non-GxP” next to it, using the same five-questions framework the rest of the system map runs on. Mark each item Pass, Fail, or N/A with a note; every Fail forces a real decision, not a shrug. Replace the <<FILL: ...>> placeholders where specifics belong. A filled specimen extract follows. Verify each cited regulation against the current source before you rely on it.

How to use

Run this on any tool someone flags, and periodically go looking rather than waiting to be told; shadow IT is discovered, not reported.
Answer from evidence. Open the tool. Ask the person who built it to show you, not describe it.
Every Fail gets a disposition decision in section 4, not a note that trails off unresolved.
A tool with no GxP touch at all still gets logged, so “we checked and it is not GxP” is a documented fact, not a memory.

Section 1: Discovery

#	Item	Ref
1.1	The tool was found through active search (shared drives, personal cloud storage, department SharePoint sites, browser extensions, low-code platform admin consoles), not only through voluntary self-reporting	Annex 11
1.2	The tool’s purpose and the GxP process it touches, if any, is documented in plain language	Annex 11
1.3	The person who built or introduced the tool is identified and available to explain how it works	Annex 11

Section 2: The five-questions screen

#	Item	Ref
2.1	What GxP decision the tool’s output drives is documented, even if the honest answer is “none”	Part 11
2.2	Where the original record lives, and in what format, is documented	Part 11
2.3	Who can change the data, and whether every change is captured, is documented	Part 11
2.4	Whether anyone signs or approves anything in or through the tool is documented	Part 11, §11.50
2.5	What happens if the tool fails, is lost, or the person who built it leaves is documented	Annex 11

Section 3: Spreadsheet, script, and low-code specific risk items

#	Item	Ref
3.1	If it is a spreadsheet: formulas that drive a GxP decision are protected from accidental edit (cell locking or an equivalent control)	Annex 11
3.2	If it is a spreadsheet: one controlled master version exists, not multiple copies circulating on different desktops	Part 11
3.3	If it is a script: the logic has been reviewed by someone other than the author	Annex 11
3.4	If it is a low-code app: it runs on a platform with access control and a change history, not an unmanaged personal account	Annex 11
3.5	The tool’s output has been checked at least once against a known correct answer, a manual calculation or a validated alternative	211.68

Section 4: Decision and disposition

#	Item	Ref
4.1	A documented decision exists: GxP and validated, GxP and scheduled for validation, or non-GxP with a written rationale	Annex 11
4.2	If disposed non-GxP, the rationale was checked against real use, not assumed use (would someone actually rely on this during a real event, an excursion, or a deadline crunch)	Annex 11
4.3	The decision and the tool are recorded in the GxP system inventory, even when the outcome is non-GxP	Annex 11
4.4	If disposed GxP, an owner and a validation timeline are assigned, and the tool’s use is restricted, or the decision is reversed, until validation completes	Annex 11

Scoring summary

Section	Items	Pass	Fail	N/A	Highest-risk open item
1 Discovery	3	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`
2 Five-questions screen	5	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`
3 Spreadsheet/script/low-code risk	5	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`
4 Decision and disposition	4	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`	`<<FILL>>`

Signoff

Role	Name	Signature	Date
Screener	`<<FILL>>`
Tool owner	`<<FILL>>`
QA	`<<FILL>>`

References

21 CFR 211.68 (automatic and electronic equipment); 21 CFR Part 11, including §11.50 (signature manifestation). EU GMP Annex 11 (computerised systems), including risk management and the scope of “computerised system.” Related reading: GxP computerized systems, a complete map for the five-questions framework this checklist applies, and infrastructure qualification and spreadsheet validation for what validating a Fail actually looks like.

Confirm the current version and clause numbers of each reference before issue.

Filled specimen

An extract from screening a QC-built spreadsheet that averages triplicate assay results before an analyst types the average into the LIMS.

#	Item	Result	Note / action
1.1	Found through active search	Fail (initially)	Discovered on a shared drive during a routine folder review, not self-reported by the analyst who built it
2.1	GxP decision documented	Fail	The averaged value directly feeds the LIMS result that supports disposition; this was not written down anywhere before the screen
3.1	Formulas protected	Fail	No cell locking; any user can overwrite the averaging formula with a typed value
3.2	One controlled master version	Fail	Three near-identical copies found across two analysts’ desktops with different formula versions
4.1	Documented decision	Pass (after screening)	Disposed as GxP, scheduled for validation as a small Category 5 custom tool per the spreadsheet validation guidance

Disposition: the spreadsheet is GxP because its output feeds a disposition-supporting LIMS entry, question 2.1 alone settles it. Interim control while validation is pending: the analyst’s supervisor reviews and initials every averaged value against the raw triplicate results before LIMS entry, and the two duplicate copies are removed so only the one under review remains in use. That interim control, not a promise to fix it later, is what makes the open Fail a managed risk rather than an ignored one.

Common inspection findings this checklist catches early

A spreadsheet or script that drives a release decision, discovered by an inspector rather than by the quality unit.
Multiple versions of the same calculation circulating with no way to tell which one is current or correct.
A tool disposed “non-GxP” on paper while people actually rely on it during real events, the gap between the written rationale and real practice.
A low-code app built on a personal account with no access control and no change history, invisible to the system inventory entirely.

How to adapt this checklist

Add rows for any risk pattern specific to your environment, for example a particular low-code platform your organization has standardized on.
Run it on every newly discovered tool immediately, and schedule a periodic active search rather than waiting for voluntary reports.
Convert every Fail in sections 1 through 3 into a disposition decision in section 4; a Fail with no disposition is not a completed screen.
Feed validated tools into your system inventory and your CSV program the same way any other new system would enter it.
Confirm the referenced regulations against their current published versions before issue.