Compliance requires knowing who did what and when.

Audit logs answer the question: "Who did this, when, and from where?"

This question matters in multiple contexts:

SOC 2 compliance. SOC 2 Type II auditors review whether the organization has controls over data access. Audit logs demonstrate that access to sensitive data is logged and reviewable.

HIPAA. The HIPAA Security Rule requires audit controls: hardware, software, and procedural mechanisms that record and examine activity in information systems that contain ePHI.

Enterprise customer requirements. Larger customers ask during sales due diligence: "Can we see a log of who accessed our data?" Without audit logs, the answer is no.

Incident investigation. When something goes wrong (unauthorized access, data modification), audit logs provide the investigation trail.

The audit log data model:

audit_events {
  id
  tenant_id
  user_id
  action (create | read | update | delete)
  resource_type (user | document | payment)
  resource_id
  changes (JSON diff of before/after for updates)
  ip_address
  user_agent
  created_at
}

Implementation considerations:

Tamper-resistance. Audit logs should be append-only — no updates or deletes. Application users should not be able to modify or delete audit records.

Performance. Writing an audit event on every action adds latency. Async logging (fire-and-forget to a queue) keeps the main request fast.

Retention. SOC 2 typically requires 1 year. HIPAA: 6 years. Configure retention policies accordingly.

Queryable. Administrators need to search by user, date range, action type, and resource. Index the relevant columns.