The Default Retention Window Is Not What You Think It Is

Purview Unified Audit Log (UAL) retention defaults vary by license tier, and this is where the first architectural problem begins.

For Microsoft 365 E3 tenants, the default UAL retention period is 90 days. For E5 or Compliance add-on tenants, it extends to one year. Microsoft's documentation states this clearly — but what the documentation does not explicitly address is how this interacts with the event generation latency and event lifecycle of Intune-sourced records.

Intune does not write directly to the Purview audit pipeline in real time for all event categories. Certain Intune operations — particularly device compliance state changes, policy assignment modifications, and conditional access evaluation events — are logged asynchronously. The delay between the operational action and the audit record appearing in UAL can range from minutes to several hours depending on service load and the specific workload involved.

This is not a bug. It is an architectural characteristic that Microsoft's standard onboarding documentation does not surface as a compliance risk. Practitioners who have only read the licensing comparison table are operating with an incomplete model.

---

Where Intune's Event Lifecycle Creates Structural Gaps

To understand the gap, you need to map the Intune operational lifecycle against the UAL event taxonomy. Three operational windows are consistently high-risk.

Device Enrollment Events

When a device enrolls through Autopilot, BYOD, or bulk enrollment, a sequence of events fires across multiple service boundaries: Entra ID device registration, Intune MDM enrollment, compliance policy evaluation, and conditional access grant or block. These events are logged across different audit schemas — AzureActiveDirectory, MicrosoftTeams, and IntuneDeviceManagement — and they do not always share a common timestamp anchor.

If your retention policy is set at the UAL workspace level without workload-specific overrides, you may have 90-day retention on the Entra ID device registration event but no explicit retention policy on the IntuneDeviceManagement schema at all. The Intune events fall back to the tenant default — which for E3 tenants is 90 days — but the correlation window between enrollment and first compliance evaluation can span hours. An auditor asking "what was the compliance state of this device at the moment it was granted network access?" may find the enrollment event but not the compliance evaluation that immediately followed it.

Compliance Policy Change Events

Policy changes in Intune generate audit records under the IntuneDeviceManagement workload. When an administrator modifies a compliance policy — changing a password length requirement, adding a disk encryption check, or altering a grace period — the change event is logged. What is frequently not logged in a way that survives the default retention window is the downstream re-evaluation cascade: every device that was re-evaluated against the new policy, and what compliance state transition occurred.

For a SOC 2 Type II audit covering a 12-month period, an auditor may ask for evidence that all devices were compliant with the updated policy within the required remediation window. If the re-evaluation events are older than 90 days and no extended retention policy was applied, that evidence does not exist in Purview. The compliance state today tells you nothing about the compliance state at the moment the policy changed.

Access Revocation and Offboarding Events

This is the highest-risk gap for HIPAA and FedRAMP environments. When a user is offboarded — account disabled in Entra ID, Intune device wiped or retired, conditional access policies updated — the event sequence spans Entra ID, Intune, and potentially Defender for Endpoint. Under FedRAMP Moderate controls (specifically AU-11), audit records must be retained for a minimum of three years.

A tenant running on E3 licensing with default UAL retention of 90 days is non-compliant with AU-11 on day one. The gap is not theoretical. It is structural and immediate.

---

Querying the Gap Before It Becomes an Audit Finding

Before adjusting any retention policy, you need to understand what your current UAL coverage actually looks like. The following KQL query, run in Microsoft Sentinel or the Purview audit search interface, surfaces Intune-sourced events and their distribution across the retention window.

// Identify Intune audit event distribution across the last 90 days
// Run in Microsoft Sentinel Log Analytics workspace connected to Purview UAL
OfficeActivity
| where TimeGenerated > ago(90d)
| where RecordType == "IntuneDeviceManagement"
| summarize EventCount = count(), 
            EarliestEvent = min(TimeGenerated), 
            LatestEvent = max(TimeGenerated)
            by OperationName
| order by EventCount desc
| project OperationName, EventCount, EarliestEvent, LatestEvent

This query tells you two things: which Intune operation types are actually being captured in your UAL pipeline, and whether any operation types have suspicious gaps (a high-frequency operation with a EarliestEvent that is more recent than expected suggests events are being dropped or delayed).

The next query identifies device compliance state change events specifically, which are the records most likely to be missing from a policy change audit trail.

// Surface compliance state transition events for devices
// Cross-reference with policy modification timestamps to identify coverage gaps
OfficeActivity
| where TimeGenerated > ago(90d)
| where RecordType == "IntuneDeviceManagement"
| where OperationName has_any ("UpdateDeviceCompliancePolicy", 
                               "DeviceComplianceState", 
                               "SetDeviceCompliancePolicyState")
| extend ParsedAuditData = parse_json(AuditData)
| project TimeGenerated,
          OperationName,
          UserId,
          DeviceId = tostring(ParsedAuditData.DeviceId),
          PolicyId = tostring(ParsedAuditData.PolicyId),
          ComplianceState = tostring(ParsedAuditData.ComplianceState)
| order by TimeGenerated desc

If this query returns no results or sparse results for a period when you know policy changes occurred, you have confirmed the gap.

---

Configuring Retention Policies That Match the Actual Risk Surface

Fixing the gap requires applying workload-specific audit retention policies in Purview, not relying on the tenant-level default. This is done through the Microsoft Purview compliance portal or via PowerShell using the Security & Compliance module.

The following PowerShell block creates a retention policy scoped specifically to Intune audit records with a three-year retention period — the minimum required for FedRAMP AU-11 compliance.

Connect-IPPSSession -UserPrincipalName admin@contoso.com

New-UnifiedAuditLogRetentionPolicy `
    -Name "Intune-Endpoint-3Year-Retention" `
    -Description "Extended retention for Intune device management audit events. Required for FedRAMP AU-11 and SOC 2 Type II." `
    -RecordTypes IntuneDeviceManagement `
    -RetentionDuration ThreeYears `
    -Priority 1

Get-UnifiedAuditLogRetentionPolicy | 
    Where-Object { $_.Name -eq "Intune-Endpoint-3Year-Retention" } |
    Select-Object Name, RecordTypes, RetentionDuration, Priority, IsValid

Critical note on priority: Purview evaluates retention policies in priority order. A lower priority number means higher precedence. If you have an existing tenant-wide policy at Priority 100 and you create a workload-specific policy at Priority 1, the workload-specific policy wins for IntuneDeviceManagement records. Confirm your priority assignments before assuming the policy is active.

You also need to extend retention for Entra ID events that correlate with device lifecycle operations. The AzureActiveDirectory record type covers device registration, conditional access evaluation, and sign-in events that are essential for reconstructing the enrollment and access revocation timeline.

New-UnifiedAuditLogRetentionPolicy `
    -Name "EntraID-Device-Access-3Year-Retention" `
    -Description "Extended retention for Entra ID device registration and conditional access events. Supports cross-workload audit correlation." `
    -RecordTypes AzureActiveDirectory `
    -RetentionDuration ThreeYears `
    -Priority 2

Get-UnifiedAuditLogRetentionPolicy | 
    Select-Object Name, RecordTypes, RetentionDuration, Priority, IsValid |
    Sort-Object Priority

---

Governance Considerations for Multi-Framework Environments

Environments subject to multiple compliance frameworks face a compounding problem. SOC 2 Type II typically requires 12 months of audit evidence for the audit period plus a reasonable lookback. HIPAA's audit control standard (§164.312(b)) does not specify a retention duration explicitly, but HHS guidance and common audit practice treat six years as the standard for documentation retention. FedRAMP Moderate AU-11 specifies three years.

If your Purview retention policy is configured to satisfy FedRAMP at three years, you are not automatically satisfying HIPAA's practical six-year standard. These frameworks do not align, and a single retention policy value cannot satisfy all three simultaneously unless you set it to the highest common requirement.

The governance failure mode here is subtle. Compliance teams often document that "audit logging is enabled and retention policies are configured" without specifying which retention duration applies to which event workload. When an auditor requests evidence for a HIPAA audit covering events from four years ago, the Purview configuration may technically have a retention policy in place — but if that policy was set to three years, the records are gone. The documentation said "retention is configured." The auditor's question cannot be answered.

Ownership is also a structural gap. In most enterprises, Purview audit configuration is owned by the security or compliance team, while Intune policy changes are owned by the endpoint team. Neither team has a formal handoff process that says: "Before you make this Intune policy change, confirm that the audit retention policy covering this workload is active and set to the correct duration." That handoff does not exist by default. It must be engineered.

A practical control is to add a pre-change checklist item to your Intune change management process — specifically requiring the change owner to confirm UAL retention coverage for the affected workload before the change is approved. This is not a technical control. It is a procedural one, and it is the kind of control that SOC 2 auditors look for when they evaluate the operating effectiveness of your change management process.

---

Validating Coverage After Policy Changes

After configuring workload-specific retention policies, validation is not optional. The policy creation PowerShell confirms the policy exists — it does not confirm that events are being captured and retained as expected.

Use the following KQL query to validate that Intune events older than 90 days are now present in your UAL pipeline, confirming that the extended retention policy is actively preserving records beyond the previous default window.

// Validate extended retention: confirm Intune events exist beyond 90-day default window
// This query should return results if extended retention is working correctly
// Run after 90+ days have elapsed since policy creation
OfficeActivity
| where TimeGenerated between (ago(365d) .. ago(91d))
| where RecordType == "IntuneDeviceManagement"
| summarize EventCount = count(),
            EarliestCaptured = min(TimeGenerated),
            LatestCaptured = max(TimeGenerated)
| project EventCount, EarliestCaptured, LatestCaptured,
          CoverageDays = datetime_diff('day', LatestCaptured, EarliestCaptured)

If EventCount is zero and you are past the 90-day mark from policy creation, the extended retention policy is not functioning as expected. Common causes include a priority conflict with an existing tenant-wide policy, a licensing gap (extended retention beyond one year requires E5 Compliance or the Audit add-on), or a delay in policy propagation that exceeded the expected window.

---

Recommendations for Endpoint and Compliance Teams

Four specific actions address the gaps described in this article.

First, audit your current UAL retention policies today using Get-UnifiedAuditLogRetentionPolicy. If you have no workload-specific policies, your tenant is running on defaults — and those defaults are almost certainly insufficient for at least one of your compliance frameworks.

Second, map your compliance framework requirements to specific Purview record types. IntuneDeviceManagement and AzureActiveDirectory are the minimum scope for endpoint-related audit coverage. Add MicrosoftDefenderATP if Defender for Endpoint is part of your access control architecture.

Third, set retention duration to the highest requirement across all applicable frameworks. If HIPAA's practical standard is six years and FedRAMP is three years, configure six years. The cost of over-retention is storage. The cost of under-retention is an audit finding you cannot remediate after the fact.

Fourth, add a UAL retention verification step to your Intune change management process. Before any compliance policy modification, the change owner should confirm — in writing, as part of the change record — that the relevant UAL workload has active extended retention coverage. This creates an auditable trail that demonstrates operating effectiveness, not just policy existence.

---