Audit Logs Are a Product Feature, Not a Compliance Chore
Every enterprise buyer asks for audit logs. Most SaaS treat them as an afterthought and pay for it during procurement.
Audit logs come up in every enterprise security questionnaire. Most SaaS treat them as a compliance chore — ship them just before an audit, hide them in a dropdown, and move on. Buyers notice. Well-designed audit logs are a product feature that reduces churn and shortens sales cycles. This is what we build for clients scoping enterprise readiness.
The pattern below covers what to log, where to store it, and how to surface it in a way that makes procurement teams say yes faster.
What audit logs are actually for
Three overlapping jobs:
- Compliance evidence — SOC 2, HIPAA, ISO 27001 all require some form of access and change logging.
- Security investigation — when something goes wrong, the audit log is how you reconstruct what happened.
- Customer-facing accountability — enterprise buyers want their own admins to see what their users are doing.
The third job is the one most SaaS underinvest in. A log that only compliance auditors see is a cost center. A log the customer's admin can filter, export, and set alerts on is a paid feature.
What every audit log entry needs
The minimum fields we ship in every project:
- Actor — user ID, email, and role at the time of the action.
- Actor type — user, admin, system, or API key. Different colors in the UI.
- Action — a stable, machine-readable name like
user.role_changed, not human prose. - Target — the resource affected. Include type, ID, and human-readable name at time of action.
- Metadata — before and after values for changes, or additional context for reads.
- Timestamp — always UTC, always with millisecond precision.
- IP address and user agent — for security review.
- Workspace or tenant ID — so multi-tenant filtering is fast.
- Session or request ID — links back to your app logs when investigating.
Missing any of these usually shows up as a gap during the first security review. Adding them retroactively is possible but painful — the old entries won't have the field.
What to log — and what not to
The trap is logging everything and drowning in noise. The trap on the other side is logging too little and failing audits.
Always log
- Authentication events — login, logout, failed login, password reset, MFA changes.
- Authorization changes — role changes, permission grants, workspace invites accepted.
- Sensitive data access — viewing PII, exporting data, running reports.
- Sensitive data changes — CRUD on customer records, financial data, configuration.
- Integration events — API key creation, webhook config changes, OAuth grants.
- Admin actions — anything a customer's admin does that affects other users.
- Impersonation — both start and end of every impersonated session.
Usually skip
- Read events on non-sensitive data — logging every page view drowns the useful signal.
- System heartbeats — belong in application logs, not audit logs.
- UI events like button clicks — these are product analytics, not audit.
The rule of thumb: if a customer's admin might reasonably ask "who did X and when?", it needs to be in the audit log. Everything else is noise.
Storage — the immutability question
Audit logs need to be append-only. That's the whole point. If they can be edited, they're not trustworthy evidence.
Application-level immutability
Simplest pattern. A dedicated audit_events table, no update or delete permissions granted at the database level to the application user. Only inserts. Writes happen through a function that enforces the schema.
This is enough for SOC 2 Type II in almost every case. Auditors want to see that the design intent is immutability and that access is restricted.
External immutable storage
For higher-assurance requirements — HIPAA, financial services, government — mirror audit logs to a write-once storage tier. S3 Object Lock with governance mode, or a dedicated service like Vanta's audit trail. Original stays in Postgres for fast querying; the mirror is the tamper-evident source of truth.
Retention
SOC 2 typically expects 1 year. HIPAA expects 6 years. Financial services often 7. Talk to your auditor before designing retention. Building for the longest requirement you might ever hit is cheaper than migrating later.
Surfacing audit logs to customers
The part most SaaS get wrong. A compliance-driven audit log is a search box and a table. A product-driven audit log is a feature customers use weekly.
Filter by actor, action, target, and time
The minimum useful set. If a customer's admin can only search by date, they can't investigate anything real.
Export to CSV or JSON
Every enterprise buyer will ask for this in their first month. Do it once, expose it in the UI, move on.
Filtering by workspace or team
Multi-tenant hygiene. Admins should only see their own tenant's events. Never trust a query parameter for tenant scoping — enforce it server-side.
Alerts on high-risk actions
Optional but powerful. Let admins configure alerts for events like "role changed to admin," "API key created," or "bulk data exported." Sends an email or Slack message. Turns your audit log into a security tool.
SIEM export
Enterprise buyers often want audit events streamed to their SIEM — Splunk, Datadog, Panther. Support at least one export format (usually CEF or JSON to an S3 bucket) and you'll unlock deals you'd otherwise lose.
Performance and scale
Audit logs grow fast. A busy multi-tenant SaaS can write millions of events a day. The table gets big and slow.
Partition by month
Postgres declarative partitioning by month works well. Queries scoped to a time range hit only relevant partitions. Old partitions are cheap to detach and archive.
Index for the query patterns you have
The common ones: (tenant_id, timestamp DESC) for the default view, (tenant_id, actor_id, timestamp DESC) for actor drilldowns. Don't index every field — indexes on high-write tables are expensive.
Async write path
For high-volume events, write to a queue and let a worker persist. Never let audit log writes block the user's request. The queue also gives you resilience — a database blip won't lose events.
Common mistakes
Storing logs in the same table as app data. Mixing audit events with app rows makes queries slow and immutability hard to enforce. Separate table, always.
Free-text action names. "User John changed billing" is impossible to filter. Use stable machine-readable names — user.billing_updated — and render the human-readable version at display time.
Skipping tenant scoping. A customer's admin should never see another tenant's events. Enforce this in the query layer, not the UI.
Logging PII directly. If your audit log contains full email addresses, credit card numbers, or health data, it inherits every data protection obligation of the source. Consider whether metadata pointers are enough instead of raw values.
No retention policy. Logs grow forever, storage costs climb, and queries slow down. Pick a retention window and enforce it.
Trade-offs
Audit logs add write load to every sensitive operation. On a hot code path, they can double the write count. Async writes solve most of it; the ones that must be synchronous are usually the ones you most want to log.
Rich metadata also has a cost. Storing the "before" and "after" state of every change roughly doubles storage vs storing the diff. For most SaaS the storage is negligible compared to the debugging value.
Common misconceptions
"Audit logs are a compliance-only feature." They're a product feature. Enterprise buyers evaluate them. Bad audit UX loses deals.
"Application logs are audit logs." They aren't. Application logs are for engineers debugging behavior. Audit logs are for humans reconstructing decisions. Different fields, different retention, different consumers.
"We can add audit logs before our SOC 2 audit." You can, but retroactive logging means all your historical events don't exist. Auditors ask for evidence over time. Start early.
Frequently asked questions
Final take
Audit logs are one of the highest ROI features enterprise-facing SaaS can ship, and one of the most underinvested. Design them for the customer's admin, not just the auditor. Ship the search, filter, export, and alert flows. Store them append-only in a dedicated table with sensible retention. Do that, and your next security questionnaire gets easier every quarter.
If you're scoping audit logs for an enterprise-facing product, book a call. We've built this feature into a lot of products and the pattern is stable enough that we can review a design in an hour.
FAQ
Frequently asked questions
What's the difference between audit logs and application logs?+
Application logs record what the system did — HTTP status codes, database queries, errors — for engineers debugging behavior. Audit logs record what humans and integrations did — who changed what, when, and why. Different retention, different structure, different consumers. Don't try to serve both with one table.
Do audit logs need to be encrypted at rest?+
Yes, and almost every managed database does this by default. The bigger concern is who can query them — even with encryption, an over-permissive access policy is a data leak waiting to happen. Restrict read access to the audit table and log every query against it if you're really strict.
How long should audit logs be retained?+
Depends on the framework. SOC 2 typically expects 1 year of retained evidence. HIPAA expects 6. Financial services often 7. If you don't know yet, plan for the longest requirement you might hit — retroactively extending retention is impossible for events that have already been deleted.
Should I use a managed audit log service?+
Managed services like Vanta's audit trail or dedicated products from newer companies exist and are fine for the compliance evidence layer. Most SaaS still build the customer-facing side in-house because it's tightly coupled to the product. A common pattern is to write once, mirror to a managed service for immutability, and query in-house for UX.
Do audit logs need to include IP address and user agent?+
For security-review purposes, yes — they help distinguish legitimate access from account takeover. Some jurisdictions treat IP address as personal data (GDPR), so include it deliberately and disclose it in your privacy policy. User agent is safer and always useful.
Building something similar?
Let's talk in 30 minutes.