Audit logging: do's and don'ts
Updated 2026-05-07
Audit logging is unsexy and load-bearing. The teams that get it right when they don't have to are the teams who don't scramble during their first security incident or first SOC 2 audit. The do's and don'ts here are the floor; specific industries (healthcare, finance, public sector) layer on additional requirements.
Do
Log every authentication event with timestamp, IP, user-agent, and outcome
Authentication audit is the first thing forensics looks at when account compromise happens. Without per-event records you cannot answer 'when did the attacker first authenticate' or 'from where.'
SOC 2 Type II, ISO 27001, HIPAA, and PCI DSS all require authentication audit. The schema is canonical: timestamp (ISO 8601, UTC), user_id, event_type (login_success, login_failure, mfa_challenge, mfa_success, etc.), IP, user-agent, outcome.
Log every change to auth factors with before-and-after state
Factor changes are the highest-stakes audit events, they're how attackers persist after takeover. Logging the before-and-after state lets the user (or the security team) see what actually changed.
Best practice in NIST SP 800-92 (Guide to Computer Security Log Management) and broadly required by enterprise security questionnaires. Real production incident responses have caught factor-change-driven takeovers from this audit trail alone.
Make audit logs queryable per Organization for B2B SaaS
B2B customers need to audit their own users' activity for their own compliance and incident response. Per-Organization audit log access is a standard B2B SaaS feature, the customer's security team queries their own data without seeing other customers.
Required by enterprise B2B contracts above ~$50k/year in 2026. Most B2B-mature CIAM ship per-Org audit access; the vendors that don't lose deals at the security questionnaire stage.
Retain authentication audit logs for at least 90 days, ideally 365
Most ATO incidents are detected days to weeks after they occur. 30-day retention often misses the original compromise. 90 days is the practical floor; 365 days covers most regulatory minima.
PCI DSS requires 365 days. HIPAA recommends 6 years for protected health information. SOC 2 typically requires 12 months. Default to 365 days for the auth surface unless storage cost is a binding constraint.
Stream audit events to a SIEM (or equivalent) for correlation
Auth events alone tell part of the story; correlating with application events, network events, and data-access events tells the rest. A SIEM (Splunk, Sentinel, Elastic, Sumo Logic, Datadog) lets the security team build detection rules across signal sources.
Modern CIAM ships log streaming to the major SIEM destinations (Auth0 Log Streams, Okta System Log, AWS CloudTrail integration). The customer's security operations team is the consumer, not the SaaS engineering team.
Don't
Don't log passwords, password hashes, secrets, or full session tokens
Audit logs become an attack surface if they contain the credentials they're auditing. Logs are read by more eyes (operators, support, compliance) than the credentials themselves; treating logs as secret-grade containers defeats their purpose.
OWASP Logging Cheat Sheet and PCI DSS both explicitly forbid sensitive credentials in logs. Documented production incidents have traced to credentials accidentally logged in error stack traces or request dumps.
Don't log full PII payloads if you can log identifiers
Per-event PII multiplies the GDPR / CCPA surface unnecessarily. Logging the user_id and event_type is enough for forensics; logging full profile data on every event is overcollection.
Data minimization is a core GDPR principle. Audit logs are explicit examples in EDPB guidance, they should contain identifiers and event metadata, not the full data state of the user record on every event.
Don't allow admins to delete audit log entries
An admin who can delete audit entries can hide their own compromise. Audit logs should be append-only at the storage layer; deletion (for retention) should be policy-driven, time-based, and itself audited.
Standard audit-log immutability requirement in SOC 2, PCI DSS, and most regulated frameworks. Production audit stores use write-once storage (S3 with object lock, Splunk frozen indexes, immutable append-only databases).
Don't rely on application-layer logging alone for auth events
Application layer logs are subject to the application's bugs, deployment cycles, and uptime. Auth audit should originate at the CIAM layer (the source of truth) and be reliable independent of application state.
Documented incidents where application logs were corrupted or unavailable during the actual compromise window, the CIAM-layer audit was the only surviving evidence.