What is an audit log?

An audit log answers “who did that”. In an event console the actions worth recording are content changes, moderation decisions, attendee data access, invitation sends and check-ins.

In practice at an event

Two moments make it valuable. The first is a moderation decision somebody questions afterwards: a photo removed, a question declined, an attendee blocked. Being able to say who decided and when turns a dispute into a conversation.

The second is more mundane and more frequent: a session moved room, nobody remembers doing it, and the schedule now disagrees with the venue. An audit log ends that in thirty seconds.

It also matters for security review, where “can you tell who accessed the attendee list” is a standard question, and for the specific case of a departing team member whose actions need reviewing.

What to look for

Ask what is logged, how long it is kept, and who can read it. A log that only administrators can see is normal; a log nobody can see is not a log.

Ask specifically whether vendor support access is logged. Support staff needing occasional access to your event is normal and necessary; that access being invisible to you is not.

A log is only useful if somebody can read it under pressure. Before your event, open it once and find a specific action you took an hour earlier. If that takes more than a minute on a normal day, it will not happen at all on the day you need it.

How event67 handles it

Every administrative action in the organizer console is audit-logged, across roles covering super-admins, org admins and per-event moderators. Team chat carries its own audit trail alongside reactions, replies and delivery ticks. The console has an Activity view for reviewing what has happened on an event.