A customer facing audit log should let an account admin answer who did what, to which object, when, and from where, within their own tenant. Include sign ins, permission changes, data exports and settings edits. Make entries immutable, filterable and exportable, and keep other tenants' data and internal secrets out.
Internal logs versus customer audit logs
Your internal logs serve engineers. A customer audit log serves the customer's security team, their auditors and their support staff. It has a narrower scope and a stricter promise: entries are accurate, ordered and not editable by the people being audited.
Buyers increasingly ask for it in security reviews. If you do not have one, a basic version is often the quickest way to answer a common questionnaire item.
Events to include
The OWASP Logging Cheat Sheet's higher risk functionality list is a good source of events: user and privilege administration, admin actions, access to sensitive data, encryption and key activities, data import and export, and configuration changes. Translate each into something a customer understands.
| Category | Example entries |
|---|---|
| Authentication | Sign in, failed sign in, MFA enabled or removed, SSO settings changed |
| Users and roles | Member invited, removed, role changed |
| Access to data | Record exported, report downloaded, share link created |
| Credentials | API key created, rotated or revoked (key ID only) |
| Settings | Retention, domain, security policy changes with before and after |
| Support access | Vendor staff access to the account, with reason and time |
Showing your own staff's access to the tenant builds trust. Customers tend to notice whether it is there.
Fields per entry
- Timestamp in UTC, with a stable sort order for entries in the same second.
- Actor: user, API key ID or system, with display name and ID.
- Action in a short, stable verb phrase.
- Target object type and ID.
- Outcome: success or failure.
- Source IP and user agent, mindful that IPs can be personal data. See is an IP address personal data.
- Before and after values for settings, where safe.
- A unique event ID, useful in support tickets.
Design decisions
Keep it append only, with integrity controls such as append only tables, as OWASP Top 10 A09 suggests for high value transactions. Do not let customer admins delete entries. If a customer needs removal for a legal reason, handle it as a controlled support process.
Provide filters by actor, action, object and date, and an export in a common format such as JSON or CSV. An API makes it easy for customers to feed their own monitoring.
Choose a retention period that you can state publicly, and keep your promise. If retention differs by plan, say so clearly on the pricing or docs page.
Never include secrets, full request bodies or other tenants' identifiers.
Common gaps
Missing read events, since teams log writes only. No entry for the audit log's own export. Entries for system actions without a clear actor. Time zones that differ across the UI and the export.
Quick check
Should customers see failed actions?
Yes for sign in and permission failures, since they are useful for spotting attacks. Mark them clearly as failures.
Is an audit log the same as an activity feed?
No. A feed is for convenience and can be edited or trimmed. An audit log is a record you promise not to alter.
Safeguard's compliance and evidence automation helps teams assemble proof for buyer reviews. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
