Validation Execution Data Integrity Checklist

This is a ready-to-use checklist. 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 the template so you can see how a completed version reads. Verify each cited regulation against the current published source before you rely on it, and treat this as an educational reference to adapt rather than as legal or regulatory advice.

This checklist is written for the person executing the protocol, not for the person auditing it afterwards. It is short enough to complete honestly and specific enough to be worth completing. The governing process for anything that fails a check sits in SOP: Validation Test Incident Management.

How to use this checklist

• Section A is completed once, before the first test step of an execution session or campaign. If any item fails, execution does not start until it is resolved.
• Section B is the standing rule set held throughout execution. Complete it at the end of each execution session, or at the end of each protocol, whichever your procedure specifies.
• Section C is completed once, after execution is finished and before the summary report is drafted.
• Mark every item Pass, Fail, or NA. NA needs a reason in the comment column. A blank is not an answer.
• Any Fail is raised as a test incident under your incident management procedure before execution continues.

Section A: Before execution

Complete before the first test step. Every item is a precondition, not an aspiration.

Gate A. Execution does not begin with an open Fail in section A. If a Fail is discovered after execution has started, execution stops, the item is raised as an incident, and everything executed under the failed condition is assessed for validity.

Section B: During execution

These are the standing rules. Confirm each at the end of the session or protocol, and be honest, because the audit trail records the same facts whether or not you do.

Gate B. Any Fail in section B is raised as a test incident. Items B3, B4, B5, B10, B13, B17, and B20 are data integrity items; a Fail on any of these is notified to QA the same working day and assessed under your data integrity investigation procedure.

Section C: After execution

Complete after execution finishes and before the validation summary report is drafted.

Gate C. The validation summary report is not drafted with an open Fail in section C. See Validation summary report and release.

Signoff

References

21 CFR 211.68, 211.188, 211.194, and 211.192, for automatic equipment controls, batch record content, laboratory record content, and the investigation of unexplained discrepancies. 21 CFR Part 11, for electronic records and electronic signatures, including the requirement that record changes do not obscure previously recorded information. EU GMP Annex 11, Computerised Systems (2011, the version currently in force), for audit trail, access control, and data integrity expectations. The draft revision published 7 July 2025, consultation closed 7 October 2025, is not final. EU GMP Annex 15, Qualification and Validation (2015), which requires deviations from validation protocols to be documented with appropriate justification. EU GMP Chapter 4, Documentation, for good documentation practice expectations applied to the execution record. FDA guidance on data integrity and compliance with drug CGMP (2018), MHRA GxP Data Integrity Guidance and Definitions (2018), and PIC/S PI 041-1, for the ALCOA+ principles applied in sections A to C. FDA guidance “Computer Software Assurance for Production and Quality Management System Software”, issued 3 February 2026, for the risk-based assurance context. ISPE GAMP 5 Second Edition (2022), for the validation lifecycle context. Reference only.

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

Filled specimen

The following shows selected lines completed for an OQ execution session on a chromatography data system in a biologics QC laboratory. The company, system, names, and numbers are illustrative.

Section A, selected lines

A6 failed. Execution was held for two days while the environment patch level was reconciled with the production target under CR-CDS-2026-044, and TI-OQ-CDS-006 recorded the hold. That is the correct outcome. The alternative, executing anyway and noting the difference in the report, would have left every result open to the question of whether it applied to the environment actually released.

Section B, selected lines

B7 failed and was handled correctly: the omission was found, corrected as a late entry with both dates and a reason, and raised as an incident rather than quietly backfilled. A reviewer reading page 27 sees exactly what happened and when.

Section C, selected lines

C11 is the check that earns its place. The activity was legitimate and was already documented in an incident, but nothing tied the incident to the two audit trail entries an inspector would find first. Adding the cross-reference took ten minutes at the desk. Explaining it cold in a back room, two years later, without the cross-reference, takes considerably longer and looks worse.

Common inspection findings this checklist prevents

• Execution begun against a superseded protocol version, or against an uncontrolled printed copy.
• The build or environment under test not recorded, so the package does not establish what was actually qualified.
• Test results transcribed into the protocol at the end of the day from working notes, with the working notes discarded.
• A failing step retried before it was recorded, so only the passing attempt exists.
• Failed steps blanked, obliterated, or overwritten so the failure is invisible on the page.
• Expected results edited to match observed system behaviour and the step then marked PASS.
• Blank required fields across executed pages, later backfilled with no late-entry annotation.
• Corrections made with no reason recorded, or with the original entry rendered illegible.
• Execution performed under a shared or generic account, so entries cannot be attributed to a person.
• Screenshots with no visible timestamp or user identity, or evidence that was cropped or re-created after the fact.
• Re-executions performed before the authorization that permits them was approved, evidenced by the audit trail.
• Witness or second-person signatures applied in a batch after the fact by someone who did not observe the work.
• Audit trail entries showing record creation outside the documented execution window, with no explanation in the package.
• A summary report issued while incidents in the log carry no disposition, or open items carry no owner and no date.

How to adapt this checklist

1. Set your checklist number, and align the section A items to the prerequisites your protocols actually specify. Add rows for anything unique to your technology, such as instrument calibration status, reference standard traceability, or a controlled data set checkout.
2. Decide the completion cadence for section B and state it once. Per session works for multi-day campaigns; per protocol works for short executions. Mixed practice produces gaps.
3. Mark your own data integrity items in section B and tie them to your notification timing. The set flagged here (B3, B4, B5, B10, B13, B17, B20) is a starting point, not a fixed list.
4. For paper execution, write your good documentation practice correction convention into the B8 and B9 rows in your own words so the executor reads the rule at the moment of use rather than recalling a training slide.
5. For fully electronic execution, replace the paper-specific rows with the equivalent electronic controls: no shared accounts, no local file copies, e-signature meaning applied correctly, and a record-level audit trail that captures the change and the reason.
6. Where your protocols already carry an execution cover sheet, fold section A into it rather than issuing a second document, so the executor completes one thing well instead of two things quickly.
7. Add your specimen signature register reference to the C15 row so the signature review has something to check against.
8. Confirm every regulation in the references section against the current published version before issue, in particular the status of the EU GMP Annex 11 revision, which was still in draft at the time of writing.