Register: GxP Analytics Tool Inventory (Scripts, Notebooks, Dashboards, Queries, Macro Workbooks)

This is a ready-to-use register. It is the first document an auditor asks for when the subject turns to homegrown analytics, and not having one is itself a finding, because it means nobody knows how many tools produce GxP numbers or who owns them. Replace every <<FILL: ...>> placeholder, keep one row per tool, set your own document numbers and dates, and route the register through your normal document control. Field definitions, the discovery process for unregistered tools, and a filled specimen follow. This content is educational reference, not legal or regulatory advice; verify each cited regulation against the current source before you rely on it.

Register control header

How to use this register

1. One row per tool, one tool ID per row. A tool is one unit of released logic. A dashboard with fourteen measures is one row, not fourteen. A repository containing three separately released scripts is three rows.
2. Register before use, not after. The register entry is created when the tool is proposed for GxP use, with status Draft. It is not a record of what was validated; it is a record of what exists.
3. Register non-GxP tools too. A row that says “assessed, not GxP, must not be used for a GxP decision without reclassification” is the evidence that the decision was made rather than avoided.
4. Never delete a row. Decommissioned tools stay on the register with a decommission date, because the results they produced are still in the retention period.
5. The register is the schedule. The next-review-due column drives the periodic review workload. If it is not on the register, it does not get reviewed.

Because the field set is wide, this template splits the register into two linked tables sharing the tool ID. Keep them as two sheets of one controlled file, or as one table if your document system handles the width.

Part A: identity and intended use

Part B: control state and lifecycle

Discovering shadow tools

A register only reflects reality if you actively look for what is missing. Registration by voluntary self-declaration routinely undercounts, because the people running the highest-risk unregistered tools are usually the ones most convinced their tool is too small to matter. Run all five of the following at the frequency set in the header and record what each one found.

Additional prompts that reliably surface shadow tools: ask where each number in the quality metrics pack comes from and follow it back; ask what happens if the person who produces a recurring report is on leave; and read the file paths embedded in recently issued reports.

When a shadow tool is found in GxP use:

1. Register it immediately with status Draft and a note that it was found by discovery, not declared.
2. Classify it. If it is class A or B, suspend GxP use of its output until at least the code review and calculation verification are complete, or document the interim controls that make continued use defensible.
3. Assess whether results already produced require verification, under <<FILL: SOP-ID for data integrity investigation>>.
4. Record the discovery in the sweep record so the trend in shadow-tool count over time is visible to management review.

Register maintenance rules

• The custodian reconciles the register against version control tags at <<FILL: frequency>>. A production tool whose running version does not match its registered tag is suspended until reconciled.
• A tool with status Released and a next-review-due date in the past is escalated to <<FILL: role>> within <<FILL: number>> working days.
• Reclassification upward from C to B, or B to A, requires the deliverable set for the new class before continued GxP use.
• Owner departure triggers reassignment within <<FILL: number>> working days. An orphaned class A tool is suspended.
• The register itself is a controlled record and is retained for the life of the program.

Register: Part A (blank rows)

Register: Part B (blank rows)

Filled specimen

Seven rows spanning every risk class, including one non-GxP tool, one tool with a change in flight, one suspended shadow tool found by discovery, and one decommissioned tool. Names, identifiers, and dates are illustrative.

Specimen Part A

Specimen Part B

Specimen discovery sweep result

Shadow-tool count found by sweep: 7 in January 2026, 7 in July 2026. Flat rather than falling, which was escalated to management review with a proposal to add a repository template and a registration step to the analytics onboarding path.

Common inspection findings this register prevents

• The opening request for a list of GxP scripts and dashboards cannot be answered, and the list produced during the inspection is visibly assembled that week.
• A tool producing a number in a regulatory document is not on any list, so no classification, review, or test evidence exists for it.
• A dashboard reviewed before batch disposition has no named owner, and the person who built it left the company.
• Two versions of the same dashboard exist, one published and one in a personal workspace, and different people are looking at different numbers.
• A scheduled job is still refreshing and distributing output from a tool the organization believes was retired.
• Periodic reviews are overdue for tools nobody realised were still in production, because the review schedule was never linked to an inventory.
• A tool is described as validated but the version running cannot be matched to any tagged, released version.
• Exploratory output was pasted into a controlled document because nothing on the record said it was non-GxP.

How to adapt this register

1. Set your tool ID convention and never reuse an ID. Sequential is sufficient; embedding the department or year in the ID creates rework when either changes.
2. If you already maintain a computerized system inventory, decide deliberately whether these tools become rows in it or live in a separate register. A separate register is usually cleaner because the field set differs, but the two must cross-reference so a system upgrade surfaces the tools that read from it.
3. Add a column for the upstream system identifier if you want a system upgrade to immediately show which analytics tools are exposed to the schema change. This is the single most useful extra column in practice.
4. Set the reconciliation and sweep frequencies to what you will actually do. Two real sweeps a year beat four scheduled sweeps and one performed.
5. Track shadow-tool count found per sweep as a metric and take it to management review. A count that does not fall means the controlled path is still harder than the uncontrolled one.
6. If your document system cannot handle the width, keep Part A and Part B as two sheets of one controlled workbook joined on tool ID, and control the workbook itself under the same rules this register applies to macro workbooks.
7. Reference this register by number in the governing SOP, the change control procedure, and the periodic review procedure, so that each one drives updates back into it.