12.2 Configuring Alert Policies

Quick Answer: An alert policy is a rule that watches the audit log for a specific activity and fires an alert when its conditions are met. Policies are created in the Microsoft Defender portal → Policies & rules → Alert policy, and the alerts they generate appear in the unified alerts queue that Defender XDR and Microsoft Purview share. Severity, category, activity, threshold, and recipients are the five fields you set on every policy.

The Alert Policy Framework

Microsoft 365 uses a single alerting backbone across Defender XDR (endpoints, identity, email, apps) and Microsoft Purview (data loss prevention, information protection, insider risk). The same alert policy object powers both. When you create a policy in the Defender portal's Alert policy blade, you are configuring a subscription to specific audited activities; when those activities happen, the policy emits an alert into the unified alerts queue.

Creating an Alert Policy

The create-policy wizard walks through these fields in order:

1. Name and description — a clear name that will appear in the alerts queue; the description is admin-facing only.
2. Severity — Informational, Low, Medium, or High. Severity drives the icon shown in the queue and is used by SOAR and ticketing integrations; it does not by itself change the response.
3. Category — choose the closest match from the built-in list: Threat management, Data loss prevention, Mail flow, Permissions, Threat management — insider risk, and others. Category is used for filtering and for the alert policy reports.
4. Activity to detect — the audited operation that triggers the policy. Common Defender for Office 365 activities include Suspicious email sending patterns detected, Malware campaign detected after delivery, Email messages containing phish URLs removed post-delivery, Suspicious inbox forwarding rule created, Suspicious inbox manipulation rule created, and User restricted from sending email (the outbound-spam block).
5. Trigger conditions — two modes:
   • Activity is — fires on every occurrence of the activity (good for high-signal detections like a user restricted from sending email).
   • N activities in M time window — fires only when the count threshold is met within the window, e.g. "5 suspicious forwarding rules in 1 hour". This suppresses noise from single benign events.
6. Recipients to notify — up to the tenant's notification limit; each recipient gets an email when the alert fires, and the alert row in the queue is visible to anyone with the appropriate role (Security Reader, Security Operator, Security Admin, or Compliance Admin).

Built-in versus Custom Policies

Microsoft ships dozens of built-in alert policies that are on by default in most tenants — for example, Malware campaign detected after delivery, Suspicious email sending patterns detected, Email messages from a campaign removed after delivery, and Creation of inbox forwarding/redirect rule. You cannot delete built-in policies, but you can edit their severity, threshold, and recipients, or turn them off. Custom policies are for activities the built-ins do not cover or for tighter thresholds than the defaults.

The Unified Alerts Queue

When any alert policy fires, an alert row appears in Incidents & alerts → Alerts in the Microsoft Defender portal. The queue is unified: a single alert may combine signals from Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, and Purview DLP, depending on which policy fired. Each alert has a status (New, In progress, Resolved), an owner, a classification (True positive, False positive, Informational, expected activity), and a determination. The aggregation logic groups related alerts into a single incident so analysts respond to the attack story rather than to individual signals.

Alert Policies versus AIR

Automated investigation and response (AIR) is a separate, Plan 2 capability that does not depend on your alert policies. AIR is driven by built-in playbooks that trigger automatically when specific high-confidence detections occur — for example, a user clicks a malicious URL that Safe Links blocks, or a phishing message is ZAP'd after delivery. The playbook launches an investigation that hunts for related emails, URLs, and mailbox configuration across the tenant, proposes remediation actions, and writes them to the Action center for approval (or auto-approves them if the tenant is in full automation mode). Alert policies notify people; AIR performs work.

The two systems cooperate: an AIR investigation can fire an alert that appears in the unified queue, and a custom alert policy on a related activity can give an analyst the context they need to approve a pending AIR action.

Tuning Guidance

For MS-102, the defensible pattern is: (1) leave the built-in Threat management policies on; (2) raise severity to High on User restricted from sending email and Suspicious inbox forwarding rule created because both indicate possible account compromise; (3) add a custom policy for Malware campaign detected after delivery with a Low threshold if the default is too noisy; (4) route notifications to a distribution group that pages the on-call analyst; (5) review the alerts queue weekly and reclassify false positives so the queue stays actionable.