The Microsoft 365 configuration problems that cause audit findings are rarely decisions anyone made. They're defaults nobody changed, in a tenant that has been running fine for three years.
The most expensive one deletes your evidence on a schedule.
Your audit logs expire before your audit period does
Microsoft Purview Audit (Standard), which is what you have unless you're licensed for E5 or the equivalent add-on, retains audit records for 180 days. There is no setting to extend it. On day 181 the oldest records begin disappearing, without a warning and without a way to get them back.
Now consider how a Type II works. It examines whether your controls operated across an observation period, and fieldwork happens after that period closes. An auditor sampling activity from the start of a 12-month window is asking about events that are more than a year old. Even on a six-month window, by the time the period closes and fieldwork begins, the earliest records are pushing against the limit.
The failure looks like this: an auditor selects a terminated employee from month two and asks for evidence of when their access was revoked. The offboarding happened correctly. The control operated. The record that proves it was deleted four months ago.
That is not a security failure and it isn't a process failure. It's a licensing and configuration decision made by someone who had no reason to connect it to an audit that hadn't been scoped yet.
E5 helps, and it doesn't close the gap
If your users are licensed for E5, Purview applies a default retention policy that keeps Exchange Online, SharePoint, OneDrive, and Microsoft Entra records for one year.
Everything else still defaults to 180 days. Teams activity, Power Platform, Defender events. Those can be extended with custom audit log retention policies, up to a year, and further with an additional add-on.
Two things follow from that. First, mixed licensing means mixed retention, because the policy applies based on the license held by the user who generated the activity. A tenant with a handful of E5 users and everyone else on Business Premium has an evidence window that varies by whose activity you're asking about. Second, retention policies apply going forward. Creating one in month ten of your observation period does not recover months one through nine.
Which means the time to fix this is before the observation window opens, and the time to check it is now, whether or not an audit is scheduled.
The other defaults worth checking
Audit retention is the one that costs the most, but it isn't alone. The pattern is the same in each case: a setting that was reasonable when the tenant was created, never revisited, and invisible until someone tests it.
Legacy authentication protocols that bypass Conditional Access, still enabled because a line-of-business application needed them in 2021 and nobody confirmed whether it still does.
Standing global administrator access, usually more accounts than anyone would guess, held permanently rather than elevated when needed. Auditors ask how many people can do anything, and the honest answer is often uncomfortable.
Break-glass accounts excluded from Conditional Access policies, which is correct practice, but frequently undocumented and unmonitored, so what should be a deliberate exception looks like a gap.
Guest access and external sharing in SharePoint and Teams, where the default posture is more permissive than most organizations assume and the accumulated guest list is longer than anyone expects.
Unified audit log ingestion, which is on by default but can be disabled with a single PowerShell command, and occasionally has been.
Why a policy document doesn't help here
This is the part that catches people who have done the compliance work seriously.
You can write a policy stating that audit records are retained for twelve months, get it approved, and file it. The auditor will read it, and then test the tenant. The tenant is configured for 180 days. The finding isn't that your retention is too short. It's that your documented control and your actual configuration disagree, which is a worse finding because it calls the rest of your documentation into question.
Configuration is the control. The policy describes it. When they diverge, the configuration is what operated.
What this looks like done properly
Before an observation period starts, the tenant configuration gets reviewed against the controls the organization intends to claim. Retention is set to cover the window with margin, licensing gaps are identified while there's still time to address them, and the settings that will be tested are confirmed to match what the policies say.
That review is not difficult and it doesn't take long. It's just easy to skip, because nothing in the environment prompts you to do it and everything appears to be working.
It fits alongside the operational work that produces the rest of your evidence: access requests and approvals that get captured as they happen, device enrollment enforced through Conditional Access, and credential controls that produce reports rather than investigations. Configuration review is the part that makes sure the platform is still holding the records those processes generate.
If you're planning a first audit or maintaining an existing report, checking your audit log retention against your observation window is a short task with an outsized consequence. It's one of the first things we look at, and it's found more than once.
More on how the pieces fit together in preparing for a SOC 2 audit.