Audit Logs for SaaS: What to Track and How to Build Them

Audit logs are one of those features that nobody thinks about until they need them — at which point they need them urgently and they don't exist. An enterprise customer asks for a log of all admin actions taken on their account. A SOC 2 auditor asks for evidence of access controls and change tracking. A customer escalates because something changed in their account and they don't know what. In every one of these scenarios, the absence of audit logging is painful.

The good news: audit logging isn't complicated to build. The challenge is building it comprehensively from the start, with a data structure that's queryable and a surface that makes the logs accessible to the people who need them — not just engineers with database access.

What events to track

There are two categories of audit events that matter for most SaaS companies.

The first is customer-facing events — actions taken within the product that affect account data, user access, or configuration. These are the events your customers want to see: who invited a new user, who changed the account plan, who deleted a record, who modified a shared configuration. This is the audit log your enterprise customers will ask for in their security review.

The second is internal team events — actions taken by your ops, support, and admin teams through your internal tools. Who accessed a customer account, who applied a credit, who changed a subscription, who used impersonation to view a user's account. This is the audit log your compliance team and your engineers need.

Both categories should be tracked from day one, but they serve different audiences and may be stored and surfaced differently.

The data structure that makes logs useful

An audit log entry needs to capture: who did the action (user ID, email, and whether it was a customer or internal team member), what action was taken (structured event type, not a free-text description), what was affected (the entity type and ID — account, user, subscription, etc.), when it happened (timestamp, with timezone), the before and after state of what changed, and the source (the product UI, your admin panel, the API, an automated job).

The most common mistake in audit log implementation is storing events as unstructured log messages. "User admin@company.com changed subscription for account 12345" is useful for humans reading a log file but terrible for querying, filtering, or building a UI on top of. Structured event types with consistent fields make the data queryable and allow you to build a meaningful audit log surface.

Retention and access

Audit log data should be retained for at least 12 months for most SaaS companies, and 24+ months if you're pursuing SOC 2 Type II or serving regulated industries. Storing audit events in your primary operational database works at small scale; at larger volumes, a dedicated append-only store (a separate database table, or an event streaming system like Kafka with a retention sink) is more appropriate.

Access to audit logs needs to match the sensitivity of what's being logged. Internal team action logs should be accessible to your ops and compliance teams through your admin panel, not just to engineers. Customer-facing audit logs should be surfaced in the product for account admins. Building the access layer — queryable, filterable, exportable — is usually more work than the underlying event capture.

Making it queryable for your ops team

The thing that makes audit logs operationally useful isn't the logging itself — it's the query surface. Your ops team needs to be able to answer questions like: what changes were made to account X in the last 30 days? Which admin actions did team member Y take this week? Which accounts had subscription changes applied by the system (not a user) in the last month?

A simple filter-and-search UI on top of your audit log — filterable by event type, actor, affected entity, and date range — handles 90% of operational queries without engineering involvement. This is worth building as part of your admin panel, not as an afterthought.

The SOC 2 connection

If your company is pursuing SOC 2 compliance, audit logging is a direct requirement. The SOC 2 Trust Services Criteria require evidence of: logical access controls (who has access to what), change management (who changed what, and when), and monitoring (that you can detect and review unusual activity). Comprehensive audit logging with a queryable surface addresses all three. Companies that add audit logging retroactively for a SOC 2 audit spend significantly more time and money than those that build it in from the start.