This is a ready-to-use checklist. Replace every <<FILL: ...>> placeholder with your own specifics and route completed copies through your normal periodic review and retention process. A worked filled specimen follows the template. Verify each cited regulation against the current source before you rely on it.
Purpose
Qualifying the off-host security log store at installation proves the tamper-evidence control, write-once/read-many storage, an object-lock retention policy, or hash-chaining, worked on that day. It does not prove the control still works a year later, after a storage migration, a platform upgrade, or a policy change. This checklist re-tests the control on a defined schedule so a silently degraded protection is caught before, not after, the evidence is needed.
Scope
| Field | Entry |
|---|---|
| Log store / platform | <<FILL>> |
| Tamper-evidence mechanism in use | <<FILL: WORM, object-lock, hash-chaining, or combination>> |
| GxP systems whose security events this store protects | <<FILL>> |
| Verification frequency | <<FILL: e.g. annually, or more often for High tier>> |
| Performed by | <<FILL: role, independent of the team that administers the log store>> |
Verification checklist
| # | Item | Pass / Fail / NA |
|---|---|---|
| 1 | Select a test event already committed to the store (or a designated test partition, if the platform supports one, to avoid touching production evidence) | <<FILL>> |
| 2 | Attempt a controlled deletion of the test event using credentials that would be available to a GxP host administrator | <<FILL>> |
| 3 | Confirm the deletion attempt was blocked outright, or produced a detectable integrity failure (a logged denial, a hash mismatch); a silent success is an automatic Fail | <<FILL>> |
| 4 | Attempt a controlled alteration of the test event’s content | <<FILL>> |
| 5 | Confirm the alteration attempt was blocked or detected the same way | <<FILL>> |
| 6 | Independently recompute the stored hash or chain value for a sample of archived events (minimum <<FILL: sample size>>) | <<FILL>> |
| 7 | Confirm the recomputed value matches the value recorded at ingestion for every sampled event | <<FILL>> |
| 8 | Confirm the object-lock, WORM, or retention-lock setting is currently active on the store (not just documented as configured at go-live) | <<FILL>> |
| 9 | Confirm the active retention period is still at or beyond the retention period of the GxP records this store protects | <<FILL>> |
| 10 | Confirm no storage-tier migration, platform upgrade, or configuration change since the last verification has altered the tamper-evidence mechanism without a documented change-control and re-verification | <<FILL>> |
| 11 | Confirm the administrators of the underlying storage platform (if a different team from the log-store owner) do not hold rights that bypass the tamper-evidence control | <<FILL>> |
Escalation
Any Fail is a data integrity finding, not a maintenance ticket. Raise a deviation the same day per <<FILL: SOP-ID for deviations>>, notify the system owners of every GxP system this store protects, and treat the period since the last successful verification as a window of unproven tamper-evidence until a root cause and corrective action are documented. Do not wait for the next scheduled verification to re-test after a Fail; re-test immediately after the fix.
Acceptance criteria
The verification is acceptable when every item carries a documented basis, any Fail escalates same-day, and an independent reviewer signs the record.
References
21 CFR 11.10(e) (audit trails shall not obscure previously recorded information, applied to the log store). EU GMP Annex 11, clause 9 (audit trails) and clause 12 (security). MHRA GxP Data Integrity Guidance and Definitions; PIC/S PI 041.
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
| Field | Entry |
|---|---|
| Log store / platform | Central security log archive, object storage with retention lock |
| Tamper-evidence mechanism in use | Object-lock (compliance mode) plus per-batch hash chaining |
| GxP systems protected | CDS (HPLC/UPLC), LIMS, MES |
| Verification frequency | Annual (High tier) |
| Performed by | M. Osei, IT Security, independent of the log-store administration team |
| # | Item | Result |
|---|---|---|
| 1 | Test event selected | Test event from the designated test partition, dated 03 Sept 2026 |
| 2 | Deletion attempt made | Attempted using a credential equivalent to a CDS host administrator |
| 3 | Deletion blocked or detected | Pass; API returned an access-denied response, logged with a denial event |
| 4 | Alteration attempt made | Attempted a metadata field edit on the same test event |
| 5 | Alteration blocked or detected | Pass; object-lock prevented the write |
| 6 | Hash recompute, sample | 50 archived events sampled across the retention period |
| 7 | Recomputed values matched | Pass, 50 of 50 matched |
| 8 | Object-lock setting currently active | Pass, confirmed via platform console and exported configuration report |
| 9 | Retention period still sufficient | Pass, lock set to 10 years; longest-retention record it protects requires 7 |
| 10 | No unreviewed change since last verification | Fail; a storage-tier migration in May 2026 moved the archive to a new storage class, and the migration change record did not include a re-verification step |
| 11 | Storage-platform administrators cannot bypass the control | Pass, confirmed via access-control review; storage admins hold no object-lock override permission |
Disposition: Item 10 scored Fail. Deviation DEV-2026-0311 opened the same day. Root cause: the change-control procedure for infrastructure migrations did not include a tamper-evidence re-verification step as a mandatory checklist item. Corrective action: items 1-9 of this checklist were re-performed immediately following the finding (all passed, confirming no actual loss of protection occurred), and the infrastructure change-control procedure was updated to require this checklist’s completion as a closure condition for any future migration touching the log store.
Common inspection findings this checklist prevents
- Tamper-evidence proven once at installation qualification and never re-tested, so a later degradation (a lapsed retention lock, a stopped hashing job) goes undetected until evidence is actually needed and is not there.
- A storage migration or platform upgrade that silently carries forward a changed configuration, with no re-verification built into the change-control process.
- A log store’s retention setting correct at go-live but shortened later by a storage administrator with no connection to the GxP system the store protects.
- No independent party ever actually attempts to break the control; the tamper-evidence claim rests entirely on vendor documentation or a single historical test.
How to adapt this checklist
- Set the verification frequency from the risk tier of the systems the store protects; a High tier store supporting release decisions warrants more than an annual check.
- Build the test-partition or test-event mechanism into the log store’s own design so verification never touches real evidentiary records.
- Add this checklist’s completion as a mandatory closure condition in your infrastructure change-control procedure for any change touching the log store, the gap the filled specimen above illustrates.
- Point the escalation path to your real deviation and CAPA procedures.