SaaS Audit Logging: Designing Evidence Trails for Enterprise Customers
How to design audit logs for a B2B SaaS product: which events to record, event schema, tamper evidence, retention, customer access, exports and SIEM streaming.
What should SaaS audit logging include?
A SaaS audit log should record security-relevant and business-critical actions as structured events (actor, action, target, tenant, time, source and outcome), write them append-only to tamper-evident storage, keep them for a defined retention period, and give customer admins search, export, an API and SIEM streaming, scoped to their tenant. Enterprise buyers ask for it in security reviews because it lets them investigate incidents and show control over who did what.
This guide is for product and engineering leads at B2B SaaS companies selling to larger customers.
Key takeaways
- Separate audit events from application debug logs.
- Use one structured schema for every event.
- Record failures as well as successes for security events.
- Make storage append-only and tamper-evident.
- Give customers search, export, API and streaming.
- Treat logs as personal data: minimise and set retention.
Which events to record
| Category | Examples |
|---|---|
| Authentication | Sign-in success and failure, MFA changes, SSO configuration, session revocation |
| Users and access | Invitations, role changes, permission grants, SCIM provisioning and deprovisioning |
| Security settings | IP allow lists, password policy, API keys and tokens created or revoked |
| Data access and export | Exports, bulk downloads, viewing sensitive records, report sharing |
| Configuration | Workflow, integration and webhook changes; feature settings |
| Data changes | Create, update and delete of important records, with before and after values where appropriate |
| Support access | Vendor staff impersonation or support sessions, with reason and approval |
Event schema
Use one schema for every event so customers can search and stream consistently. The OWASP Logging Cheat Sheet covers which attributes to record and what to exclude.
{
"id": "evt_01J9X4",
"tenantId": "org_482",
"occurredAt": "2026-10-10T09:41:12Z",
"actor": { "type": "user", "id": "usr_77", "email": "a.patel@example.com" },
"action": "role.assigned",
"target": { "type": "user", "id": "usr_91" },
"changes": { "role": { "from": "member", "to": "admin" } },
"context": { "ip": "203.0.113.10", "userAgent": "Mozilla/5.0", "requestId": "req_9f2" },
"outcome": "success"
}Integrity, storage and retention
- Write audit events in the same transaction as the change, or through an outbox, so none are lost.
- Store append-only; restrict deletion to a retention process.
- Use write-once storage such as S3 Object Lock for archives.
- Consider hash chaining per tenant to detect gaps or edits.
- Synchronise clocks and record times in UTC.
- Exclude secrets, passwords and full payment data; minimise personal data.
- Define retention per plan and document it.
Customer access
Enterprise customers expect to use audit data in their own tools. Provide an admin view with filters by actor, action, target and date; CSV or JSON export; an API with pagination; and streaming to SIEM tools via webhooks or cloud storage delivery. Scope everything by tenant, restrict access to admin roles, and log access to the audit log itself. For tenant isolation patterns, see multi-tenant SaaS architecture.
Hypothetical example: a B2B HR platform
This example is hypothetical. An HR SaaS company kept a free-text activity feed that failed several enterprise security reviews. It defined 60 audit event types, added a common schema, wrote events through an outbox from the same database transactions, archived them to write-once storage, and built an admin audit view with export and a streaming option for enterprise plans. Security questionnaires became easier to answer with documented retention and examples.
Common mistakes
- Treating debug logs as audit logs.
- Free-text messages instead of structured events.
- Recording only successful actions.
- Logging secrets or full personal data.
- No customer access, so support exports logs by hand.
- Audit events lost when a background job fails.
Sources
OWASP Logging Cheat Sheet; NIST SP 800-92: Guide to Computer Security Log Management; AWS S3 Object Lock.
Accessed 10 October 2026.
Conclusion
Good audit logging is a product feature: complete structured events, tamper-evident storage, clear retention and customer access through search, export and streaming. Build it before enterprise security reviews ask for it. For permissions and access lifecycle, see SaaS roles and permissions and joiner-mover-leaver automation.
Enterprise security reviews asking for audit logs?
ZSpace Labs is a remote-first technology studio that works with clients globally on SaaS engineering and security features. If it would help to design your audit event model and customer access, we are happy to talk it through.
Common questions.
Application logs help engineers debug and are often sampled, verbose and short-lived. Audit logs record who did what, to which resource, when and from where, for accountability and investigation, and need completeness, integrity and defined retention.