Audit logging appears on every comparison table and turns out to be worth wildly different amounts depending on what is actually in it.
There is a single test. Six months from now, someone asks who had access to a particular document and what they did with it. Can the log answer, without qualification?
The five parts of a usable entry
Who - and with which credential. Not just an account name. A person signing in through a browser, an API key acting on their behalf, and a sync client on a laptop are three different actors with three different implications. A log that flattens them into “user@example.com” cannot distinguish a person from a stolen token, which is precisely the distinction you need during an incident.
What, specifically. “File modified” is nearly useless. You want the file by path and by stable identifier, so the entry still resolves after a rename - renames are exactly when you most need history, and a path-only log loses the thread at the worst moment.
When, unambiguously. UTC with an explicit offset, at second resolution or better. Local timestamps across a distributed team turn incident reconstruction into arithmetic, and arithmetic under pressure produces mistakes.
From where. IP address, plus enough client detail to distinguish a browser from a sync client from a script. This is what makes “signed in from two continents within an hour” a visible fact rather than a suspicion.
The outcome. This is the part most often missing and the most valuable. A log of successful actions tells you what happened. A log that also records denied attempts tells you what someone tried and could not do - which is the actual signal of a problem in progress rather than a record of one that finished.
Events worth capturing
Authentication: sign-ins and failures, two-factor changes, password changes, new sessions, session revocations.
Access: downloads and previews, not only modifications. For confidential material, reading is the event that matters, and logs that only record writes miss the entire exfiltration case.
Sharing: links created and their settings, links opened and by whom, links revoked or expired. External sharing is where data actually leaves, and it deserves more logging attention than internal editing usually gets. Our guides to expiry and sharing sensitive documents cover the controls; the log is how you verify they held.
Permissions: grants, revocations, role changes, credential creation. Every access question asked later is answered from this stream.
Destruction: deletions, and whether recoverable, and by whom.
Properties that make it trustworthy
Tamper evidence. A log an attacker can edit after the fact is not evidence. Some form of hash chaining or append-only guarantee means alterations and gaps become detectable rather than invisible. Without it, the log is only trustworthy against people who were not trying.
Retention that outlives the question. Incidents surface late - the average breach goes undiscovered for months. A 30-day window cannot answer a question about last quarter, which is when most questions arrive. Check this number before you need it.
Actually queryable. A trail you can filter by user, by file, by date range and by outcome gets used. One that requires exporting everything and grepping does not, and an unused log is decoration with a storage cost.
Sensible about secrets. Logs must never capture file contents, share tokens, credentials or session identifiers. An audit trail that leaks the thing it was auditing has created a new problem rather than a control - and audit logs are frequently copied to analytics systems with weaker access controls than the files themselves.
Separate from the thing it audits. If deleting a workspace deletes its audit trail, the trail cannot testify about the deletion.
Why the denied events matter most
Successful actions are mostly noise - people doing their jobs, thousands of times a day. Denied attempts are where the signal lives.
A credential repeatedly trying paths it has no rights to is either misconfigured or being probed, and both are worth knowing about today rather than next quarter. A log recording only successes cannot distinguish an attacker who found nothing from an attacker who was never there. That distinction is the entire point.
Using it before an incident
The mistake is treating an audit log as forensic material only. The higher-value use is routine.
Look at it when someone leaves, to see what they touched and which credentials they created. Look at it when a project ends, to find external shares that should end with it. Look at it occasionally for denied-access clusters, which surface misconfigured integrations long before anyone reports a problem.
That habit connects directly to team permissions: the roles express what should be possible, and the log is the only way to find out what actually was.
Our own trail records access, sharing, permission and authentication events with the outcome attached, and is available to workspace owners and admins.
