Audit Logging

An employee at a healthcare company accesses a celebrity patient's medical record. The media publishes details from that record. The hospital faces a HIPAA investigation. Regulators ask: "Who accessed this record, when, from what device, and what did they view?"

If the hospital has proper audit logging, they can answer in minutes. The log shows: Employee X accessed Patient Y's record at 2:47 PM from IP 10.0.3.14. They viewed diagnosis, medications, and treatment plan. Access was not justified by their role or any active care relationship.

If the hospital doesn't have audit logs, they can't prove anything. The investigation drags on. The fine is larger. The reputational damage is worse.

Audit logging records every significant action in your system: who did what, to what resource, when, from where, and whether it succeeded. It's not optional for regulated industries (healthcare, finance, government). And even for unregulated businesses, audit logs are the first thing you reach for during a security incident, a customer dispute, or a production debugging session where you need to know exactly what sequence of actions led to the current state.

Every audit log entry should capture seven fields:

What to audit:

• Authentication events (login, logout, failed login, password change, MFA enrollment)
• Authorization changes (role assignment, permission grants, API key creation)
• Data access (reading sensitive records, healthcare data, financial records)
• Data modifications (create, update, delete of any business object)
• Admin actions (user management, configuration changes, feature flag toggles)
• Security events (IP allowlist changes, CORS policy updates, firewall rule changes)

AWS CloudTrail captures about 40 event types per service. Stripe logs every API call with the requesting API key, IP, and idempotency key. Your audit surface should be at least this thorough.