SOP: Validation and Control of GxP Scripts, Notebooks, and Low-Code Analytics

This is a ready-to-use SOP for the category of tools that traditional computerized system validation programs quietly skipped: code written in-house by the people who use it. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows. This content is educational reference, not legal or regulatory advice; verify each cited regulation against the current published source before you rely on it.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> identifies, classifies, specifies, reviews, tests, releases, changes, reviews periodically, and retires scripts, notebooks, queries, dashboards, and macro-enabled workbooks that are built in-house and used in GxP activities.

The objective is that any number produced by such a tool and used in a GxP decision can be shown to be correct, attributable to a named author and an identified code version, independently reviewed by a second qualified person, produced in a controlled environment, and reproducible on demand for the retention period of the record it supports.

2. Scope

2.1 In scope

This procedure applies to any of the following when the output is used in a GxP activity:

2.2 Out of scope

• Packaged vendor applications validated through the standard computerized system lifecycle. Those are governed by <<FILL: SOP-ID for computerized system validation>>.
• Machine-learning and generative models, governed by <<FILL: SOP-ID for AI/ML lifecycle>>.
• Robotic process automation bots, governed by <<FILL: SOP-ID for RPA>>.
• Infrastructure and platform qualification. The compute platform is qualified once under <<FILL: SOP-ID for infrastructure qualification>>; this procedure validates the logic that runs on it, not the platform.
• Tools whose output is used only for exploration, hypothesis generation, or internal curiosity and never informs a GxP decision. These are recorded as non-GxP under section 5.2.4 but are not validated.

2.3 The boundary rule

Intended use sets scope, not the size of the tool, not the technology, and not who wrote it. A twenty-line script that feeds a batch disposition is in scope at high rigor. A ten-thousand-line notebook that produces a slide for an internal seminar is out of scope. The following statements are not acceptable justifications for excluding a tool:

• It is only a script.
• It is low-code, so no code was written.
• It is just a view of data that lives somewhere validated. (A view that drops or duplicates rows misrepresents the validated source.)
• The author checks it every time.
• It is in Excel.
• It is temporary.

Any disagreement about whether a tool is in scope is resolved by Quality Assurance and the decision is recorded on the classification form (section 5.2).

3. Responsibilities

3.1 The independence rule

The person who wrote the logic cannot be the only person who attests that it is correct. For every tool of risk class A or B, at least one qualified person other than the author signs the code review record and at least one person other than the author signs the release. Where the department is genuinely too small to provide an internal reviewer, the reviewer may be drawn from another function or an approved external party, and the arrangement is recorded on the code review record. A reviewer shortage is not a justification for self-review.

4. Definitions

• Analytics tool. Any item listed in section 2.1. Used throughout this procedure to avoid repeating the list.
• Record of origin. The output that is the authoritative GxP record. If the tool writes the number that is filed, reported, or dispositioned against, the tool produces the record of origin. If the authoritative value stays in a validated source system and the tool only presents it, the tool produces a view.
• Validated version. A specific, immutable version of the tool code, identified by a version control tag and the underlying commit identifier, that has passed testing and carries an approved release statement.
• Pinned environment. An explicit, stored manifest of the language runtime version and the exact version of every library the tool depends on, together with the isolation mechanism (virtual environment, package snapshot, or container image) that enforces it.
• Independent code review. A documented review of a named version of the code performed by a qualified person who did not author it, against the approved specification and the source method.
• Known-answer test. A test in which the expected result was derived independently of the tool, by hand calculation, by a validated system, or by a second tool, before the tool was run.
• Shadow tool. An analytics tool in GxP use that is not on the inventory register.

5. Procedure

5.1 Register the tool

1. Before a tool is used for any GxP purpose, the owner registers it in the GxP analytics tool inventory register (<<FILL: register ID>>) and receives a tool ID.
2. Registration is required even where the eventual classification is non-GxP. The register is the evidence that a decision was made rather than skipped.
3. Where a tool is already in GxP use and is not registered, the owner registers it immediately, records it as a retrospective entry, and Quality Assurance assesses whether data already produced by the tool requires verification under <<FILL: SOP-ID for data integrity investigation>>.

5.2 Classify the risk

1. The owner completes the risk classification form (<<FILL: form ID>>), answering the five determining questions:
   1. What GxP decision does the output support?
   2. Is the output the record of origin, or a view of a record held in a validated system?
   3. Is the calculation complex or novel, or trivial and transparent?
   4. How many people rely on it, and how often?
   5. Could an undetected error in this tool reach product or patient?
2. The classification produces a risk class and a corresponding assurance level:

3. Quality Assurance reviews and approves the classification. The classification and its rationale are inspectable records.
4. Where the answer to any of the five questions changes, the owner reclassifies through change control. Reclassification upward requires the full deliverable set for the new class before continued GxP use.

5.3 Specify the tool

1. The owner writes the specification (<<FILL: specification template ID>>) before development is considered complete, and always before testing.
2. The specification states intended use, inputs, processing logic including the equation where a calculation is performed, outputs and which field is the controlled result, rounding and significant figures, error handling, environment dependencies, and the limits of validity.
3. Requirements are numbered and written so that each one can be tested by observation. A requirement that cannot fail a test is not a requirement.
4. For a dashboard, the specification lists every calculated measure, every query transformation step, every calculated column, every relationship, the refresh logic, and any row-level security rule, each with its own requirement ID.
5. The specification is approved before testing begins. Changes to the specification after approval go through change control.

5.4 Place the tool under version control

1. All GxP tool source is stored in the controlled version control system at <<FILL: repository location or namespace>>. Personal drives, email attachments, shared network folders, and laptops are not acceptable homes for a GxP tool.
2. The protected branch used for GxP releases does not accept direct commits. Changes reach it only through a reviewed merge or pull request.
3. When a version passes testing and is approved for GxP use, it is tagged using the convention <<FILL: tag convention, e.g. v1.0-validated>>. The tag, and the commit identifier it points to, are recorded in the inventory register and on the release statement.
4. Outputs used for GxP purposes carry a provenance stamp containing at minimum the tool ID, the version tag, the commit identifier, the run timestamp, the operator, and an identifier or hash of the input dataset.
5. Credentials, connection secrets, and GxP source data are never committed to the repository. Secrets are held in <<FILL: secrets management solution>>.
6. For low-code content, the project is stored in a text-diffable project format where the platform offers one, in preference to a single binary file, because a binary file cannot be meaningfully reviewed by diff. Where only a binary format exists, the reviewer documents what was compared and how.

5.5 Perform independent code review

1. Every risk class A and B tool undergoes documented independent code review before first GxP use and before any subsequent release.
2. The review is recorded on the code review record (<<FILL: record ID>>) and covers at minimum:
   • Correctness of the calculation against the approved specification and the cited source method.
   • Handling of edge cases, missing values, out-of-range values, and rounding.
   • Absence of hard-coded values that should be controlled parameters.
   • Absence of silent failure paths. The tool fails visibly or it does not fail.
   • Readability sufficient for a third person to maintain the tool.
   • No credentials and no GxP data committed to the repository.
   • For notebooks, evidence that the saved output was produced by the saved code.
3. Findings are recorded with a severity, and every finding is resolved or formally accepted with a rationale before the reviewer signs the conclusion.
4. Self-review is not independent review and does not satisfy this section.

5.6 Control the environment

1. The language runtime version and every library version are pinned in a manifest stored in version control alongside the code.
2. The tool runs in an isolated environment (virtual environment, package snapshot, or container image) on qualified infrastructure. The environment identifier, including an image digest where containers are used, is recorded in the inventory register.
3. Personal workstations are not acceptable production execution locations for risk class A or B tools.
4. A library, runtime, or platform upgrade is a change and is handled under section 5.9. Until the change is approved, production continues to run the previously validated pinned environment.
5. The environment manifest, and where practical the built environment artifact itself, is archived with the code so that a result can be regenerated later in the retention period.

5.7 Test the tool

1. Testing is executed against the approved specification using the verification test protocol (<<FILL: protocol template ID>>), scaled to the risk class:

2. Regardless of class, the following are tested where they apply to the tool:
   • The calculation against a known-answer reference derived independently of the tool.
   • Boundary and edge cases, including empty input, a single record, values at specification limits, and the rounding boundary.
   • Error handling on corrupt, missing, or wrongly typed input. The tool must not return a plausible wrong number.
   • Reproducibility: the same input run twice in the controlled environment produces identical output, and the tagged version reproduces an archived result.
   • For dashboards, each measure against an independent calculation on the same source data, and confirmation that filters, slicers, joins, and row-level security neither drop nor duplicate rows.
3. Automated unit tests that encode the known-answer cases and run on every change are accepted as testing evidence for the requirements they cover, provided the test code is itself under version control and reviewed, and the run results are retained.
4. Any test failure is recorded as a test deviation under <<FILL: SOP-ID for validation deviations>>, root-caused, corrected by a new reviewed commit, and re-tested. Failures are not silently corrected during execution.

5.8 Release the tool

1. The validation or CSV lead prepares a release statement containing: tool ID, validated version tag and commit, environment identifier, specification version, code review record reference, test protocol and results reference, open deviations and their disposition, stated limitations, and the conclusion that the tool is fit for its intended use.
2. The tool owner and Quality Assurance approve the release statement before first GxP use.
3. The inventory register is updated with the validated version tag, the validation date, and the next periodic review due date.
4. Only the released, tagged version is run for GxP purposes, and only from the controlled environment.

5.9 Control change

1. Any of the following is a change requiring a change record under <<FILL: SOP-ID for change control>>:
   • A change to the code, including a change that the author considers cosmetic.
   • A change to a calculation, a parameter, a threshold, or a rounding rule.
   • A change to the input source, its schema, its units, or its filters.
   • A change to the output format or to which field is the controlled result.
   • A runtime or library upgrade, including a patch release.
   • A change to the execution environment, platform, or scheduled run.
   • A change to the intended use.
2. Library and runtime upgrades. The requester assesses whether the upgrade could affect the computed result, including changes to numerical methods, statistical defaults, rounding behaviour, date handling, sort stability, and default parameter values. Where results could be affected, the applicable test cases are re-executed in the new pinned environment and the results compared to the previously recorded results before the environment is re-tagged as validated. An upgrade with no result impact still requires a recorded assessment.
3. Emergency change. Where a defect is producing wrong GxP output, the tool is withdrawn from use first, the affected data is quarantined and assessed, and the correction then follows the normal path. Speed is achieved by withdrawing the tool, not by skipping review.
4. Every change re-enters the lifecycle at the earliest affected step. A calculation change requires specification update, code review, testing, and a revised release statement. A comment-only change requires a code review and a recorded assessment that no testing is affected.
5. The version control history plus the change record together form the change evidence chain. Neither alone is sufficient.

5.10 Review periodically

1. Each registered tool is reviewed at the interval set by its risk class:

2. The periodic review confirms:
   • The tool is still in use, and by whom.
   • The intended use and risk class are still correct.
   • The version running in production matches the validated tag, with no undocumented drift.
   • The environment is still pinned, still supported, and still on qualified infrastructure.
   • All changes since the last review went through change control.
   • Any incidents, deviations, or user-reported discrepancies since the last review were resolved.
   • The owner and reviewer named on the record are still with the organization and still appropriate.
3. Findings from periodic review are routed to CAPA or change control as appropriate. A tool found running an untagged version is withdrawn until reconciled.

5.11 Decommission

1. When a tool is retired, the owner raises a decommissioning record under <<FILL: SOP-ID for decommissioning>> and confirms:
   • What replaces it, if anything, and that the replacement is validated.
   • That no downstream tool, report, or scheduled job still calls it.
   • That the code, environment manifest, environment artifact, specification, review record, test evidence, and release statement are archived for the retention period of the records the tool supported.
   • That access to run the tool is removed and any scheduled execution is disabled.
2. The inventory register entry is marked decommissioned with the date, and is retained rather than deleted.

5.12 Maintain the inventory

1. The inventory custodian performs a documented discovery sweep at <<FILL: frequency, e.g. every 6 months>> to find shadow tools, using at minimum the methods listed in the inventory register procedure (repository scan, scheduled-job review, platform workspace review, source-system query log review, and a departmental attestation).
2. Each function head attests at the same frequency that all GxP analytics tools used by their function are registered.
3. Shadow tools found in GxP use are registered immediately and assessed for data impact.

6. Acceptance criteria

This procedure is being followed when all of the following are demonstrable on request:

• Every GxP analytics tool in use appears on the inventory register with an owner, a risk class, and a validation status.
• Every risk class A and B tool has an approved specification whose requirements are numbered and testable.
• The version running in production for each tool matches a tag in version control, and that tag is named on the release statement.
• Every release of every class A and B tool has a signed independent code review record naming a reviewer who is not the author.
• The environment for each class A and B tool is pinned, and the pinned manifest is stored with the code.
• Test evidence exists showing the calculation verified against an independently derived reference, plus boundary, error handling, and reproducibility results.
• Every change since release, including library upgrades, has a change record, and the results of any re-testing are recorded.
• Periodic reviews are performed on schedule and their findings are closed.
• No GxP output in the retention period is untraceable to a specific tool version and input.

7. Records generated

8. References

21 CFR 211.68(b), which requires that controls be exercised over computers or related systems so that changes are made only by authorized personnel, and that input to and output from the system be checked for accuracy. 21 CFR Part 11 (1997), electronic records and electronic signatures, which applies where electronic records are created, modified, maintained, archived, retrieved, or transmitted under a predicate rule. FDA guidance, “Computer Software Assurance for Production and Quality Management System Software”, issued 3 February 2026. This version supersedes the final guidance issued 24 September 2025, which was titled “Computer Software Assurance for Production and Quality System Software”, and that final was itself preceded by the draft issued 13 September 2022 under the same shorter title. Cite the current version and date, and do not attach the current title to either earlier document. EU GMP Annex 11, Computerised Systems (2011), which is the version currently in force. A draft revision was published for consultation on 7 July 2025 with the consultation period closing 7 October 2025; that revision was not final at the time of writing and should be monitored rather than cited as a requirement. ISPE GAMP 5 Second Edition (2022), a risk-based approach to compliant GxP computerized systems, which places bespoke code in category 5 and directs a critical-thinking, risk-scaled lifecycle. Referenced by title; do not reproduce its text. MHRA “GXP Data Integrity Guidance and Definitions”, March 2018. PIC/S PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments, effective 1 July 2021. ICH Q9, Quality Risk Management, for the risk-based scaling of assurance effort.

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

9. Revision history

10. Approvals

Filled specimen

The following shows how the lifecycle reads for one tool taken end to end under this procedure. The company, identifiers, and dates are illustrative.

Tool. ANL-0007, a Python script that fits a stability regression for drug product lot potency and writes the slope, the predicted potency at the proposed shelf life, and the one-sided lower 95% confidence bound into the table used in the annual product review.

The point of the specimen is the chain. Every number this script has produced since 12 May 2026 can be tied to tag v1.0-validated, commit a3f19c4, a named reviewer who is not the author, a pinned environment, and a test result that was written down before the tool was run.

Common inspection findings this SOP prevents

• No inventory exists, so the number of GxP scripts and dashboards in use is unknown and the first document request cannot be answered.
• A tool feeding a GxP decision has no statement of intended use, so there is no criterion against which “testing” could have passed.
• The only evidence of correctness is that the author checked their own work.
• The version that produced an archived result cannot be identified, so the result cannot be regenerated or defended.
• A dashboard reviewed before disposition silently dropped rows through a join or a security rule, and the trend the reviewer relied on was built on an incomplete dataset.
• The logic changed between two runs with no change record, so two lots were assessed using different math.
• A library was upgraded on the production host with no assessment and no regression testing, and the previously validated behaviour is gone.
• Tools run from personal workstations, so access, backup, and reproducibility all fail at once and the tool disappears when the person leaves.
• Notebook output on file was never produced by the code on file, because cells were run out of order or edited after running.
• Rounding in the tool disagrees with rounding in the validated source system, and nobody had specified either.
• A retired tool is still being called by a scheduled job that nobody remembered.

How to adapt this SOP

1. Set your document number, owner, effective date, and the cross-references in the header and section 2.2 to your real procedures.
2. Decide whether you will run three risk classes as written or map them onto your existing criticality tiers. Keep the class labels identical across the classification form, the inventory register, the specification, and the test protocol so the chain reads cleanly.
3. Name your actual version control system, repository namespace, tag convention, and secrets manager in section 5.4. Generic wording here is the most common reason the procedure is unfollowable in practice.
4. Set the periodic review intervals in section 5.10 to intervals your organization can actually meet. An interval you miss is worse than a longer interval you keep.
5. If your low-code platform offers a text-diffable project format, state it by name in section 5.4 and require it for new content, with a documented transition plan for existing binary project files.
6. Decide who your independent reviewers are before you issue the procedure. Name the qualification criteria in section 3 rather than leaving reviewer competence undefined.
7. If you have an existing backlog of unregistered tools, issue this procedure together with a time-bound remediation plan and a documented risk-based sequence, rather than declaring every legacy tool non-compliant on day one.
8. Confirm every reference in section 8 against the current published version before issue, and pay particular attention to the status of the Annex 11 revision, which was still in draft at the time of writing.