When there is a question about what happened inside Microsoft 365 — a compromised account, a suspicious departure, a file that shouldn’t have moved — memory and assumption are not enough. What you need is an impartial record of events. In most tenants, the closest thing to that record is the unified audit log.
Understanding what the audit log captures, and just as importantly what it does not, is the difference between an investigation grounded in evidence and one built on guesswork. This article explains why these logs matter and where their limits lie. It is general information; the specifics for any given tenant depend on its licensing and configuration.
What the audit log actually is
The Microsoft 365 unified audit log is a consolidated stream of activity events from across the service — Exchange Online, SharePoint, OneDrive, Entra ID, Teams, and more. Rather than each service keeping its own siloed history, many actions flow into one searchable record: who did what, to which object, and when.
For an investigator, that consolidation is the point. A single question — “what happened to this mailbox last Tuesday?” — can be answered by correlating sign-ins, mailbox actions, and file activity that would otherwise live in separate places.
Why it is often the best evidence available
Three properties make audit records especially valuable when something is contested.
It is activity-level, not just outcome-level. A file being gone tells you the end state. The audit log can tell you the action that produced it — a deletion, a move, a permission change — and the account that performed it.
It spans the environment. Because it draws from many services, the log lets you follow a thread across boundaries: an unusual sign-in, followed by a new inbox rule, followed by a burst of file downloads. Any one event might be innocent; the sequence tells a story.
It is comparatively neutral. Unlike recollections gathered after the fact, the log was written as events occurred, without knowledge of the dispute to come. That does not make it infallible, but it makes it a more objective starting point than most alternatives.
The limits that matter most
The audit log’s usefulness is bounded by conditions that were set before the events you care about — which is exactly why they are easy to overlook until it is too late.
- Retention is finite and license-dependent. Audit events are kept for a period determined by your licensing and configuration. Once events age past that window, they are gone. A higher license purchased after an incident does not resurrect records that were never retained or have already expired.
- Logging must have been enabled. If auditing was turned off, or specific auditing was not configured for the relevant workload, the corresponding events simply do not exist to be found.
- Not every action is equally detailed. The granularity of what is recorded varies by workload and plan. Some questions the log answers cleanly; others it can only partially illuminate.
- Timestamps need care. Time zones, clock references, and the meaning of a given event type all require attention. Misreading them produces confident but wrong timelines.
None of this makes the audit log unreliable. It makes it something that must be interpreted honestly, with its gaps acknowledged rather than papered over.
Turning records into a defensible timeline
Raw log entries are not an investigation. The analytical work is in correlation and interpretation: assembling events from multiple services into a coherent sequence, distinguishing routine activity from anomalies, and being explicit about what the evidence supports versus what remains uncertain.
A well-built timeline states its own limits. It says not only “these events occurred in this order,” but also “here is what we could not determine, and here is why.” That candor is what makes a technical account useful to the people who have to act on it — and it keeps technical findings distinct from the legal or personnel conclusions that belong to others.
A readiness checklist
You cannot investigate with logs you never kept. Before you need them:
- Confirm that unified audit logging is enabled for your tenant.
- Understand your current audit retention window and what your licensing provides.
- Verify mailbox auditing is capturing the actions you would care about.
- Know which workloads (Exchange, SharePoint, Entra ID) are in scope for logging.
- Review whether your retention matches how long issues typically take to surface.
- Document the configuration, so that during an incident you already know what exists.
The takeaway
The best time to think about audit logs is long before an investigation — because their value in a crisis is fixed by decisions made in calmer times. When a genuine question arises, the first analytical step is not to draw conclusions but to establish what the records can actually show. An honest answer to that question, gaps and all, is worth far more than a confident story the evidence cannot support.