The audit log is the immutable record of everything that happened in your tenant. Every sign-in, every admin operation, every configuration change, every security event. Append-only; queryable in the console; exportable; streamable.
What's audited
Section titled “What's audited”In short: actions that change state, fail to change state, or have security implications.
Some examples by family:
- Authentication — sign-in success, sign-in failure, sign-out, session revocation, MFA challenge succeeded / failed.
- User lifecycle — create, update, disable, enable, delete, password reset.
- Admin operations — application config changes, federation connection edits, role assignments, flow / action changes, branding edits.
- Security — brute-force detection, refresh-token reuse detection, breach incident matches, threat-feed hits.
- Policy changes — authentication policy, password policy, MFA enforcement changes.
Not audited (would create noise without value):
- Individual API calls authenticated against an already-issued token (those would multiply 100×).
- Internal platform housekeeping (token rotation, cache eviction, etc.).
- Things that affected no state (a sign-in attempt that didn't even reach the credential check, e.g., a malformed request).
Properties
Section titled “Properties”Every entry has:
id— opaque event id.type— closed taxonomy (user.signed_in,application.created, etc.). See Event schema.occurred_at— ISO timestamp at platform precision.actor— who did it. User / admin / system / application.target— what was acted on. User / session / application / etc.outcome—success/failure/denied/partial.data— type-specific fields with the operation's details.context— IP, user agent, fingerprint signal, request id, geolocation.
Read the audit log
Section titled “Read the audit log”Audit → Read logs. A queryable table view. See Read the audit log.
For real-time monitoring, the Dashboard's recent-activity tile surfaces the last 20 admin-interesting events. For long-form investigation, the full audit surface is the answer.
Export
Section titled “Export”Bulk-export audit entries for compliance evidence, vendor evaluation, or your own archive. See Export.
Streaming
Section titled “Streaming”For long-term retention / centralised security monitoring, stream audit events to your own destination — webhook, Splunk, Datadog, Elastic. See Stream to a destination.
Retention
Section titled “Retention”The platform retains audit entries for a configurable window:
- Default: 365 days.
- Configurable in Settings → Audit policy → Retention. Up to the maximum your plan allows.
After retention expires, entries are permanently dropped from the audit feed. If you need longer, stream to your own archive.
Compliance use
Section titled “Compliance use”Common audit-use scenarios:
- SOC 2 — auditors ask "show me all admin actions in <quarter>". Export with that filter.
- GDPR / DPIA — "show me data-deletion events for this user". Filter on
target_id = usr_Xand event-types matchinguser.deletedor*.erasure_*. - Incident investigation — "what happened between 14:00 and 16:00 that triggered the alert?" Filter by time + outcome.
- Internal review — "who changed the authentication policy in the last quarter?" Filter by event-type
admin.policy_updated.
What audit can't tell you
Section titled “What audit can't tell you”- What's in a user's profile right now. The user record's current state is in the Users surface. Audit is the history of how it got there.
- Whether a webhook receiver successfully processed an event. Audit records the platform-side fire; your receiver's processing is your code's concern. (Some platforms include receiver-confirm callbacks; IntelliAuth doesn't today.)
Per-tenant scope
Section titled “Per-tenant scope”Audit is tenant-scoped. Events in production-cymmetri don't show up in staging-cymmetri. For cross-tenant audit (the platform admin view), the IntelliAuth admin console has its own audit surface — see CP admin audit.