Checklist: Data Integrity Forensic Self-Inspection

This is a ready-to-use self-inspection checklist. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control. A worked filled specimen follows the blank checklist. Verify each cited reference against the current source before you rely on it.

The value of this checklist is that it runs the inspector’s own method on your systems before an inspector does. A modern FDA or EU data integrity examination is forensic: the investigator sits at the workstation, opens the full instrument history, reconciles the user log against the batch record, reads audit trail configuration, and compares databases. If you have already done each of those moves on a sampling basis and can show the evidence, the conversation shifts from “did you know” to “you knew and you control it.” Run this quarterly at minimum, and after any relevant system change.

Document control header

How to use: work each check, mark Pass, Fail, or N/A, record the evidence kept, and raise an exception for any Fail per <<FILL: SOP-ID for deviations>>. A Fail on a release-critical system is handled the same working day.

1. CDS instrument history (total vs reported injections)

• Opened the full instrument acquisition history on a sample of instruments, not just the reported sequence.
• Compared total injections on the instrument against the injections in the reported result and the LIMS.
• Investigated any unreported, aborted, renamed, or “test”/“trial” injections, especially any that precede a passing reported result.
• Evidence kept: <<FILL: reviewer-signed log with instrument, sample count, total vs reported, exceptions>>

2. Audit trail configuration

• Confirmed the audit trail is enabled and capturing the required fields (who, when, old-to-new, reason).
• Confirmed no ordinary or privileged user can disable it, and that any config change to it is itself logged.
• Checked settings after the most recent upgrade and on the defined schedule.
• Evidence kept: <<FILL: configuration verification record with screenshots>>

3. User and access-log reconciliation

• Cross-checked the system user log (who logged in and when) against the batch or test record (who performed the work).
• Confirmed the named operator was qualified on the method and the instrument was qualified on that date.
• Investigated any mismatch (work recorded under one name, login under another).
• Evidence kept: <<FILL: self-audit checklist entries for the sampled batches>>

4. Shared and generic logins, privileges

• Confirmed unique user IDs; no shared or generic accounts on records-relevant functions.
• Confirmed administrator rights are segregated from analysts and operators (least privilege).
• Confirmed users cannot grant themselves rights without an approved, logged change.
• Evidence kept: <<FILL: access review record>>

5. File metadata and system clock

• Spot-checked raw file metadata (creation and modification dates, application user) against the batch record narrative.
• Investigated any file timestamp that predates the recorded start of testing.
• Confirmed the system clock is controlled, synchronized to a controlled source, and not user-changeable.
• Evidence kept: <<FILL: clock control evidence, metadata check notes>>

6. Cross-database reconciliation

• Compared results across separate systems (for example CDS versus LIMS, or historian versus MES batch record).
• Investigated any value present in one system but missing from the other, or differing between the two.
• Evidence kept: <<FILL: reconciliation record>>

7. Deletion, re-integration, and reprocessing

• Reviewed deletions of data, files, or sequences, and re-integrations, for a recorded reason.
• Confirmed reprocessing is controlled and the original and reprocessed results are both retained.
• Evidence kept: <<FILL: audit trail review record>>

Acceptance criteria

• Every check was performed on a defined, risk-based sample and the evidence retained.
• No unexplained trial injections, disabled audit trails, shared logins, uncontrolled clocks, or unreconciled cross-database differences remain open.
• Every exception is raised, investigated, and closed, with affected data held until resolved.
• The self-inspection is signed by a reviewer independent of the system operators and reviewed by QA.

References

21 CFR Part 11 (electronic records and signatures); 21 CFR 211.68 and 211.194. EU GMP Annex 11 (computerised systems) and the audit trail expectations. FDA Data Integrity and Compliance with Drug CGMP guidance (public domain, quoted only briefly if at all with attribution). MHRA GxP Data Integrity guidance and PIC/S PI 041 (referenced by number and title; described, not reproduced). The ALCOA+ principles the checks test against.

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

Revision history

Approvals

Filled specimen

The following shows the CDS instrument-history check completed for an example release-testing HPLC, so you can see the level of detail expected. The system and numbers are illustrative; replace them with your own.

In this example the self-inspection found what an inspector would look for: two unreported sample injections preceding a passing result, run under a shared login, with renamed files. It was raised the same day, a shared-login remediation and an audit-trail reason-code enforcement were opened, and the affected batch data were held pending investigation. Finding it yourself, with the evidence and the corrective actions in hand, is a completely different position from an inspector finding it cold.

Common inspection findings this checklist prevents

• Unreported trial injections before a passing result, discovered by the inspector rather than by you.
• A disabled or under-configured audit trail on a release-critical system.
• Shared or generic logins that break the who-did-what chain.
• File timestamps that contradict the batch record, unexamined.
• Values that differ between the CDS and the LIMS with no reconciliation.

How to adapt this checklist

1. Set the systems, sample size, and cadence from your data criticality and risk assessment.
2. Assign a reviewer independent of the people who operate the systems.
3. Point the exception route at your real deviation procedure and hold affected data until resolution.
4. Feed recurring findings into your internal audit plan and your remediation program.
5. Keep every completed self-inspection as evidence you run the inspector’s technique on yourself.