An admin who can't see who exported a customer list, or who changed a permission last Tuesday, has no way to investigate an incident inside your product. That's what a buyer's IT admin is checking when they ask whether you have an audit log. NIST's glossary defines one as "a chronological record of system activities, including records of system accesses and operations performed in a given period" (NIST glossary: audit log); the admin's real test is whether that record names the person responsible.

What the admin expects to find

Start with what your product actually records. Open the audit log screen in a demo workspace, if there is one, and look at the events it lists. Sign-ins and failed sign-ins are the obvious entries. Changes to users and roles matter just as much, since a quiet promotion to admin is exactly the kind of event a security team wants to catch, and that's where the log connects to how roles and permissions are set up.

Data exports and deletions come next, along with changes to workspace settings such as turning off SSO enforcement. If your log records those, say so plainly. If it only records sign-ins, say that too, because the buyer's admin will find out in the first week.

Each entry should answer who did what, and when. Some audit logs also record where the action came from, such as an IP address or device. Check whether yours does before you mention it.

Who can see it, and for how long

A buyer who takes audit logging seriously will follow up on retention and access, and both have exact answers in your product or documentation.

How long are entries kept? Retention for audit logs can differ from retention for the rest of the customer's data, and it can differ by plan. If the log keeps a short window on a lower tier and a longer one on enterprise plans, the buyer pricing the lower tier needs to hear that.

Can they get the data out? A security team that runs its own monitoring may want audit events in those tools, so expect them to ask whether there's an export, an API endpoint or a streaming integration with their SIEM. A screen they have to check by hand is a different proposition from events flowing into the system their security team already watches.

Why reviewers ask in such detail

Logging isn't a niche concern for security teams. In August 2024, the Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC) published Best Practices for Event Logging and Threat Detection with partners including CISA, the FBI, the NSA and the UK's NCSC, setting out a baseline for event logging to mitigate cyber threats (CISA: event logging best practices). NIST's older SP 800-92, a guide to computer security log management, covers similar ground. A reviewer working from guidance like that will want to know whether logs can be altered after the fact. Can anyone at your company edit or delete entries? And are your own staff's actions in a customer's workspace recorded too?

You can test that last one yourself: have someone on support open a session in your demo workspace, then look for it in that workspace's audit log. If support engineers' sessions in a customer workspace don't appear in that customer's audit log, the admin will see a gap exactly where vendor access should show up.

VoiceVocab's Cloud & security course has you answer buyer questions about hosting, access and security out loud, with written feedback on each answer; the free APIs & integrations lesson works the same way and needs no card.

Showing it in a demo

If audit logging matters to the buyer, show it rather than describe it. Make a change in the demo workspace during the call, such as promoting a test user to admin, then open the audit log and find the entry. The admin sees the event, the actor and the timestamp appear in front of them, and you find out on the spot whether the entry contains what they expected. If it doesn't, write down which detail was missing and check whether a setting or a different plan records it.

Check the timestamps before you do this. If the log displays times in UTC and the buyer is in another time zone, say so, or the first thing they notice will be an entry that seems to come from the wrong hour.

Audit log or audit trail?

Buyers sometimes use the two terms interchangeably, but NIST defines them differently. An audit trail is "a chronological record that reconstructs and examines the sequence of activities surrounding or leading to a specific operation, procedure, or event in a security relevant transaction from inception to final result" (NIST glossary: audit trail). When a buyer asks for an audit trail on a particular record, such as a contract or a payment, they want that full sequence for one item, which is a narrower and deeper request than a workspace-wide list of events.