The audit log events enterprise buyers will actually ask about

Most B2B SaaS teams find out what belongs in an audit log the hard way: a security questionnaire comes back with a specific ask, engineering scrambles to add one more event type, and the deal slips a week while it gets built. The list below is an attempt to get ahead of that. These are the ten event categories that come up most often once a company has more than a handful of enterprise customers, in roughly the order a security reviewer tends to ask about them.

1. Authentication, both success and failure

The obvious one, and also the one teams get partially wrong. Logging successful logins is easy. What gets missed is failed attempts, which matter more for security investigations: repeated failures from one account, one IP hitting many accounts, or a login succeeding from a location that doesn't match the user's usual pattern. Include the method (password, SSO, magic link) since a mix of methods on one account is itself worth flagging.

2. MFA enrollment, challenges, and resets

An MFA reset is one of the highest value events an attacker can trigger, since it's often the step right before an account takeover. Log enrollment, every challenge (not just failures), and resets separately from ordinary logins, and keep enough context to show who initiated the reset, whether it was the user or an admin acting on their behalf.

3. Session and token lifecycle

Issuance, refresh, and revocation of sessions and long lived tokens, including what triggered the revocation. This is the category that answers "can you actually cut this person off right now," which is a question every enterprise security team eventually asks, usually right after an offboarding.

4. Administrative role and permission changes

Every time someone's role or permission set changes, log who changed it, what the role was before, and what it became. This is the event type most often missing entirely from a first pass at audit logging, and it's frequently the very first thing a security reviewer asks for, since privilege escalation is the pattern they're most worried about.

5. Provisioning and deprovisioning through the directory

Every SCIM create, update, deactivate, and delete, logged as distinct event types rather than folded into a generic "user changed" bucket. A directory sync running quietly in the background is exactly the kind of thing that needs its own trail, since it's automated and easy to assume it's working correctly without checking.

6. API key and service credential lifecycle

Creation, scope, last use, rotation, and revocation for every long lived credential your platform issues. A key that's never been rotated is a finding in almost every audit, and a key with broader scope than its actual usage is the kind of thing that turns a routine review into a longer conversation.

7. Data export and bulk access

Any action that pulls a meaningful volume of data out of your system in one request: CSV exports, bulk API pulls, report downloads. The signal that matters here isn't the export itself, since legitimate exports happen constantly, it's the combination of volume and destination. A modest export to a known integration is routine. A large export followed by a personal email address as the destination is the pattern every DLP tool and every incident responder is looking for.

8. Impersonation and support access

If your support or engineering team can log in as a customer's user to help debug an issue, that access needs its own event type, separate from a normal login, and it needs to be visible to the customer, not just internal to your team. This is consistently one of the first questions a security reviewer asks once they learn impersonation exists as a feature at all, because from their side it looks identical to an account takeover unless it's clearly labeled.

9. Security configuration changes

Changes to the controls that protect everything else: MFA enforcement toggled on or off, IP allowlists edited, SSO connections modified, password policy changes. These events are rare compared to the others on this list, which is exactly why they deserve their own category rather than getting buried in a general settings log. A control being quietly disabled is often the actual root cause once an incident gets investigated.

10. Non-human and automated activity

Service accounts, webhooks, scheduled jobs, and increasingly, AI agents acting on a user's behalf. This category has grown the fastest over the past year and is the one most existing audit logs weren't built for, since it requires distinguishing the human who authorized an action from the automated identity that carried it out. Log both: the delegating user and the acting service or agent, plus what it was scoped to do.

A short note on retention

Coverage solves half the problem. The other half is keeping records long enough that they're still there when someone asks for them. As a rough baseline across the categories above: authentication events for about a year, administrative and role change events for two years, and anything touching impersonation, MFA resets, or regulated data for longer still, since those are the categories most likely to matter well after the fact. Build retention into your schema from the start. Migrating years of historical data onto a new retention policy after the fact is a far worse project than setting it correctly the first time.

Building this yourself takes longer than it looks

Every item on this list is straightforward to describe and slow to build well. The hard part is rarely the logging call itself, it's the surrounding infrastructure: tamper evident storage kept separate from your application database, a schema flexible enough to cover ten different event categories without turning into a junk drawer, retention tiers that actually match what auditors expect, and a way to get records out to a customer's SIEM without a support ticket in the loop.

WorkOS Audit Logs is built for exactly this list. It gives you a strongly typed event schema you define once, SDKs so emitting an event is a couple of lines of code, storage that's separate from your own database by design, and log streams that ship straight to Datadog, Splunk, or S3 so your customers can plug your data into the tools they already run. Customers also get their own view into the log through the WorkOS Admin Portal, so their IT and security teams can investigate without opening a ticket with you. If you're staring down this list and budgeting the engineering quarter it implies, it's worth a look before you build it from scratch.