How long Microsoft keeps the logs you will need after a breach

Entra ID keeps audit logs and sign-in logs for seven days on the Free tier and 30 days on both P1 and P2. Moving from P1 to P2 buys Identity Protection and Privileged Identity Management and adds nothing to activity log retention, which catches out organisations that assumed the higher tier meant more history. Multifactor authentication usage sits at 30 days on every tier. Microsoft's retention reference gives risky sign-ins as seven days on Free, 30 days on P1 and 90 days on P2, while its own risk-export guidance still shows 30 days at P2, so plan against the shorter number.

Microsoft Graph activity logs behave unlike the rest. They record Graph API calls, they are available only with P1 or P2, and they are not retained at all by default; the data exists only if the category was enabled in a diagnostic setting beforehand. Since most application access to mail, files and directory objects travels through Graph, the log that would describe what a compromised app registration did is, in most tenants, one that was never created.

Audit (Standard) retains audit records for 180 days and is enabled by default for most organisations, so the log is almost certainly there whether or not anyone has searched it. The default changed from 90 days on 17 October 2023, and that date is diagnostically useful: a runbook or questionnaire answer still asserting 90 days has not been reviewed since.

Audit (Premium) adds a default policy holding one year of records carrying a workload value of AzureActiveDirectory, Exchange, OneDrive or SharePoint. It covers only records generated by users holding Office 365 or Microsoft 365 E5, the Purview Suite, or the E5 eDiscovery and Audit add-on. Records from non-E5 users and guests fall back to 180 days, as do records from every other workload unless a custom policy says otherwise.

Custom retention policies are the route to something longer, and also how retention gets quietly shortened, because any custom policy takes precedence over the default. An organisation can hold up to 50 policies ordered by priority, and ten-year retention needs a separate per-user add-on that cannot reach records generated before the policy existed. Records generated by non-user entities, meaning service principal actions, system events and application activity, sit outside all of that on a fixed one year. Ingestion can also be switched off organisation-wide with one Exchange Online setting, so confirm it: a tenant with ingestion disabled looks identical to a healthy one until you run a search.

MailItemsAccessed is the record that answers whether messages were actually read. It is part of Audit (Standard), covers POP, IMAP, MAPI, Exchange Web Services, ActiveSync and REST, and is enabled by default for users assigned an Office 365 E3 or E5, or Microsoft 365 E3 or E5, licence. In a mixed tenant that produces the pattern investigators keep meeting: a complete mail access history for one employee and nothing for the person beside them, decided by a licence assignment unrelated to security.

The records arrive in two shapes, and the difference decides how precisely a notification can be scoped. Bind access records individual messages by internet message ID, with every bind inside a two-minute interval aggregated into one record. Sync access records the folder instead of the items, and Microsoft's own guidance is to treat every item in a synced folder as compromised. Sync is recorded only when a desktop Outlook client on Windows or Mac accesses the mailbox, and after a sync the reading happens locally where no audit record follows it.

Mailbox auditing is on by default, and several configuration decisions remove the evidence anyway. Customising the audited actions for a sign-in type through the AuditAdmin, AuditDelegate or AuditOwner parameters stops Microsoft managing that sign-in type on that mailbox, so actions released afterwards are never added. A mailbox audit bypass association suppresses every action by the named user anywhere in the organisation, including actions taken as a delegate in other mailboxes. Auditing on by default covers user, shared and Microsoft 365 Group mailboxes; resource and public folder mailboxes are not supported, and cross-geo access to a shared mailbox is never written to that mailbox's audit log.

The Azure activity log is collected by default with no configuration, retained for 90 days, then deleted. The period is not adjustable and the entries are not chargeable. It records control-plane operations, the creation, modification and deletion of resources, and it does not typically capture reads. It is also the only place the creator of a resource is recorded.

Resource logs work the opposite way. They are generated automatically but are not collected or stored until a diagnostic setting exists to route them, and that setting is created per resource, so anything a project team stood up last month has none unless an Azure Policy assignment creates one. The honest description of most estates is 90 days of control plane and nothing of data plane. The destination then carries its own clock, and the first 31 days of workspace retention are included in the ingestion price, which is where most estates quietly settle.

One correlation trap comes with any query of exported identity logs. TimeGenerated is the time Log Analytics received the record, the actual sign-in time sits in CreatedDateTime, and for risky sign-ins TimeGenerated reflects when the risk was detected. Both are UTC while the Entra admin centre displays local time, so a timeline assembled from both without adjusting will be wrong by hours.

The download question most often has no answer. For a storage account, data-plane reads are recorded only through the StorageRead resource log category, which produces nothing unless the diagnostic setting predates the activity. Without it, no log in Azure can say which blobs were read, and the investigation falls back to inference from network egress, application logs, or the known behaviour of the tooling.

The same question about a SharePoint document library is usually answerable, because that file activity lands in the unified audit log by default. Two stores holding the same regulated material can sit in completely different evidential positions, decided by whether somebody created a diagnostic setting.

Microsoft answers this one plainly. Asked whether last month's data becomes visible after buying a premium licence, the Entra retention reference says no: upgrading from Free to P1 or P2 exposes only the data still inside the seven-day window, and anything already expired is unrecoverable unless it was archived at the time. What the purchase buys is the next 30 days.

The unified audit log reaches the same place by a different mechanism. An audit record's lifetime is fixed when it enters the auditing pipeline, based on the licensing and policies in force at that moment, so later changes affect only records committed afterwards. A ten-year policy cannot reach back before it existed, and streaming Defender data accumulates only from the day it is enabled.

The licence approved on day two and the diagnostic setting created on day three are controls for the next incident. For the current one, the only evidence in existence is what was already being retained when the intrusion started, which is why the inventory of what runs and how long it is held belongs in a normal working week.

The constraint that decides these settings is ingestion and retention volume. Keeping everything for a year loses the budget argument, and the usual retreat of 30 days for everything produces an estate that can answer almost nothing about an intrusion discovered in month three. The decision is which few sources carry a long horizon while the rest roll off.

Identity earns it first, because audit and sign-in logs are small next to application telemetry and answer questions that arise in every investigation. The unified audit log comes next, through Audit (Premium) retention or a scheduled export to storage the organisation controls. Then the Azure activity log, which is cheap to hold because its ingestion is not charged and only the period past 90 days attracts a retention cost. Then data-plane logging on the one or two stores that hold regulated material, while flow logs and verbose platform telemetry expire early without weakening any of those answers.

The horizon should come from the obligation. Scoping affected individuals under the Notifiable Data Breaches scheme is a log question with a 30-day assessment clock attached, an AFSL holder carries record-keeping obligations measured in years and a regulator entitled to test them, and a firm working towards AML/CTF readiness has to evidence who did what and when well beyond a six-month window. Each sets a floor the configuration should be built to meet.

In an Azure and Entra ID security review this is the first inventory we build: which sources run, how long each is held, and which of the questions above the configuration could still answer today. In incident response it sets the order of work, because there is no value in building a timeline around a source that expired in January. The append-only audit ledger under the operations and compliance portal we built and run for GRM LAW records what happened inside the system; tenant and platform logs record how someone reached it at all. Before any of that, write down the five questions your board, your insurer and the OAIC would ask on the worst day, and confirm source by source that each answer still exists today.