Agent Foskett Case File • Microsoft Purview • Retention Policy • Audit Logs • KQL
At 3:21 AM, Someone Changed the Retention Policy
At 3:21 AM, an administrator changed a Microsoft Purview retention policy.
No file download. No dramatic ransomware screen. Just a configuration update in the middle of the night.
“Three twenty-one?” Agent Foskett said. “That is a remarkably specific time to develop an interest in records management.”
But who made the change — and what did it actually affect?
Case file: An administrative change is not proof of authorisation
A fictional, evidence-led investigation into a Microsoft Purview data lifecycle retention policy, its audit trail, sign-in context, and the risk of assuming policy changes automatically delete data.
The change nobody expected
The fictional organisation had a Microsoft Purview retention policy covering selected SharePoint and OneDrive locations. Its records team expected business content to remain governed by the approved schedule.
On the following morning, a compliance administrator noticed that the policy configuration no longer matched the approved baseline. The policy scope had been narrowed overnight. A change record showed 3:21 AM local time.
“Could be planned maintenance,” said the analyst.
“Then we should find the plan,” Agent Foskett replied. “And the person who approved it.”
On the following morning, a compliance administrator noticed that the policy configuration no longer matched the approved baseline. The policy scope had been narrowed overnight. A change record showed 3:21 AM local time.
“Could be planned maintenance,” said the analyst.
“Then we should find the plan,” Agent Foskett replied. “And the person who approved it.”
First, identify exactly which policy changed
The team checked the Microsoft Purview data lifecycle / records-management retention policy, not the separate Purview audit-log retention policy. These are different controls. They preserved the current policy name, locations, retention settings, enabled state, rule configuration, any applicable preservation-lock settings, and an approved prior baseline.
They compared the before-and-after configuration and checked change-management records. In this scenario, the policy was still present, but one SharePoint site was no longer in scope. That observation raised a risk; it did not prove that any content had already been deleted.
They compared the before-and-after configuration and checked change-management records. In this scenario, the policy was still present, but one SharePoint site was no longer in scope. That observation raised a risk; it did not prove that any content had already been deleted.
Find the administrative event in Microsoft Purview Audit
The Microsoft Purview Audit search is the primary starting point for Microsoft 365 administrative activity. Search the suspected period with a wider window, examine relevant retention-policy operations, and export the original audit records. Audit records vary by workload and operation; inspect the actual event and its
For the example below,
AuditData rather than assuming every change uses the same operation label.For the example below,
OfficeActivity is available only if Microsoft 365 activity has been connected to a Log Analytics workspace through the appropriate integration. It is not automatically present in every Sentinel workspace.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
// Microsoft Sentinel / Log Analytics — requires OfficeActivity ingestion
let StartUtc = datetime(2026-10-13T15:30:00Z);
let EndUtc = datetime(2026-10-13T17:30:00Z);
OfficeActivity
| where TimeGenerated between (StartUtc .. EndUtc)
| where Operation has_any ("Retention", "CompliancePolicy", "ComplianceRule")
or tostring(Parameters) has_any ("Retention", "CompliancePolicy")
| project TimeGenerated, OfficeWorkload, Operation, UserId,
ClientIP, OfficeObjectId, Parameters
| order by TimeGenerated ascA note about 3:21 AM and time zones
For this illustrative case, 3:21 AM on 14 October 2026 in Melbourne (AEDT, UTC+11) corresponds to 16:21 UTC on 13 October 2026. The KQL searches use UTC timestamps, so the investigator must convert the local event time correctly before correlating sources. A one-hour or one-day error can send the investigation in the wrong direction.
“The logs are very precise,” Agent Foskett said. “It is our clocks that occasionally require an investigation.”
“The logs are very precise,” Agent Foskett said. “It is our clocks that occasionally require an investigation.”
Who was the administrator — and was the sign-in expected?
The audit event identified an administrator account, but an account name is not the same as proof of who was at the keyboard. The team checked the account’s Entra ID sign-in history, authentication method, application, device context, source IP, conditional-access result, and nearby activity. They compared the event against authorised automation and scheduled change windows.
The sign-in below is a correlation lead; it cannot, by itself, prove that a particular sign-in caused the Purview change. Service principal or non-interactive activity may require additional log sources.
The sign-in below is a correlation lead; it cannot, by itself, prove that a particular sign-in caused the Purview change. Service principal or non-interactive activity may require additional log sources.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
// Microsoft Sentinel — requires Entra SigninLogs ingestion
let TargetAdmin = "compliance.admin@contoso.com";
let StartUtc = datetime(2026-10-13T15:30:00Z);
let EndUtc = datetime(2026-10-13T17:30:00Z);
SigninLogs
| where TimeGenerated between (StartUtc .. EndUtc)
| where UserPrincipalName =~ TargetAdmin
| project TimeGenerated, UserPrincipalName, AppDisplayName,
IPAddress, ResultType, ConditionalAccessStatus,
AuthenticationRequirement, DeviceDetail, LocationDetails
| order by TimeGenerated ascThe second audit trail: privilege and account changes
Agent Foskett widened the investigation. Had someone assigned a privileged role before 3:21 AM? Was a new credential added to the administrator account? Was an emergency account used? Were there suspicious directory changes shortly before or after the policy update?
These questions matter because an apparently ordinary configuration change can follow an identity compromise. Equally, the change may be an authorised maintenance task. The team kept both hypotheses open until they had evidence.
These questions matter because an apparently ordinary configuration change can follow an identity compromise. Equally, the change may be an authorised maintenance task. The team kept both hypotheses open until they had evidence.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
// Microsoft Sentinel — requires Entra AuditLogs ingestion
let StartUtc = datetime(2026-10-13T14:00:00Z);
let EndUtc = datetime(2026-10-13T18:00:00Z);
AuditLogs
| where TimeGenerated between (StartUtc .. EndUtc)
| where Category in~ ("RoleManagement", "UserManagement", "ApplicationManagement")
| project TimeGenerated, Category, OperationName, Result,
InitiatedBy, TargetResources, CorrelationId
| order by TimeGenerated ascWhat did the policy change actually do?
The investigators compared the site exclusion against the policy’s retention rules, effective scopes, labels, and any other overlapping retention settings. A location being removed from one policy does not automatically mean its content is immediately deleted. Other policies, labels, holds, processing delays, and service behaviour may still govern the items.
To establish impact, they reviewed affected locations and item-level retention state using supported administrative and compliance tools. They searched for separate deletion or disposition evidence, and documented what could not be determined from the available logs. They did not claim an information loss event without evidence of one.
To establish impact, they reviewed affected locations and item-level retention state using supported administrative and compliance tools. They searched for separate deletion or disposition evidence, and documented what could not be determined from the available logs. They did not claim an information loss event without evidence of one.
Reconstructing the timeline
02:58 AM — Privileged access reviewedAn administrator session appears in the identity evidence; its relationship to the change is investigated.
03:21 AM — Policy changedThe Purview audit trail records a retention-policy administration event.
03:24 AM — Configuration persistedThe updated policy scope is visible in the configuration review.
08:40 AM — Difference discoveredThe records team finds a mismatch against the approved baseline.
09:15 AM — Evidence preservedThe team exports audit records, sign-in context, and policy configuration.
10:30 AM — Authorisation checkedChange records and administrators are consulted before any restoration.
The investigation outcome
In this illustrative case, the administrator confirmed they had not scheduled the 3:21 AM change, and the team could not locate an approved change request. They treated the event as potentially unauthorised, escalated it through the incident-response process, reviewed account security, and restored the approved policy configuration using authorised procedures after preserving evidence.
They did not conclude that data had been deleted. The evidence supported an unexpected policy-scope change and the need to investigate identity and content impact. That is a meaningful finding without inventing a larger incident.
They did not conclude that data had been deleted. The evidence supported an unexpected policy-scope change and the need to investigate identity and content impact. That is a meaningful finding without inventing a larger incident.
Practical defensive lessons
Restrict policy administration to the smallest practical set of roles; require accountable change approval; review privileged access and emergency accounts; monitor retention-policy administration events; keep versioned configuration baselines; and test how alerts reach the SOC.
Use Microsoft Purview Audit as the authoritative investigation starting point and Sentinel only where the necessary logs are connected and retained. Always preserve timestamps, raw audit details, actor information, and the before-and-after configuration.
Use Microsoft Purview Audit as the authoritative investigation starting point and Sentinel only where the necessary logs are connected and retained. Always preserve timestamps, raw audit details, actor information, and the before-and-after configuration.
Investigation principle: A policy change tells you what was configured. Additional evidence is required to prove who authorised it and what happened to the data.
Final thought
“So someone changed the retention policy at 3:21 AM?” the analyst asked.
“Yes,” Agent Foskett replied.
“Does that mean the records were deleted?”
“No. It means we have a change to investigate. Let us not promote a suspicion into a fact.”
He closed the audit record.
“Besides, anyone voluntarily doing records management at 3:21 in the morning deserves at least one follow-up question.”
The Logs Already Knew! 🔎
“Yes,” Agent Foskett replied.
“Does that mean the records were deleted?”
“No. It means we have a change to investigate. Let us not promote a suspicion into a fact.”
He closed the audit record.
“Besides, anyone voluntarily doing records management at 3:21 in the morning deserves at least one follow-up question.”
The Logs Already Knew! 🔎
Related investigations
Defender Detected the Threat — But the Response Action FailedA detection is not proof that containment succeeded.The AI Assistant Answered a Question Nobody Should Have AskedInvestigate untrusted instructions and AI-generated answers.Someone Exported the Database — But No Download Was RecordedFollow application and database activity beyond file downloads.
