Audit Logs for SaaS: Design, Retention, and Export

Audit logs record every meaningful action taken in your app.

Audit Logs: The Enterprise Feature That Closes Compliance-Driven Deals

Audit logs record the who/what/when/where of every meaningful action in your product: user X changed permission Y at time Z from IP W. They're a compliance and security requirement (SOC 2 requires them; HIPAA and PCI DSS effectively require them) and a genuine forensic tool when incidents happen. Enterprise buyers will ask about audit logs during security review — companies without them either lose the deal or ship them under contractual pressure in a rushed sprint.

What events to log

Standard event catalog: (1) Auth events — login success/failure, logout, session expiry, MFA challenges. (2) User management — invite, role change, deactivation. (3) Admin actions — settings changes, integration configuration. (4) Data access — reads of sensitive data (patient records, financial data). (5) Data modification — significant creates, updates, deletes. Skip: routine reads of non-sensitive data (audit-logging every page view creates unusable noise).

The standard schema

Every audit event should carry: (a) timestamp (ISO 8601, UTC), (b) actor (user ID + display name + type: human/API key/system), (c) action (verb, from a controlled vocabulary), (d) target (object type + ID + display name), (e) before/after values for changes, (f) source IP and user agent, (g) session/request ID for correlation, (h) result (success/failure + reason). Consistency across event types is what makes logs searchable and useful.

Retention and immutability

Retention: 1 year minimum for SOC 2, 6+ years for HIPAA, 7+ years for financial data. Immutability: audit logs must be write-once — a compromised admin should not be able to delete their tracks. Use append-only storage or write to a separate audit-only database with restricted permissions. Better: stream to an external SIEM (Splunk, Datadog, Panther) so tampering with your database doesn't erase the record.

Customer-facing audit log UX

Enterprise customers want to see their own audit logs, not just yours. Ship an in-product audit log viewer at Enterprise tier: filterable by user, event type, and date range; exportable as CSV/JSON; API-accessible for streaming to their SIEM. Streaming-to-SIEM (Panther, Splunk, Datadog via webhook/API) is what large enterprises actually need — a UI is a starting point but insufficient at scale.

Common failure modes

(a) Logging inconsistently — some code paths log, others don't; auditor spot-checks find gaps. (b) Logging in the application server only — if the server is compromised, logs can be edited. (c) Bloating logs with routine reads that never get queried. (d) Missing before/after values for changes, making forensic investigation impossible. (e) No retention policy — logs from 3 years ago still stored in hot storage costing $$$.

Frequently asked questions

When do we need to build audit logs?
Before your first SOC 2 audit, before your first enterprise security questionnaire, or before shipping features that handle regulated data. Deferring past those milestones creates painful retrofit work.
Should we build or use a service?
Services like WorkOS Audit Logs, Vanta's audit tooling, and Panther streamline the storage/retention/export side. Application-level event capture is still yours to build. For most companies, hybrid — build capture, buy storage and viewer — is fastest.
Do audit logs belong on the free tier?
Basic audit visibility (recent activity for the customer's own admin) is reasonable at Team tier. Full audit log export, long retention, and SIEM streaming are standard Enterprise-tier features.

Related fundraising guides (40)

Investor directory · Fundraising library · Articles A–Z · Company funding database