Microsoft 365, Entra and Intune
Microsoft 365 audit log retention: there right up until you needed it
A customer emails in March asking whether a document was accessed by anyone outside the company. The document was shared in September. You open the audit log search, set the date range, and get nothing, because the retention window closed months ago and nobody chose that window or knew it existed.
Microsoft 365 audit log retention is one of the few settings where the default is fine until the single moment it is not, and at that moment there is no remedy. You cannot retrospectively retain a log.
What the unified audit log actually holds
More than people expect, which is what makes the retention question matter.
Sign-ins and authentication events. Mailbox activity including access to other people's mailboxes, which is the one that answers most internal questions. SharePoint and OneDrive file access, sharing and downloads. Teams messages sent and channels created. Administrative actions across Exchange, SharePoint, Entra and Purview. Sharing link creation, which is how you answer the question in the opening paragraph.
That last one is worth dwelling on. The record of a link having been created, and of who used it, is in the audit log and nowhere else that a small tenant is likely to be keeping.
Microsoft 365 audit log retention by licence
The shape, rather than exact numbers, because Microsoft has changed these and will again.
Standard audit, included in the common business and E3 plans, retains for a period measured in months rather than years. It covers the event types above.
Premium audit, in E5 or as an add-on, retains substantially longer, adds some higher-value event types, and permits configurable retention policies per event type or per user.
Because the specifics move, check Microsoft's audit log retention documentation against your own tenant rather than trusting any figure in a blog post, including this one. The relevant question is not what the documentation says in general, it is what your tenant is configured for right now, and that is worth checking today rather than in March.
The gap between retention and investigation
Here is the practical problem, and it is a mismatch of timescales rather than a configuration error.
Security incidents are frequently discovered long after they happen. A compromised account is noticed when somebody reports an odd email. A data question arrives when a customer asks, or when a former employee's new employer sends something suspicious. Breach notification obligations begin when you become aware, not when the event occurred, and the ICO's personal data breach guidance sets out what you are expected to be able to establish.
The investigation you will need is almost always about a period that has already passed. So the retention window is not "how long until we notice a problem", it is "how far back might we need to look, from a starting point we do not control".
For a company handling customer data under contractual obligations, a window measured in a few months is uncomfortably short. Twelve months is a defensible answer. Longer if your contracts say so, and some customer contracts do specify log retention without anybody internally having read that clause.
Shipping it somewhere you control
If the built-in window is shorter than you need, the options are to buy longer retention or to export.
Ship to Sentinel. The OfficeActivity table holds unified audit log data,
and once it is in Log Analytics you control retention independently. The
trade-off is ingestion cost, which is the entire subject of
the Sentinel cost note, and OfficeActivity is
one of the higher-volume tables. Worth filtering to the operations you actually
need rather than taking everything.
Export to storage. Cheaper by a wide margin, and worse to query. A scheduled job pulling the audit log via Graph or the Office Management API into blob storage with a lifecycle policy costs very little. When you need it you are parsing JSON out of blobs rather than writing KQL, which is fine for an occasional investigation and painful for anything routine.
Buy Premium audit. Simplest, no engineering, and the cost scales with headcount rather than volume, which for a small company is often the cheaper answer than it first appears.
The decision usually comes down to whether you also want detections on this data. If yes, Sentinel, because the data has to be there anyway. If you only need it for retrospective questions, storage export is the economical answer.
What an investigation looks like without it
Worth describing, because it is the argument that gets budget.
A former employee is suspected of taking a customer list before leaving. With the audit log, this is an afternoon: search file access and sharing events for that user over their final month, identify what was downloaded or shared externally, and produce a timeline with timestamps. The answer is either reassuring or actionable, and either way it is defensible.
Without it, you have their mailbox if it still exists, whatever the endpoint tooling retained, and inference. You cannot establish what was accessed. You cannot rule it out either, which is the worse half: an inconclusive investigation means you cannot tell the customer nothing happened, and you cannot tell your insurer or a regulator what did.
That asymmetry is the point. Retention does not only help you prove something went wrong. Most of the time it lets you prove nothing did, and "we checked and here is the evidence" is a materially different conversation from "we have no way of knowing".
The same applies to the mundane version. Somebody asks whether a file was shared externally before a deal closed. With logs it is a query. Without them it is a discussion about what people remember.
The check worth doing this week
Two things, twenty minutes.
Confirm audit logging is actually enabled. It has been on by default for new tenants for some time, and older tenants and specific mailbox audit settings still catch people out. A tenant where somebody disabled mailbox auditing years ago to reduce noise is not a hypothetical.
Then run a search for something you know happened four months ago and see whether it returns. That is a more reliable answer than any documentation, because it tests your tenant rather than the general case. If it comes back empty, you have found out on a quiet Tuesday rather than during an incident.
Where this sits
Log retention is one of the least interesting controls to implement and one of the most consequential to have got wrong, which is a poor combination for something nobody is asked about until it matters.
It sits alongside the rest of the Microsoft 365 notes, and if you are documenting this for a certification or a customer questionnaire, the book covers logging and monitoring evidence in the context of the relevant Annex A controls.