Who changed an Intune policy

Start with the policy and incident window

Record the policy name, type and object ID before searching. Names can be reused and recreated policies have new identities. Write down when the unexpected behavior was first noticed, then allow for a change earlier than the report: a device or support ticket may reveal the effect after the edit.

Keep the investigation read-only while collecting evidence. Capture the relevant current settings and a new backup if you have access, rather than changing the suspected setting immediately and losing the context. The goal is to distinguish the recorded operation from the later device symptom.

• Audit logs or backup comparisons for drift evidence
• Audit logs or backups for policy recovery

Filter the native Intune audit log

In the Intune admin center, open Tenant administration, then Audit logs. Use Date to select the investigation window. Under Add filters, choose Category and then Activity; the available activities depend on the category. Apply the filters and open the event matching the policy and operation.

Check the activity time, operation and result before drawing a conclusion. An attempted update that failed is different evidence from a successful edit. In the event details, inspect Initiated by (actor) and Target(s). Keep the resource identity with the event so that similarly named policies are not confused.

• Microsoft: view and filter Intune audit events

Interpret the actor rather than guessing from an app name

The actor data can describe a user or an application. Intune audit records include user principal name and application identity fields where available. An application name can identify the client used for the operation, so it should not automatically be read as proof that an unattended application made the decision.

Compare the recorded actor with your change record and the workflow that ran at that time. A shared automation identity may establish which process issued an operation without identifying the person who approved it. Preserve the distinction between the recorded identity, the client and the human decision rather than assigning responsibility from one display name.

The event is evidence of an operation against a target. It is not a complete history of the policy payload, a record of every approval outside Intune, or proof of which devices had applied the change when a user reported a problem. Those questions need their corresponding records.

Keep audit evidence before the window closes

Microsoft documents a date filter covering the previous year in the admin center and retrieval of two years of Intune audit events through Microsoft Graph. Route audit logs to Azure Monitor when you need a separate retention arrangement. Check access and collection before relying on a future investigation to retrieve older events.

Keep the original event export with its timestamps and object identities. If there is no matching event in the selected view, widen the date window and check category and activity filters before concluding that nobody changed the policy. A missing record in a filtered result is not a positive attribution to another admin or process.

Use the backup difference for what changed

In TenuVault, open Backup & Restore, select a saved point in Backup History and choose View Changes from Backup Details. Expand the affected item to read the setting paths and old and new values. The dialog names the backup and preceding eligible backup; use those capture times alongside the audit event time.

A snapshot comparison cannot assign each setting to an actor. Several edits can occur between captures, and the policy may have been changed back before the next one. Keep the audit operation and the saved difference together, with a note explaining whether they align or whether intermediate state remains unknown.

For recent tenant-wide investigation, Drift Detection compares the two newest complete backups and adds severity, exports and recovery actions. For an older saved point, use the backup change view. Do not describe either result as a live read of the tenant unless you first made a new backup.

Prepare the next investigation

Pro and MSP change watching can alert on selected Intune audit changes through configured channels. Actor details are off by default. If you enable them, choose destinations permitted to receive that personal data. Alerts can narrow by policy name and change type, which is useful when investigating repeated changes to a specific policy.

• Record the event and policy identities, operation result and relevant times.
• Keep the before-and-after saved points and explain any gaps.
• Use a reviewed restore plan if recovery is required, after preserving evidence.
• Check alert delivery and watcher health instead of assuming configuration alone guarantees notification.

• Set up Intune change alerts