This is a ready-to-use operational qualification protocol for a system’s security logging. Its whole purpose is to prove, by deliberately triggering each integrity-relevant event, that capture, off-host forwarding, tamper evidence, retention, and alerting genuinely work, the test most often skipped and the one an inspector will ask you to demonstrate. Replace every <<FILL: ...>> placeholder, run it in a controlled non-production environment or an approved production window, and record every actual result as you observe it. A filled specimen of several test cases follows. This content is educational reference, not legal or regulatory advice; adapt it to your validated systems and verify each cited regulation against the current source before you rely on it.
Approval page
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Validation / CSV) | <<FILL>> | ||
| Reviewer (IT / System owner) | <<FILL>> | ||
| Reviewer (Security / log-store owner) | <<FILL>> | ||
| Approver (Quality Assurance) | <<FILL>> |
| Field | Entry |
|---|---|
| Protocol number | <<FILL: e.g. OQ-SEC-014>> |
| Version | <<FILL: 1.0>> |
| System under test | <<FILL: SYSTEM NAME / ID>> |
| Off-host store | <<FILL: store name / reference>> |
| Environment | <<FILL: qualification / production window>> |
1. Objective
To provide documented evidence that the security event logging for <<FILL: SYSTEM NAME>> captures each integrity-relevant event with the correct who, what, and when; forwards it to the tamper-evident off-host store in near real time; prevents or detects tampering with stored events; retains events for the required period; and raises the defined real-time alerts within their target time.
2. Scope
This protocol covers the operating-system, database, directory, and application security logging for the system under test, plus the forwarding path and the off-host store. It does not cover application audit trail content (qualified separately) or access provisioning. For a SaaS or cloud-hosted system, it covers the tenant, identity, and configuration logs you control plus verification that the contracted vendor event feed arrives at your store.
3. System description
<<FILL: brief description of the system, its GxP use, its hosting model on-premises or cloud, and the log sources in scope: OS audit policy, database native auditing, directory audit, application security log, forwarder, and store.>>
4. Prerequisites
| Prerequisite | Reference / evidence | Verified (initials, date) |
|---|---|---|
| Logging configuration approved and under change control | <<FILL: config record ID>> | |
| Off-host store operational, owned by a function separate from the GxP host admins | <<FILL: store record>> | |
| Test accounts and a non-production data set available | <<FILL>> | |
| Alert routing configured to a test recipient | <<FILL>> | |
| Approved maintenance window (if run in production) | <<FILL>> |
5. Roles
| Role | Responsibility |
|---|---|
| Tester | Executes each test case, records actual results contemporaneously |
| System owner / IT | Provides test access, drives host actions under direction |
| Security / store owner | Confirms arrival, immutability, and retention at the store |
| QA | Reviews executed protocol, dispositions deviations, approves the summary |
6. Acceptance criteria
Every test case passes its stated expected result. Specifically: each triggered event is captured with a unique attributable identity, the specific action and target, and a trustworthy timestamp; each captured event arrives at the off-host store within <<FILL: target minutes>>; an attempted deletion or edit of a stored event is prevented or detectably fails; retention is enforced for <<FILL: retention period>>; and each in-scope real-time alert reaches the test recipient within <<FILL: alert target time>>. Any failure is handled per section 8.
7. Test cases
| ID | Step / action to trigger | Expected result | Actual result | Pass/Fail | Tester | Date |
|---|---|---|---|---|---|---|
| TC-01 | Perform a privileged/administrator login to the host | Login captured with account, source, timestamp; arrives at store within target | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| TC-02 | Open a direct database connection outside the application and run a read against a GxP table | Direct DB access captured with account, statement type, target, timestamp; arrives at store | <<FILL>> | |||
| TC-03 | Stop the audit-trail / logging service, then restart it | Both stop and restart captured; a real-time alert reaches the test recipient within target | <<FILL>> | |||
| TC-04 | Change the system clock backward within a controlled test | Clock change captured with old and new value; alert fires (outside a maintenance flag) | <<FILL>> | |||
| TC-05 | Add a test account to an administrator or data-editing group | Privilege change captured; alert fires | <<FILL>> | |||
| TC-06 | Generate a burst of failed logins against a test privileged account above threshold | Failed-login spike captured; alert fires within target | <<FILL>> | |||
| TC-07 | Clear or attempt to clear the local security log on the host | Attempt captured; off-host copy retains the prior events intact | <<FILL>> | |||
| TC-08 | Attempt to delete or edit an event already in the off-host store, using host admin credentials | Deletion/edit prevented or detectably fails; tamper evidence recorded | <<FILL>> | |||
| TC-09 | Interrupt forwarding from the host for a defined interval | Forwarding-silent condition detected and alerted; gap visible on restoration | <<FILL>> | |||
| TC-10 | (Cloud/SaaS) Confirm the contracted vendor security-event feed arrives at your store for a test tenant action | Vendor event received intact, with who, what, and when | <<FILL>> | |||
| TC-11 | Confirm retention: verify an event dated at the start of the retention window is still present and unaltered | Event present, intact, within enforced retention | <<FILL>> |
Add or remove test cases to match the system’s log sources; TC-10 applies only to cloud or SaaS systems.
8. Deviation handling
Record any test case that does not meet its expected result as a deviation with the ID, the observed result, the immediate assessment, and the disposition. Do not overwrite the actual result; document it as observed. Retest only after the root cause is corrected and the correction is itself under change control. QA dispositions each deviation before the protocol is approved.
| Deviation no. | Test case | Observed result | Root cause | Correction | Retest result | QA disposition |
|---|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
9. Summary and conclusion
<<FILL: state the number of test cases executed, passed, and failed; summarize deviations and their disposition; and state the conclusion on whether the security logging for this system is qualified for its intended use.>>
| Field | Entry |
|---|---|
| Test cases executed / passed / failed | <<FILL>> / <<FILL>> / <<FILL>> |
| Open deviations at approval | <<FILL: none, or list>> |
| Conclusion | <<FILL: qualified / qualified with restrictions / not qualified>> |
| Approved by (QA, signature, date) | <<FILL>> |
10. Attachments
- Executed test-case records with contemporaneous actual results.
- Screen captures or store exports evidencing capture and arrival for each event.
- Alert-receipt evidence with timestamps.
- Deviation records and retest evidence.
References
21 CFR Part 11, sections 11.10(d), (e), and (g). 21 CFR 211.68 (equipment checks). EU GMP Annex 11, sections 12 (security) and 9 (audit trails); Annex 15 (qualification and validation). PIC/S PI 041, Good Practices for Data Management and Integrity. GAMP 5 (Second Edition) for the risk-based qualification approach.
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following shows several executed test cases for an example release-testing chromatography data system. Illustrative only.
| ID | Step / action to trigger | Expected result | Actual result | Pass/Fail | Tester | Date |
|---|---|---|---|---|---|---|
| TC-03 | Stop the audit-trail logging service, then restart it | Stop and restart captured; alert within 5 min | Stop captured 10:02:14, restart 10:03:41; alert received by on-call at 10:03:20 (66 s) | Pass | A. Cole | 20 Jun 2026 |
| TC-08 | Delete an event in the store using host admin credentials | Deletion prevented or detectably fails | Host admin credential denied delete on immutable store; attempt itself logged | Pass | A. Cole | 20 Jun 2026 |
| TC-04 | Move the system clock backward 30 min in test | Clock change captured; alert fires | Change captured (old 11:00, new 10:30); alert received at 11:00:52 | Pass | A. Cole | 20 Jun 2026 |
| TC-02 | Direct DB read on a GxP table outside the app | Direct DB access captured and forwarded | Captured with account, SELECT, target table, timestamp; at store within 40 s | Pass | A. Cole | 20 Jun 2026 |
In this run every integrity-relevant event was both captured and provable off-host, and the audit-trail-stopped alert, the single most important one, reached the responder in about a minute. That is the evidence that turns “we assume it logs” into “we tested that it does.”
Common inspection findings this protocol prevents
- The logging configuration was never tested, so nobody confirmed that triggering an event actually produces a log entry.
- The off-host store was assumed immutable but never proven to resist a host-admin deletion.
- Alerts were wired but never shown to reach a responder within the target time.
- Forwarding silence was not detected, leaving a blind window whenever a host stopped forwarding.
- Retention was configured but never verified against a real aged event.
How to adapt this protocol
- Set your protocol number, system, and off-host store in the approval and header blocks.
- Trim or extend the test cases in section 7 to match your actual log sources; keep TC-10 only for cloud or SaaS.
- Fill in the target times for arrival and alerting in section 6 from your own design.
- Run in a controlled environment or an approved production window, and record actual results as you observe them.
- Confirm every regulation in the references against the current published version before issue.