Check predefined app-policy state before claiming its detection is enabled

Source facts

Microsoft documents several predefined app-governance policies that remain visible but disabled: increased data use by an overprivileged or highly privileged app, unusual activity involving priority-account consent, and access to sensitive data. The documentation describes an optional Activate action for administrators who decide to continue using them. It also says predefined anomaly policies are nondeterministic and trigger on behavior that departs from normal patterns. Microsoft Learn.

Applicability

This check concerns the documented policies’ state, not the presence of all app-governance protection. A row in a policy list is different from an enabled detection, and an enabled anomaly policy is not a promise that every contrived test will create an alert.

DSE recommendation

Reconcile the intended detection register with each policy’s actual enabled or disabled state before asserting coverage. Ask the security owner to review why an optional policy is needed and what evidence would support retaining it. Do not reactivate every visible disabled policy simply to make an inventory count increase. Record deliberate exclusions and alternative coverage without describing either as an observed detection result.

Verification

Capture the relevant policy names and effective states from the intended tenant. Compare them with the monitoring plan and investigate unexplained differences. If an owner approves activation, verify the saved state and review subsequent operational evidence without promising deterministic alert generation. Keep the policy-state check separate from investigation of a particular application’s behavior or a claim that the application is safe.

Official references

Microsoft Learn: Predefined OAuth app policy alerts. Source reviewed September 9, 2026.