This is a ready-to-use SOP for the system-layer security log, the operating-system, database, directory, and infrastructure log that sits underneath the application audit trail and catches what the application cannot see. 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. This content is educational reference, not legal or regulatory advice; adapt it to your own validated systems and quality system, and verify each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Document title | Security Event Logging, Monitoring, and Independent Review for GxP Systems |
| Document number | <<FILL: SOP-ID, e.g. SOP-IT-021>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Supersedes | <<FILL: prior version or "New">> |
| Document owner | <<FILL: role, e.g. Head of Quality Assurance>> |
| Applies to | <<FILL: sites / systems in scope>> |
1. Purpose
This procedure defines how <<FILL: COMPANY NAME>> captures, stores, alerts on, and independently reviews the system-level security events that protect GxP electronic records. The objective is to detect and investigate the events an application audit trail cannot see, such as direct database access, disabling of the audit trail, privileged logins, and clock changes, so that the integrity of GxP records can be demonstrated and not merely assumed.
2. Scope
This procedure applies to the infrastructure supporting GxP computerized systems that create, modify, maintain, or transmit electronic records: operating systems, databases, directory services, application servers, and the cloud or SaaS environments that host them. It covers the system security log as a distinct data integrity control. It does not replace application audit trail review, which is governed by <<FILL: SOP-ID for audit trail review>>, nor access provisioning, governed by <<FILL: SOP-ID for access management>>.
3. Responsibilities
| Role | Responsibility |
|---|---|
| IT / system administration | Configure and maintain event capture and near-real-time forwarding; do NOT own the log store or perform the independent review. |
| Security / log-store owner | Own the off-host store; enforce immutability and retention; hold access that the GxP host administrators do not have. |
| Quality Assurance | Perform or formally oversee the independent periodic review of privileged activity; raise and track exceptions; approve the logging configuration as a controlled item. |
| System / process owner | Define which events are integrity-relevant for the system; record the logging design in the data integrity assessment; resource the reviews. |
| Incident responder (named on-call) | Act on real-time alerts within the target time; document each response. |
| Validation / CSV | Qualify capture, forwarding, retention, and alerting per <<FILL: SOP-ID for CSV>>. |
4. Definitions
- System security log: the operating-system, database, directory, and infrastructure logs that record who accessed a host, who acted on data outside the application, and whether the controls protecting the record were changed.
- Integrity-relevant event: a security event that could hide, enable, or evidence a change to a GxP record (for example a disabled audit trail, a clock change, a privileged login, or direct database access).
- Off-host store: a log repository outside the administrative control of the people who administer the GxP hosts, with tamper-evident storage.
- Independent review: a review of privileged activity performed by, or formally on behalf of, someone who is not the administrator whose activity is under review.
5. Procedure
5.1 Define the integrity-relevant event set
For each in-scope system, confirm capture of at least the following, and record the mapping in the system’s data integrity assessment. Tie the depth of logging to what the system does; a system that feeds batch-release decisions earns the full set, a read-only reporting front end can carry a documented lighter set.
| Event | Why it is integrity-relevant |
|---|---|
| Audit trail disabled, paused, or reconfigured | Direct attack on the primary integrity control |
| System or instrument clock change | Backdating a late entry to look contemporaneous |
| Privileged / administrator login (interactive and remote) | The accounts with the means to falsify records invisibly |
| Direct database access outside the application | Bypasses the application audit trail entirely |
| Account created, deleted, enabled, disabled, or privilege changed | Unauthorized provisioning or quiet escalation |
| Security log cleared or logging service stopped | Destroying or muting the record of the above |
| Failed-login spike against a privileged account | Brute force or credential attack |
5.2 Turn on capture and verify it
- Map each event above to the specific log source and audit-policy setting on this system.
- Enable the corresponding audit policy on each host, including object-level auditing on the audit-trail tables or files, the configuration that enables them, and the logging configuration itself.
- Place the enabling configuration under change control so it cannot be altered silently.
- Do not accept capture as working until it is qualified per section 5.5.
5.3 Forward off-host to a tamper-evident store
- Forward the integrity-relevant events over an encrypted channel in near real time, not as a scheduled batch.
- Store them where the GxP host administrators cannot delete or alter them with their host credentials, with write-once or immutable storage and detectable tampering.
- Set retention to at least the retention of the records the system supports.
- Monitor the forwarding path; a host that stops forwarding has gone dark and must raise an alert.
- For a SaaS or cloud-hosted system where you do not own the host, obtain the vendor’s privileged-access and security-event feed by agreement, export or stream it to a copy you hold, and record in the data integrity assessment which events are yours, which are the vendor’s, and which neither side can see.
5.4 Alert on the time-sensitive events
Send a real-time alert to a named, available responder only for the events that cannot wait for the periodic review: audit trail disabled or paused on production, a backward clock change outside a maintenance window, logging stopped or forwarding silent, a failed-login spike against a privileged account, a new member of an administrator group, or a cleared security log. Route everything else to the periodic review. Set thresholds from observed baseline behavior, document them, and revisit them so the channel stays quiet enough that responders still act on it.
5.5 Qualify the logging
During OQ or a focused configuration verification, deliberately trigger each integrity-relevant event in a controlled environment and confirm it appears in the log with the correct who, what, and when, arrives intact at the off-host store, and, where applicable, fires the intended alert within target time. Record the qualification per <<FILL: SOP-ID for CSV>>. Capture that has never been tested is capture that cannot be relied on.
5.6 Perform the independent periodic review
- Set the review frequency by risk: monthly for high-risk production systems that feed release decisions, quarterly for lower-risk systems. Record the frequency and rationale.
- Draw the period’s events from the off-host store, never the host’s local copy.
- Reconcile every privileged login, audit-trail change, clock change, logging stop, account or privilege change, and direct database access to an authorizing record (an approved change, an incident ticket, a planned-maintenance entry).
- Confirm failed-login spikes were investigated and closed.
- Raise anything unexplained as a deviation per
<<FILL: SOP-ID for deviations>>and track it to closure. - Document the review with scope, period, source, reviewer, events examined, exceptions, and the disposition of each.
6. Acceptance criteria
A period is in control when all of the following are true:
- Each integrity-relevant event is captured with who, what, and when, and reaches the off-host tamper-evident store within minutes.
- The GxP host administrators cannot delete or alter events in the store using their host credentials.
- Real-time alerts reach a named responder within the defined target time, evidenced by a test event.
- The independent reviewer is demonstrably not the administrator under review, and every privileged action reconciles to an authorizing record or is raised as a deviation.
- Retention meets or exceeds the retention of the records the system supports.
- The review is documented, and every exception is tracked to closure.
7. References
21 CFR Part 11, sections 11.10(d), (e), and (g) (access limits, secure time-stamped audit trails, authority checks). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11, section 12 (security) and section 9 (audit trails). MHRA GxP Data Integrity Guidance and Definitions (segregation of administration from data ownership). PIC/S PI 041, Good Practices for Data Management and Integrity. ICH Q9, Quality Risk Management (for the risk-based frequency and scope). FDA guidance, Computer Software Assurance for Production and Quality Management System Software (for cloud and vendor oversight).
Confirm the current version and clause numbers of each reference before issue.
8. Records generated
- Logging configuration record (the controlled configuration under change control).
- Security event capture qualification record (section 5.5).
- Security event review record (section 8.1).
- Deviations and investigations raised from exceptions.
8.1 Security event review record (structure)
| Field | Entry |
|---|---|
| System(s) reviewed | <<FILL: SYSTEM NAME(S) / ID>> |
| Review period | <<FILL: from date>> to <<FILL: to date>> |
| Frequency basis | <<FILL: High / Medium / Low and why>> |
| Source (off-host store) | <<FILL: store name / reference>> |
| Privileged actions in period / reconciled | <<FILL: count>> / <<FILL: count>> |
| Exceptions raised | <<FILL: none, or list with detail>> |
| Deviation reference(s) | <<FILL: number(s) or N/A>> |
| Reviewer (name, signature, date) | <<FILL>> |
| QA approval (name, signature, date) | <<FILL>> |
9. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
10. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Reviewer (QA) | <<FILL>> | ||
| Approver (Quality Head) | <<FILL>> |
Filled specimen
The following shows a completed review record for an example chromatography data system whose results feed batch release. The company, system, and numbers are illustrative; replace them with your own.
| Field | Entry |
|---|---|
| System(s) reviewed | Chromatography Data System, database server DB-CDS-02 |
| Review period | 01 June 2026 to 30 June 2026 |
| Frequency basis | High: system holds release-testing results; monthly independent review |
| Source (off-host store) | Central log store LOG-ARCH-01 (owned by Security, immutable, 15-year retention) |
| Privileged actions in period / reconciled | 11 / 10 |
| Exceptions raised | One privileged DB login at 23:14 on 16 June by shared account svc_dbadmin, followed by a direct UPDATE on the results table with the audit-trail service stopped 90 seconds prior. No change record or deviation. |
| Deviation reference(s) | DEV-2026-0207 |
| Reviewer | R. Gomez (QA), signed, 03 July 2026 |
| QA approval | S. Idris (QA Manager), signed, 03 July 2026 |
In this example the independent reviewer, working from the off-host store rather than the host, found a privileged database login and direct edit that the application audit trail never recorded, because the change was made underneath it with the trail briefly stopped. The reviewer raised it the same day, opened a deviation, and the investigation invalidated the affected result, held the batch, decommissioned the shared account, removed direct database rights, and added a real-time alert on audit-trail-stopped. Finding, exception, deviation, hold, CAPA, that sequence is exactly what this SOP exists to produce.
Common inspection findings this SOP prevents
- The system-layer log does not exist, so nobody can say who logged into the host or database, or whether the audit trail was ever stopped.
- Security logs live only on the host, where the highest-privilege users can clear the evidence of their own actions.
- No detection or alert on audit-trail-disabled, the one event that most undermines the primary integrity control.
- IT reviews its own administrators, a structural conflict an inspector will name.
- Direct database access is possible and unmonitored, the classic invisible-falsification path.
- Logging was never qualified, so capture is trusted but never verified.
- A review happens but has no record of scope, source, or exceptions, so it is not evidence a review occurred.
- Log retention is shorter than the records the log protects.
How to adapt this SOP
- Set your document number, owner, and effective date in the header.
- Replace the generic event set in section 5.1 with the mapping to your actual OS, database, directory, and application log sources, and record it in each system’s data integrity assessment.
- Name your off-host store and the function that owns it in section 5.3, and confirm the GxP host administrators do not hold access to it.
- Point the cross-references in sections 2, 5.5, and 5.6 to your real audit trail review, access management, CSV, and deviation procedures.
- Set your alert thresholds in section 5.4 from your own baseline behavior and document them.
- Confirm every regulation in section 7 against the current published version before issue.