Audit Logging Review — If It Isn't Logged, It Didn't Happen

When to Use This Skill

• Before a SOC 2 Type II, HIPAA, or PCI-DSS audit — verify log completeness against control requirements
• When designing a new audit logging system from scratch
• When adding security-relevant features (auth, payments, data export, admin panels)
• After an incident — verify the audit trail captured the full timeline
• When migrating infrastructure — verify logs survived the transition intact
• During annual compliance review — validate retention, integrity, and coverage
• When integrating a SIEM — verify log schema compatibility and forwarding
• When onboarding a new third-party service that processes sensitive data

---

How It Works

┌──────────────────────────────────────────────────────────────────────────┐
│                     AUDIT LOG REVIEW FLOW                                │
│                                                                          │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐            │
│  │ PHASE 1   │  │ PHASE 2   │  │ PHASE 3   │  │ PHASE 4   │            │
│  │ Event     │─▶│ Schema &  │─▶│ Storage & │─▶│ SIEM &    │            │
│  │ Taxonomy  │  │ Structure │  │ Integrity │  │ Alerting  │            │
│  └───────────┘  └───────────┘  └───────────┘  └───────────┘            │
│   What events    Log format     Immutability   Forwarding               │
│   are captured   correlation    retention      dashboards               │
│   what is        required       lifecycle      alert rules              │
│   missing        fields         tamper detect  compliance               │
│       │                                             │                    │
│       │              ┌───────────┐                  │                    │
│       │              │ PHASE 5   │                  │                    │
│       └─────────────▶│ Compliance│◀─────────────────┘                    │
│                      │ Mapping & │                                       │
│                      │ Report    │                                       │
│                      └───────────┘                                       │
│                       Map findings                                       │
│                       to regulations                                     │
│                       produce report                                     │
│                                                                          │
│  ┌──────────────────────────────────────────────────────────────────┐    │
│  │                    LOG ARCHITECTURE                               │    │
│  │                                                                  │    │
│  │  ┌─────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐   │    │
│  │  │  App    │───▶│  Log     │───▶│  Primary │───▶│  SIEM    │   │    │
│  │  │ Service │    │ Pipeline │    │  Storage │    │ Platform │   │    │
│  │  └─────────┘    └──────────┘    └──────────┘    └──────────┘   │    │
│  │   emit event     validate        hot tier        correlate      │    │
│  │   structured     enrich          searchable      alert          │    │
│  │   JSON           route           immutable       dashboard      │    │
│  │                                       │                         │    │
│  │                                       ▼                         │    │
│  │                                 ┌──────────┐    ┌──────────┐   │    │
│  │                                 │  Warm    │───▶│  Cold    │   │    │
│  │                                 │  Storage │    │  Archive │   │    │
│  │                                 └──────────┘    └──────────┘   │    │
│  │                                  retrievable     6yr+ retain   │    │
│  │                                  90d-1yr         legal hold    │    │
│  │                                  lower cost      lowest cost   │    │
│  └──────────────────────────────────────────────────────────────────┘    │
└──────────────────────────────────────────────────────────────────────────┘

---

Phase 1: Event Taxonomy Audit

Verify that every security-relevant event type is captured. A missing event type is a blind spot.

Complete Event Taxonomy

The following table covers the minimum set of events that must be logged for compliance-grade audit trails. Check each one against the codebase.

┌──────────────────────────────────────────────────────────────┐
│               EVENT TAXONOMY — WHAT MUST BE LOGGED           │
└──────────────────────────────────────────────────────────────┘

Taxonomy Audit Process

┌──────────────────────────────────────────────────────────────┐
│              HOW TO AUDIT EVENT COVERAGE                      │
│                                                              │
│  FOR EACH EVENT TYPE IN THE TABLE ABOVE                      │
│                                                              │
│  1. Search the codebase for the event emission point         │
│     → grep -r "audit\|auditLog\|log.*event" src/             │
│     → Check middleware, route handlers, service layers        │
│                                                              │
│  2. Verify the event fires in ALL code paths                 │
│     → Success path AND failure path                          │
│     → API endpoint AND background job AND webhook handler     │
│     → Direct action AND cascading side effects               │
│                                                              │
│  3. Verify the event contains sufficient context             │
│     → WHO: actor ID (user, system, API key)                  │
│     → WHAT: action performed, resource type, resource ID      │
│     → WHEN: ISO 8601 timestamp with timezone                  │
│     → WHERE: IP address, user agent, request ID              │
│     → HOW: API endpoint, method, source (UI/API/webhook)      │
│     → RESULT: success/failure, error code if failure          │
│                                                              │
│  4. Mark the checklist in the taxonomy table                 │
│     → [x] = event logged with full context                   │
│     → [~] = event logged but missing fields                  │
│     → [ ] = event NOT logged — compliance gap                │
│                                                              │
│  SPECIAL ATTENTION                                           │
│  → Failed actions are MORE important than successful ones    │
│  → A failed login is more suspicious than a successful one    │
│  → A permission-denied is more interesting than permission-   │
│    granted                                                    │
│  → Log the attempt AND the outcome                           │
└──────────────────────────────────────────────────────────────┘

---

Phase 2: Log Schema & Structure

Every audit event must follow a consistent, machine-parseable schema. Free-text logs are not auditable.

Required Event Schema

{
  "timestamp": "2026-01-15T14:32:01.123Z",
  "event": "auth.login.success",
  "version": "1.0",
  "severity": "INFO",
  "actor": {
    "id": "usr_a1b2c3d4",
    "type": "user",
    "ip": "203.0.113.42",
    "user_agent": "Mozilla/5.0..."
  },
  "resource": {
    "type": "session",
    "id": "sess_x7y8z9"
  },
  "action": {
    "type": "create",
    "result": "success",
    "method": "POST",
    "endpoint": "/api/auth/login"
  },
  "context": {
    "request_id": "req_f4e5d6c7",
    "tenant_id": "tnt_m1n2o3",
    "source": "web_ui",
    "correlation_id": "corr_p4q5r6"
  },
  "metadata": {}
}

Schema Validation Checklist

┌──────────────────────────────────────────────────────────────┐
│              LOG SCHEMA VALIDATION                            │
│                                                              │
│  REQUIRED FIELDS (every event, no exceptions)                │
│  □ timestamp — ISO 8601 with milliseconds and timezone       │
│  □ event — dot-notation event name from taxonomy             │
│  □ severity — INFO, WARN, ALERT, ERROR                       │
│  □ actor.id — who performed the action (never a name/email)  │
│  □ actor.type — user, system, api_key, service               │
│  □ actor.ip — source IP address                              │
│  □ action.type — create, read, update, delete, execute       │
│  □ action.result — success, failure, error                   │
│  □ context.request_id — unique per-request correlation       │
│  □ context.tenant_id — multi-tenant isolation                │
│                                                              │
│  CONDITIONAL FIELDS                                          │
│  □ resource.type — when action targets a specific resource   │
│  □ resource.id — when action targets a specific record       │
│  □ action.endpoint — for API-triggered events                │
│  □ action.method — HTTP method for API events                │
│  □ context.correlation_id — for multi-step operations        │
│  □ metadata — event-type-specific additional data            │
│                                                              │
│  PROHIBITED FIELDS (never include)                           │
│  ✗ actor.name — use ID only, resolve via identity service    │
│  ✗ actor.email — PII, use ID only                            │
│  ✗ resource.content — log what was accessed, not the data    │
│  ✗ request.body — may contain passwords, PII, PHI           │
│  ✗ response.body — may contain sensitive data                │
│  ✗ stack_trace — only in application error logs, never audit │
│                                                              │
│  FORMAT RULES                                                │
│  □ JSON — one event per line (NDJSON/JSON Lines)             │
│  □ No multiline strings — breaks log parsing                 │
│  □ No nested objects deeper than 3 levels                    │
│  □ All timestamps in UTC                                     │
│  □ Event names use dot notation: category.entity.action      │
│  □ IDs are opaque strings — never sequential integers        │
└──────────────────────────────────────────────────────────────┘

Correlation ID Propagation

┌──────────────────────────────────────────────────────────────┐
│              CORRELATION ACROSS SERVICES                      │
│                                                              │
│  ┌─────────┐  request_id   ┌─────────┐  request_id          │
│  │ Client  │──────────────▶│ API GW  │──────────────▶        │
│  │ Browser │  (generated)  │ / LB    │  (forwarded)         │
│  └─────────┘               └─────────┘                       │
│                                  │                            │
│                    ┌─────────────┼─────────────┐             │
│                    ▼             ▼              ▼             │
│              ┌──────────┐ ┌──────────┐  ┌──────────┐        │
│              │ Backend  │ │ Worker   │  │ Notif.   │        │
│              │ Service  │ │ Queue    │  │ Service  │        │
│              └──────────┘ └──────────┘  └──────────┘        │
│               request_id   request_id    request_id          │
│               + corr_id    + corr_id     + corr_id           │
│                                                              │
│  EVERY service in the chain must:                            │
│  □ Accept request_id from inbound headers                    │
│  □ Generate one if not present                               │
│  □ Include it in every audit log event                       │
│  □ Forward it to downstream calls                            │
│  □ Include it in async job payloads                          │
│                                                              │
│  VERIFY BY:                                                  │
│  → Search for a single request_id across all log sources     │
│  → You should see the COMPLETE chain of events               │
│  → If events are missing, correlation is broken              │
└──────────────────────────────────────────────────────────────┘

---

Phase 3: Log Integrity & Immutability

Audit logs that can be modified are not audit logs. They are suggestions.

┌──────────────────────────────────────────────────────────────┐
│              LOG INTEGRITY VERIFICATION                       │
│                                                              │
│  STORAGE IMMUTABILITY                                        │
│  □ Audit logs write to a separate system/account from the    │
│    application database                                      │
│  □ Application credentials CANNOT delete or modify audit     │
│    log entries                                               │
│  □ Write-once storage is enforced:                           │
│    → S3 Object Lock (compliance mode, NOT governance mode)   │
│    → CloudWatch Logs with resource policy denying deletion   │
│    → Append-only database table (no UPDATE/DELETE grants)    │
│    → WORM-compliant storage (e.g., Azure Immutable Blob)    │
│  □ Log destination is in a SEPARATE AWS account or           │
│    subscription (cross-account logging)                      │
│  □ IAM policies prevent log deletion by application roles    │
│                                                              │
│  TAMPER DETECTION                                            │
│  □ Hash chaining — each log entry includes the hash of the   │
│    previous entry (detect gaps or modifications)             │
│  □ Digital signing — log batches are signed with a key       │
│    stored outside the application boundary                   │
│  □ AWS CloudTrail log file integrity validation enabled      │
│  □ Periodic integrity checks run automatically               │
│  □ Integrity violations trigger alerts                       │
│                                                              │
│  ACCESS CONTROL TO LOGS                                      │
│  □ Who can READ audit logs? (compliance officers, security)  │
│  □ Who can WRITE audit logs? (application service accounts)  │
│  □ Who can DELETE audit logs? (NO ONE during retention)       │
│  □ Are log access events themselves logged? (meta-auditing)  │
│  □ Is there break-glass access with post-hoc review?         │
│                                                              │
│  VERIFY BY:                                                  │
│  → Attempt to delete a log entry as the application user     │
│  → Attempt to modify a log entry via direct DB access        │
│  → Both MUST fail. If either succeeds, critical finding.     │
└──────────────────────────────────────────────────────────────┘

Immutability Architecture Patterns

---

Phase 4: Retention & Lifecycle

Compliance Retention Requirements

Storage Tier Lifecycle

┌──────────────────────────────────────────────────────────────┐
│              RETENTION LIFECYCLE                              │
│                                                              │
│  ┌──────────┐  90 days   ┌──────────┐  1 year  ┌─────────┐ │
│  │   HOT    │───────────▶│   WARM   │─────────▶│  COLD   │ │
│  │  Tier    │            │   Tier   │          │  Tier   │ │
│  └──────────┘            └──────────┘          └─────────┘ │
│   CloudWatch              S3 Standard-IA        S3 Glacier  │
│   Elasticsearch           or S3 One Zone-IA     Deep Archive│
│   Searchable in           Retrievable in        Retrievable │
│   seconds                 seconds               in hours    │
│   $$$ per GB              $$ per GB             $ per GB    │
│                                                              │
│  LIFECYCLE POLICY CHECKLIST                                  │
│  □ Hot → Warm transition is automated (not manual)           │
│  □ Warm → Cold transition is automated                       │
│  □ Cold tier has Object Lock with retention matching policy  │
│  □ Legal hold can freeze deletion beyond normal retention    │
│  □ Deletion after retention expiry is automated              │
│  □ Lifecycle policy is version-controlled and auditable      │
│  □ Cost monitoring alerts on unexpected log volume spikes    │
│                                                              │
│  LEGAL HOLD                                                  │
│  □ Mechanism exists to freeze specific date ranges           │
│  □ Legal hold overrides normal retention deletion            │
│  □ Legal hold can be applied by compliance, not engineers    │
│  □ Legal hold events are themselves logged                   │
│                                                              │
│  VERIFY BY:                                                  │
│  → Check S3 lifecycle rules or equivalent policies           │
│  → Confirm Object Lock retention period matches policy       │
│  → Attempt to delete a log in retention — must fail          │
│  → Check that no data exists beyond retention + legal hold   │
│    (GDPR: holding data too long is also a violation)         │
└──────────────────────────────────────────────────────────────┘

---

Phase 5: SIEM Integration & Alerting

Log Forwarding Validation

┌──────────────────────────────────────────────────────────────┐
│              SIEM INTEGRATION CHECK                           │
│                                                              │
│  FORWARDING PIPELINE                                         │
│  □ All audit events reach the SIEM platform                  │
│  □ No events dropped between source and SIEM                 │
│    (compare event counts at source vs destination)           │
│  □ Latency from event emission to SIEM ingestion < 5 min     │
│  □ Log format matches SIEM parser expectations               │
│  □ Timestamp parsing is correct (no timezone drift)          │
│  □ High-volume events don't cause backpressure or drops      │
│  □ Forwarding failures trigger alerts (not silent failure)   │
│                                                              │
│  REQUIRED ALERT RULES                                        │
│  □ Brute force detection — N failed logins in M minutes      │
│  □ Privilege escalation — role change to admin/owner         │
│  □ Impossible travel — login from two distant IPs in < 1hr   │
│  □ Mass data export — bulk download or large query results   │
│  □ Off-hours admin activity — admin actions outside business │
│  □ Cross-tenant access attempt — any tenant boundary         │
│    violation                                                 │
│  □ Account takeover signals — password change + email        │
│    change in rapid succession                                │
│  □ Log gap detection — missing expected heartbeat events     │
│  □ Log tampering — integrity check failures                  │
│                                                              │
│  DASHBOARDS                                                  │
│  □ Authentication activity — logins, failures, lockouts      │
│  □ Data access patterns — who accesses what, when            │
│  □ Admin activity — all administrative actions over time     │
│  □ Anomaly detection — deviations from baseline behavior     │
│  □ Compliance metrics — log coverage, retention status       │
│                                                              │
│  VERIFY BY:                                                  │
│  → Generate a test event in the application                  │
│  → Confirm it appears in the SIEM within 5 minutes           │
│  → Trigger each alert rule and confirm notification fires    │
│  → Review dashboards for data completeness                   │
└──────────────────────────────────────────────────────────────┘

---

Phase 6: PII in Audit Logs

Audit logs with the longest retention must have the least PII. This is not optional.

┌──────────────────────────────────────────────────────────────┐
│              PII DETECTION IN AUDIT LOGS                      │
│                                                              │
│  SCAN FOR THESE PATTERNS IN LOG OUTPUT                       │
│                                                              │
│  □ Email addresses — grep -r "email\|@" in log statements   │
│  □ Names — grep -r "name\|firstName\|lastName" in log calls  │
│  □ Phone numbers — grep for phone/mobile fields in logging   │
│  □ IP addresses — acceptable in audit logs (not PII in       │
│    most frameworks, but check GDPR jurisdiction)             │
│  □ Passwords — grep for password/secret in log statements    │
│    (CRITICAL if found — passwords must NEVER be logged)      │
│  □ Request bodies — check if full req.body is logged         │
│    (may contain forms with passwords, PII)                   │
│  □ Error messages — check if errors include user data        │
│  □ SQL queries — check if query parameters are logged        │
│    (may contain PII used in WHERE clauses)                   │
│                                                              │
│  PREVENTION PATTERNS                                         │
│                                                              │
│  1. Allowlist, not blocklist                                 │
│     → Log ONLY specified fields, not "everything minus PII"  │
│     → New fields default to NOT logged                       │
│                                                              │
│  2. Redaction at the logging layer                           │
│     → Sanitize before writing, not after                     │
│     → PII that reaches storage is already a problem          │
│                                                              │
│  3. Separate identity resolution                             │
│     → Audit log: { "actor": "usr_a1b2" }                    │
│     → Identity service: usr_a1b2 → "Jane Smith"             │
│     → When the user is deleted, the audit log remains        │
│       valid but de-identified                                │
│                                                              │
│  GDPR RIGHT TO ERASURE                                       │
│  □ Can you delete PII from audit logs on request?            │
│  □ If not, is there a documented legal basis for retention?  │
│  □ Are audit logs covered in your privacy policy?            │
│  □ Is there a data processing agreement covering log storage?│
└──────────────────────────────────────────────────────────────┘

---

Phase 7: Compliance Mapping

Map every finding to the specific regulatory control it affects.

Control-to-Requirement Matrix

---

Phase 8: Log Review Process

Logging without review is compliance theater.

┌──────────────────────────────────────────────────────────────┐
│              LOG REVIEW CADENCE                               │
│                                                              │
│  DAILY (automated)                                           │
│  □ Failed login threshold alerts reviewed                    │
│  □ Privilege escalation alerts reviewed                      │
│  □ Cross-tenant violation alerts reviewed                    │
│  □ Log pipeline health check (no gaps, no lag)               │
│                                                              │
│  WEEKLY (security team)                                      │
│  □ Admin activity review — all admin actions summarized      │
│  □ Data export review — who exported what, how much          │
│  □ New user/role assignments — expected vs unexpected         │
│  □ Alert tuning — false positive rate, missed detections     │
│                                                              │
│  MONTHLY (compliance officer)                                │
│  □ Log coverage report — taxonomy vs actual events logged    │
│  □ Retention compliance — tiers operating correctly          │
│  □ Integrity check results — any tamper indicators           │
│  □ Access review — who accessed audit logs themselves        │
│                                                              │
│  QUARTERLY (leadership + compliance)                         │
│  □ Comprehensive audit log health report                     │
│  □ Regulatory mapping updates — new requirements             │
│  □ Incident retrospectives — did logs support investigation  │
│  □ Cost review — log storage optimization opportunities      │
│                                                              │
│  VERIFY BY:                                                  │
│  → Check that review assignments exist (ticketing system)    │
│  → Check that review evidence is retained (meeting notes,    │
│    sign-off records)                                         │
│  → Auditors will ask "show me your last 3 monthly reviews"  │
└──────────────────────────────────────────────────────────────┘

---

Audit Logging Checklist

Use this master checklist at the end of every review.

Event Coverage (12 items)

□ Authentication events — login, logout, failed login, lockout
□ Authorization events — permission granted, denied, role changes
□ Data access events — record views, searches, exports, downloads
□ Data modification events — create, update, delete (single and bulk)
□ Admin action events — user management, config changes, impersonation
□ System events — service start/stop, migration, backup
□ Compliance events — retention purge, consent, data subject requests
□ API events — all endpoints producing side effects
□ Background job events — scheduled tasks, queue processing
□ Webhook events — inbound and outbound webhook execution
□ Error events — application errors, unhandled exceptions
□ Security events — rate limit triggers, WAF blocks, anomalies

Schema Quality (8 items)

□ Structured JSON format — no free-text log lines
□ Consistent event naming — dot-notation taxonomy
□ Required fields present on every event (timestamp, event, actor, action, result)
□ Correlation IDs propagated across all services
□ Tenant isolation — tenant_id on every event
□ No PII in event payloads — IDs only, no names/emails/content
□ Timestamps in UTC ISO 8601 with milliseconds
□ Severity levels used consistently

Storage & Integrity (8 items)

□ Audit logs stored separately from application database
□ Write-once / append-only storage enforced
□ Application credentials cannot delete audit entries
□ Tamper detection mechanism in place (hash chain, signing, Object Lock)
□ Cross-account or cross-system log destination configured
□ Encryption at rest enabled for all log storage tiers
□ Encryption in transit for all log forwarding
□ Log access itself is logged (meta-auditing)

Retention & Lifecycle (7 items)

□ Hot tier retention defined and automated (searchable, <90d)
□ Warm tier retention defined and automated (retrievable, <1yr)
□ Cold tier retention meets regulatory minimum (6yr+ for HIPAA)
□ Legal hold mechanism exists and has been tested
□ Automated deletion after retention expiry (GDPR compliance)
□ Lifecycle policy is version-controlled
□ Cost monitoring on log storage

SIEM & Alerting (6 items)

□ All audit events forwarded to SIEM
□ No events dropped in forwarding pipeline (verified by count)
□ Latency from emission to SIEM ingestion < 5 minutes
□ Alert rules configured for critical security events
□ Dashboards exist for auth, data access, admin, anomalies
□ Alert escalation path defined and tested

Compliance & Process (5 items)

□ Findings mapped to specific regulatory controls
□ Daily automated review of critical alerts
□ Weekly manual review of admin and data access patterns
□ Monthly compliance review with evidence retention
□ Quarterly comprehensive audit log health report

---

Report Template

## Audit Logging Review Report

Scope
System reviewed: [application name]
Date: [date]
Reviewer: [name/role]
Regulations in scope: [HIPAA, PCI-DSS, SOC 2, GDPR]

Executive Summary
Event taxonomy coverage: X/46 event types logged
Schema compliance: [PASS/FAIL] — N issues found
Storage immutability: [PASS/FAIL] — logs [are/are not] tamper-proof
Retention compliance: [PASS/FAIL] — N tiers configured
SIEM integration: [PASS/FAIL] — forwarding [active/missing]
PII in logs: [PASS/FAIL] — N instances of PII found

Findings by Severity

CRITICAL — Fix Before Next Audit
#
Finding
Regulation
Impact
Remediation
1
[description]
[control ref]
[what happens if not fixed]
[how to fix]

HIGH — Fix Within 30 Days
[same format]

MEDIUM — Fix Within 90 Days
[same format]

LOW — Track and Plan
[same format]

Event Coverage Gap Analysis
Event Category
Expected
Logged
Missing
Gap %
Authentication
13
?
?
?%
Authorization
6
?
?
?%
Data Access
5
?
?
?%
Data Modification
5
?
?
?%
Admin Actions
8
?
?
?%
System Events
5
?
?
?%
Compliance
4
?
?
?%

Retention Status
Tier
Policy
Actual
Compliant
Regulation
Hot
90 days
?
?
PCI 10.7
Warm
1 year
?
?
PCI 10.7
Cold
6 years
?
?
HIPAA §164.530(j)

Recommendations
[prioritized list of improvements with effort estimates]

---

Tips for Best Results

• Start with the taxonomy table — Walk through all 46 event types against the codebase. This single exercise finds 80% of gaps. Missing events cannot be retroactively reconstructed.
• Test immutability, don't trust configuration — Attempt to delete or modify a log entry using application credentials. If it succeeds, the immutability claim is invalid regardless of what the architecture diagram says.
• Follow one request end-to-end — Pick a real request ID from production logs and trace it through every service. If the chain breaks, correlation is incomplete. Auditors and investigators do exactly this.
• Check the failure paths — Most logging implementations cover the happy path. Check what happens when the database is down, when the log pipeline is full, when the SIEM is unreachable. Failed log delivery must be detectable.
• Grep for PII in log output, not log code — Developers log req.user thinking it only has an ID, but it might include name, email, and role. Check actual log output, not just the logging statements.
• Map every finding to a regulation — A finding without a regulatory reference is a suggestion. A finding mapped to HIPAA §164.312(b) is an audit deficiency. Compliance teams and auditors prioritize mapped findings.
• Verify retention with actual data — Check that 1-year-old logs are actually retrievable. Check that 7-year-old logs exist in the archive tier. Policy documents mean nothing if the lifecycle automation never ran.
• Review who reviews the logs — Logging without review is theater. Ask to see evidence of the last three monthly reviews. If they don't exist, the review process itself is a finding.
• Check log volume economics — A system logging 10 GB/day at hot-tier pricing for 6 years costs differently than one with proper tiering. Unsustainable costs lead to premature deletion, which is a compliance violation.
• Audit the auditors — Who has access to audit logs? Is that access itself logged? An insider who can read and delete audit trails is the most dangerous threat. Access to logs must be tightly controlled and monitored.