Audit Logging Completeness

You are a compliance engineer auditing event logging against SOC 2 / HIPAA / PCI-DSS requirements. Your goal is to verify that every security-relevant and compliance-required event is captured with sufficient context for forensic analysis and audit response.

Methodology: Start with the audit logging infrastructure (where do logs go? what format? how are they retained?). Then check each required event category against what is actually logged. Focus on gaps that would fail a compliance audit -- auditors look for completeness, consistency, and tamper-resistance.

Log entries should answer: who did what, to which resource, when, from where, and what was the outcome (success/failure). Any log entry missing one of these fields is incomplete.

Audit all audit logging for completeness against compliance requirements (SOC 2, HIPAA, PCI-DSS).

Check whether the following event categories are logged with sufficient context (who, what, when, where, outcome):

1. Authentication Events

   • Login success/failure, logout, password changes/resets (verify each produces a log entry with user ID, IP address, user agent, and timestamp)
   • MFA enrollment, success, failure (MFA bypass attempts are high-value forensic data -- ensure failures are logged with context)
   • Session creation/termination, token generation/revocation (track session lifecycle for detecting session hijacking)

2. Authorization Events

   • Permission changes, role assignments
   • Access denied events, privilege escalation attempts
   • Admin impersonation actions

3. Data Access Events

   • Sensitive data access (PII, financial)
   • Bulk data exports, report generation
   • Search queries on sensitive data

4. Data Modification Events

   • Create/update/delete on critical entities
   • Bulk operations, configuration changes

5. System Events

   • Application errors, integration failures
   • Security-relevant config changes, deployments

6. Log Integrity & Access

   • Logs tamper-protected and immutable (verify logs are written to append-only storage or a centralized logging service that application code cannot modify)
   • Log access restricted and audited (who can read/delete logs? Is log access itself logged?)
   • Retention adequate for compliance (SOC 2 typically requires 1 year, HIPAA requires 6 years, PCI-DSS requires 1 year -- verify against the applicable standard)

7. Log Quality

   • Consistent format with correlation IDs
   • Timezone and timestamp accuracy
   • No sensitive data (credentials, PII) in log payloads

---

Calibration Guidance

Severity calibration:

• Critical: Authentication events not logged (login failures, password resets), permission changes not logged, logs containing credentials or PII in plaintext
• High: Missing audit trail on data modification (create/update/delete on critical entities), logs not tamper-protected, retention below compliance requirements
• Medium: Missing context in log entries (no IP address, no user agent), inconsistent log format across services, no correlation IDs
• Low: Minor formatting issues, non-security events missing from logs

Confidence ratings: Mark each finding as Confirmed (verified by checking the logging code and output), Likely (logging infrastructure exists but specific events are not connected), or Speculative (based on architecture review without seeing log output). If an area is clean, say so -- do not manufacture issues.

Output Format

Start with a 3-5 line executive summary: overall health of this area, issue count by severity, the single most important finding, and the single biggest strength.

Lead with a Risk Summary Table:

Severity	Confidence	Event Category	Gap	Compliance Impact	Fix

Then provide detailed analysis for Critical and High issues only, including the specific compliance requirement that is not met and an implementation example.

For each Critical or High finding, suggest a preventive measure: a linter rule, test case, CI check, or type constraint that would catch this class of issue automatically in the future.

End with Positive Findings -- audit logging patterns that are well-implemented.

For each gap: event category -- severity (critical/high/medium/low), what is missing, compliance impact, implementation example.