This is a ready-to-use checklist for one restore-test cycle of one validated analytics tool’s archived environment, run on the cadence set in your governing procedure. It exists because “the environment is archived” is an assertion until someone actually boots it. A dependency list or an unopened container image is not evidence that a five-year-old calculation can still be reproduced; this checklist turns that claim into a timed, evidenced exercise against a real archive. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers, and route the checklist through your normal document control. A filled specimen follows. This is general guidance to adapt and verify, not legal or regulatory advice; confirm each cited regulation against the current source before you rely on it.
The rule that shapes this checklist: restore the environment the way someone would five years from now, using only what is actually in the archive, not what the original author remembers.
Document control header
| Field | Entry |
|---|---|
| Document title | Analytics Tool Environment Archival and Restore-Test Checklist |
| Document number | <<FILL: CL-ID, e.g. CL-CSV-052-01>> |
| Parent SOP | <<FILL: SOP-ID for validation of GxP scripts, notebooks, and low-code analytics, or your environment archival procedure>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Document owner | <<FILL: role, e.g. Validation / CSV Lead>> |
| Applies to | <<FILL: analytics tools / registers in scope>> |
When to use this checklist
Run it once per archived tool environment, on the restore-test cadence set below unless your procedure states a different one. Run it also whenever the archival method changes (a new container registry, a new export format), and once before a newly archived environment is relied on as evidence for the first time.
| Tool risk class (per the analytics tool risk classification form) | Default restore-test cadence |
|---|---|
| A (High) | Every 2 years, or immediately before any planned re-platform |
| B (Medium) | Every 3 years |
| C (Low, GxP) | At periodic review |
Before you start
| Item | Where it comes from |
|---|---|
| The archived environment under test (container image, environment export, or equivalent) | The tool’s environment archive, located by its own inventory reference, not by asking the original author where it is |
| A documented re-hydration procedure | The tool’s release record or the environment archival procedure |
| A retained reference input dataset | The tool’s test evidence or validation package |
| The retained expected output for that reference input | The tool’s test evidence or validation package |
| Compute capable of actually running the archived image or environment (does not need to be production infrastructure) | <<FILL: sandbox, archival test host, or equivalent>> |
| The tool’s current re-platform-versus-archive decision on file | The tool’s periodic review record |
How to complete
- Enter the test identification block.
- Work sections A to D in order. Do not consult the original author before attempting section A; the point of the test is whether the archive and its documented procedure are sufficient on their own.
- Mark each item Pass, Fail, or NA. NA requires a reason on the same line.
- Any Fail is logged in the finding log and routed for remediation. Continue the remaining items so the full picture is captured.
- Complete the re-platform decision confirmation and the signoff.
Test identification
| Field | Entry |
|---|---|
| Tool ID and name | <<FILL>> |
| Risk class | <<FILL: A / B / C>> |
| Archived environment reference (image tag, digest, or export identifier) | <<FILL>> |
| Original validation or release date of this environment | <<FILL>> |
| Tester (performing the restore) | <<FILL>> |
| Test date | <<FILL>> |
| Reviewer | <<FILL>> |
Section A: what was archived
| # | Check | Pass | Fail | NA | Evidence or comment |
|---|---|---|---|---|---|
| A1 | A complete, bootable image or environment export exists, not only a dependency list or a Dockerfile intended to be rebuilt later | ||||
| A2 | The archive reference (tag or digest) matches exactly what the tool’s release record cites as validated | ||||
| A3 | A documented re-hydration procedure exists: where the archive is stored, what retrieves it, and what is needed to run it | ||||
| A4 | The retained reference input and its retained expected output are both present and associated with this archive | ||||
| A5 | The archive location is independent of any single person’s knowledge (a shared, indexed store, not an individual’s laptop or personal cloud account) |
Section B: restore and run
| # | Check | Pass | Fail | NA | Evidence or comment |
|---|---|---|---|---|---|
| B1 | The archive was retrieved using only the documented re-hydration procedure, without undocumented steps supplied from memory | ||||
| B2 | The environment booted or restored without error on the available compute | ||||
| B3 | The tool ran against the retained reference input without modification to the archived code or environment | ||||
| B4 | The output matches the retained expected output to the stated precision | ||||
| B5 | No undocumented manual workaround was required to get the above to succeed (if one was required, document it as a finding even though the test ultimately passed) |
Section C: horizon risk review
| # | Check | Pass | Fail | NA | Evidence or comment |
|---|---|---|---|---|---|
| C1 | The language or runtime version in the archive is checked against its own published support timeline; its current status (supported, approaching end of support, or already unsupported upstream) is recorded here regardless of whether the restore itself passed | ||||
| C2 | The container runtime or platform needed to boot the archive is itself still available and supported | ||||
| C3 | Any package repository or channel referenced by the archive (beyond the frozen image contents) is confirmed not to be relied upon at restore time, or is confirmed still reachable if it is |
Section D: re-platform versus archive-as-evidence decision
| Field | Entry |
|---|---|
| Is this tool still used to produce new GxP decisions going forward | Yes / No |
| If Yes | Re-platform plan exists, with a target date before the current stack loses support, and re-verification scope defined: <<FILL>> |
| If No | Confirmed archived as read-only evidence; no re-platform planned; rationale: <<FILL>> |
| If unclear | Default decision: archive as evidence; flagged for the next periodic review; stated reasoning: <<FILL>> |
| Decision confirmed by | <<FILL: Validation/CSV lead or QA, per governing procedure>> |
Finding log
Record every Fail. One row per finding.
| Item # | What was observed | Severity (see below) | Immediate action | Deviation / CAPA reference | Notified to, date |
|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Severity guide
| What was found | Severity | Action |
|---|---|---|
| Restore succeeded but took longer than the timeframe stated in your procedure | Minor | Log and trend; consider improving the re-hydration procedure |
| Restore succeeded only after an undocumented manual workaround | Major | Deviation; update the documented re-hydration procedure; re-test |
| Output did not match the retained expected result within stated precision | Critical | Escalate; do not rely on this archive as evidence until root-caused per validation test failure management |
| Archive could not be retrieved or booted at all | Critical | Escalate immediately; assess whether other archived tools share the same dependency on an unavailable runtime, registry, or format |
| Reference input or expected output missing or incomplete | Major | Deviation; the archive cannot currently serve as reproducibility evidence; remediate before the next reliance on it |
Acceptance criteria
- A complete, bootable environment archive exists for the tool, with a documented re-hydration procedure, not only a dependency manifest.
- The archive was restored and run using only that documented procedure, and the output matched the retained expected result to stated precision.
- The restore-test ran on the cadence set for the tool’s risk class, not only once at the time of original archival.
- The horizon risk review (section C) is current, even when the restore itself passes, so a future unsupported-runtime risk is visible before it becomes an emergency.
- A current, documented re-platform-versus-archive-as-evidence decision is on file for the tool, with a stated rationale.
- Every Fail is logged, classified by severity, and routed to remediation before this archive is relied on again as reproducibility evidence.
References
21 CFR 211.68(b) (controls over computers and accuracy of input and output). 21 CFR Part 11 (electronic records, retrievability over the retention period). EU GMP Annex 11 (risk-based validation of computerised systems; record retention). FDA guidance, Computer Software Assurance for Production and Quality Management System Software (scale assurance effort to risk).
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following shows the checklist completed for a stability-trend script archived five years after its original validation. Company, system, and numbers are illustrative.
Test identification
| Field | Entry |
|---|---|
| Tool ID and name | ANL-0012, stability slope script |
| Risk class | A |
| Archived environment reference | Image digest sha256:4f2a… tagged v1.0-validated-2021 |
| Original validation / release date | 11 March 2021 |
| Tester | R. Singh (Validation/CSV) |
| Test date | 18 September 2026 |
| Reviewer | A. Patel (QA) |
Selected item results
| # | Result | Evidence or comment |
|---|---|---|
| A1 | Pass | Full container image present in the archive registry, not a rebuilt-from-recipe reconstruction |
| A2 | Pass | Digest matches the one cited in the original release statement |
| A3 | Pass | Re-hydration procedure document CSV-REHYD-009 names the registry, the pull command, and the required runtime version |
| A4 | Pass | Reference dataset (12 timepoints) and expected slope/LCB values retained with the archive record |
| A5 | Pass | Archive held in the shared validation evidence store, indexed by tool ID |
| B1 | Pass | Retrieved using only CSV-REHYD-009, no steps supplied from memory |
| B2 | Pass | Image booted on the archival test host without error |
| B3 | Pass | Ran against the retained reference dataset unmodified |
| B4 | Pass | Slope and lower confidence bound matched the retained expected values exactly |
| B5 | Pass | No workaround needed |
| C1 | Pass, with a note | Interpreter version in the image is approaching its own published end of support within the next two years; noted for the next periodic review |
| C2 | Pass | Container runtime still current and supported |
| C3 | Pass | No live package repository dependency at restore time; the image is fully self-contained |
Re-platform decision
| Field | Entry |
|---|---|
| Still used for new GxP decisions | No, this specific environment reproduces only the 2021 submission calculation; a current version of the tool runs the active stability program on a currently supported stack |
| Decision | Archived as read-only evidence; no re-platform planned for this specific archived environment |
| Decision confirmed by | A. Patel, QA, 19 September 2026 |
Disposition
| Field | Entry |
|---|---|
| Overall outcome | Pass |
| Tester | R. Singh, signed, 18 September 2026 |
| QA approval | A. Patel, signed, 19 September 2026 |
What makes this specimen useful is the C1 note on an otherwise clean pass: the restore worked today, and the record also shows the team is already watching the one thing most likely to break it next, which is exactly the forward-looking habit this checklist is meant to build.
Common inspection findings this checklist prevents
- An environment “archive” that is a requirements file and a Dockerfile nobody has rebuilt in years, discovered not to reproduce the original result only when an inspector asks for it.
- A restore-test performed once, at the time of original archival, and never repeated, so drift in the surrounding registry, runtime, or format goes undetected for years.
- A restore that only succeeds because the original author supplied an undocumented manual step from memory, which will not be available once that person has left.
- No reference input or expected output retained alongside the archive, so a successful boot proves nothing about whether the tool still computes the right answer.
- A tool nobody has formally decided to re-platform or to leave archived, so it drifts toward an unsupported runtime with no plan and no one noticing until it fails.
How to adapt this checklist
- Set your document number and point the parent SOP field at your real analytics script and notebook validation procedure, or a dedicated environment archival procedure if you maintain one separately.
- Set the restore-test cadence in the table above from your own risk-based rationale if it differs from the defaults shown.
- If you archive environments as something other than container images (a virtual machine snapshot, a full conda environment export with pinned channel snapshots), adapt sections A and B’s language but keep the same requirement: a complete, bootable artifact plus a documented re-hydration procedure, not a recipe alone.
- For a tool with many archived historical versions (one per major release over several years), prioritize restore-testing the versions still cited by open or recently closed submissions first, then work backward.
- Tie section D’s decision to the tool’s periodic review so the re-platform-versus-archive question gets revisited on a schedule rather than only when someone happens to think of it.
- Confirm every regulation in the references section against the current published version before issue.