What is the Audit Logging pattern and what events should always be captured?

Audit Logging records a tamper-evident, chronological trail of who performed what action on which resource and when. It is distinct from application or debug logging: application logs record technical events (exceptions, slow queries, service calls) for operational troubleshooting; audit logs record business-level events for compliance, forensics, and accountability — and must be retained even when the original data is deleted.

Events that should always be captured:

• Authentication events — successful logins, failed login attempts, logouts, and token refresh operations. Essential for detecting credential-stuffing attacks and session anomalies.
• Authorisation decisions — both grants and denials. A denied access attempt to a sensitive endpoint may indicate a privilege-escalation attempt.
• Privileged record reads — when a user or service reads personally identifiable information (PII), financial records, or health data. Required by GDPR, HIPAA, and PCI-DSS.
• Create, Update, Delete on critical entities — changes to user accounts, payment methods, configuration, permissions, and order state.
• Administrative actions — role assignments, system configuration changes, secret rotation, and feature flag toggles.

Key properties of a well-designed audit log:

• Immutability — audit records must not be deletable or modifiable after writing. Use append-only stores (AWS CloudTrail, Kafka with infinite retention, an WORM-locked S3 bucket).
• Attribution — every entry must record the identity of the actor (user ID, service principal, IP address) and the target resource.
• Tamper detection — hash chaining or cryptographic signing of records allows detection of modifications.
• Separation from application logs — audit logs should flow through a separate pipeline with stricter retention policies and access controls.