In this module
AD5.6 Configuring Alert Notifications
Figure AD5.6 — Severity-based notification strategy. High severity: email immediately, respond within 1 hour. Medium: email within 4 hours, respond within 24 hours. Low/Informational: no notification, handle during the Monday review. This prevents alert fatigue while ensuring critical events get immediate attention.
Configuring Defender portal notifications
Navigate to security.microsoft.com → Settings → Microsoft Defender XDR → Email notifications → Incidents.
Click "Add notification rule" and create:
Rule 1 — High Severity Alerts:
- Name: "High Severity — Immediate Notification"
- Severity filter: High only
- Device groups: All devices
- Recipients: Your admin email address + your mobile email (if you want phone notifications)
- Notification frequency: "Notify for every new incident" (real-time)
Rule 2 — Medium Severity Alerts:
- Name: "Medium Severity — Same Day"
- Severity filter: Medium only
- Recipients: Your admin email address only (no mobile — these don't need phone interruption)
- Notification frequency: "Notify once per day" (daily digest at a scheduled time)
Don't create notification rules for Low or Informational severity — these generate the bulk of alerts and will flood your inbox. Handle them during the Monday review.
Configuring Entra ID Protection notifications
Entra ID Protection has its own notification settings, separate from the Defender portal. Navigate to entra.microsoft.com → Protection → Identity Protection → Notifications.
Users at risk detected: Enable. Recipients: your admin email. This sends a notification when Entra ID Protection determines a user account is at risk (leaked credentials detected on the dark web, suspicious sign-in patterns). These are the identity-specific alerts that may not appear in the Defender incident queue immediately.
Weekly digest: Enable. Recipients: your admin email. This is a weekly summary of all identity risk events — a useful supplement to your Monday review that arrives automatically.
Configure the notification threshold to "Medium and above" — this filters out low-confidence detections that are usually false positives (single failed sign-in from an unusual location) while keeping the meaningful ones (impossible travel, leaked credentials, anonymous IP sign-in).
Configuring DLP alert notifications
DLP alerts are configured within each DLP policy (AD4.7-AD4.8). Verify that your DLP policies send incident reports to your admin email:
Navigate to purview.microsoft.com → Data Loss Prevention → Policies → select each policy → Edit → Incident reports → verify your email address is listed.
For high-volume DLP matches, set the incident report to "Send when activity matches the rule" for high-severity rules only. For low-severity rules (single SIT match, user override), set to "Use the default notification" which aggregates into the Activity Explorer rather than sending individual emails.
Building the notification inbox filter
After configuring all notification sources, you'll receive emails from three senders: the Defender portal, Entra ID Protection, and Purview DLP. Create an Outlook rule that moves these notifications into a dedicated "Security Alerts" folder:
In Outlook, create a rule: if the sender contains "microsoft.com" AND the subject contains "security alert" OR "incident" OR "identity protection" OR "DLP" → move to "Security Alerts" folder AND mark as important.
This keeps security notifications visible without cluttering your main inbox. During the Monday review, check the Security Alerts folder first. During the week, scan it when you see a new email arrive — high-severity notifications need immediate attention, medium severity can wait until your next break.
# Verify your Entra ID notification settings
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityProtectionPolicy | Select-Object NotificationsEnabled,
WeeklyDigestEnabled, NotificationRecipients | Format-ListSetting response time expectations
Document your response time commitments and share them with your manager. This sets expectations and provides cover when you're asked "why wasn't this investigated at 02:00?"
| Severity | Notification | Response Time | Action |
|---|---|---|---|
| High | Immediate email | Within 1 hour during business hours, next business day for after-hours | Investigate + respond per AD1.9/AD2.10 |
| Medium | Daily digest | Within 24 hours | Investigate during next working day |
| Low | None | Within 7 days | Handle during Monday review |
| Informational | None | Within 7 days | Batch classify during Monday review |
For after-hours high-severity alerts: you're an IT administrator, not an on-call SOC analyst. Unless your organization has explicitly assigned you after-hours security responsibility (with on-call compensation), high-severity alerts received after 18:00 are investigated the next business morning. Document this boundary clearly. If the organization needs 24/7 response capability, that's a managed SOC service — not an IT administrator checking email at midnight.
If you have a managed SOC partner (like NE's BlueVoyant), they handle after-hours high-severity alerts. Your notification rules are your daytime supplement — the managed SOC provides the 24/7 coverage.
It's 22:00 on a Wednesday. You receive a high-severity notification on your phone: "Multi-stage attack involving user r.williams — credential compromise and suspicious inbox modification." You're not on-call and your organization has a managed SOC partner. What do you do?
Option A: Investigate immediately — it's a high-severity alert.
Option B: Forward the notification to the managed SOC partner's escalation email with a note: "High severity incident for r.williams at 22:00. I'm not on-call. Please investigate and contain if confirmed. I'll review first thing tomorrow morning." Then investigate in the morning.
Option C: Wait until Monday — it'll be in the incident queue.
The correct answer is Option B. The managed SOC exists for exactly this scenario — after-hours high-severity incidents that need immediate investigation. Forward the alert to them for immediate containment (session revocation, account disable if needed). Then investigate the details yourself the next morning when you can check the sign-in log, review the inbox rules, and complete the response. Waiting until Monday (Option C) gives the attacker 4+ days of access if the SOC doesn't catch it independently. Investigating at 22:00 yourself (Option A) is heroic but unsustainable — and if you make a mistake at 22:00, the consequence is worse than a delayed response at 09:00.
# Check existing alert suppression rules
Connect-MgGraph -Scopes "SecurityActions.Read.All"
# Note: Alert tuning rules are typically managed via the portal UI
# Document your suppression rules for quarterly review:
Write-Host "=== ALERT SUPPRESSION RULES ==="
Write-Host "1. Impossible travel — CEO (s.chen) — expires 2026-07-01"
Write-Host "2. Service principal sign-in — MarketingAutomation app — expires 2026-07-01"
Write-Host "Review and renew quarterly"Try it: Configure your alert notifications
1. Defender portal: security.microsoft.com → Settings → Microsoft Defender XDR → Email notifications → Incidents. Create the High Severity rule (immediate, to your admin email). Create the Medium Severity rule (daily digest).
2. Entra ID Protection: entra.microsoft.com → Protection → Identity Protection → Notifications. Enable "Users at risk" and "Weekly digest" to your admin email.
3. DLP: purview.microsoft.com → DLP → Policies → verify each policy sends incident reports to your admin email.
4. Outlook rule: Create a rule that moves security notification emails to a "Security Alerts" folder.
5. Test: Trigger a test by sending yourself a phishing test email (from a personal account with a suspicious subject). Within 24 hours, you should receive a notification from the Defender portal about the detection.
Document the notification configuration in your security configuration register alongside your CA policies, compliance policies, and DLP policies.
Suppressing known false positive alerts
After a few weeks of monitoring, you'll identify recurring false positives — alerts that fire repeatedly for legitimate activity. Common examples: an executive who travels frequently triggers impossible travel alerts weekly. A scanning tool used by IT triggers suspicious PowerShell execution. A marketing tool authenticates via service principal from a cloud IP that triggers unfamiliar location.
Rather than classifying the same FP every week, create a suppression rule in the Defender portal. Navigate to security.microsoft.com → Settings → Microsoft Defender XDR → Alert tuning. Click "Add a tuning rule."
Rule settings: Specify the alert type to suppress (e.g., "Impossible travel activity"), the entity to apply the suppression to (e.g., specific user UPN), and the action (hide alert or resolve automatically). Set an expiration: don't suppress indefinitely — set it for 90 days and review when it expires.
Document every suppression rule with: what's suppressed, why, who approved it, and when it expires. Review suppression rules quarterly — a suppression that was valid 6 months ago may no longer be appropriate (the executive no longer travels, the marketing tool was decommissioned, or the attacker is now using the same pattern the suppression hides).
Routing alerts to Microsoft Teams
For organizations that live in Teams, routing high-severity alerts to a Teams channel provides visibility to a wider group without relying on individual email notifications.
Navigate to security.microsoft.com → Settings → Microsoft Defender XDR → Email notifications → Incidents. When creating a notification rule, you can specify a Teams channel webhook as a recipient. Alternatively, use Power Automate to create a flow that triggers when a Defender incident is created (severity: High) and posts a message to a Teams channel.
The Teams channel approach works well for organizations with multiple IT staff who share security responsibility. Instead of one person receiving all notifications, the entire IT team sees the alert in a shared channel. Whoever is available first can begin the investigation. Add a reaction emoji convention: thumbs-up means "I'm investigating," checkmark means "resolved."
For solo IT administrators (the typical Admin to Defender learner), email notifications to your admin inbox are simpler and sufficient. The Teams channel approach is more useful when you have 2-3 IT staff sharing the monitoring workload.
Testing your notification pipeline
After configuring notifications, verify they work end-to-end. Don't wait for a real incident to discover that your notifications aren't configured correctly.
Test 1 — Trigger a known detection. From a personal device (not your work device), attempt to sign in to your work account. If your CA003 policy blocks the sign-in (the personal device isn't compliant), this generates a CA failure in the sign-in log. Depending on your Entra ID Protection configuration, it may also trigger a risk detection. Check whether you receive a notification.
Test 2 — Check notification delivery. After triggering the test, verify the notification arrives within the expected timeframe: immediately for high-severity rules, within 4 hours for medium (daily digest). If the notification doesn't arrive, check: is the notification rule enabled? Is your email address correct? Is the notification rule filtering to the right severity level?
Test 3 — Verify the Outlook rule. Send yourself a test email with "security alert" in the subject. Does it land in your "Security Alerts" folder? If not, adjust the Outlook rule conditions.
Run this test pipeline once during initial setup and again after any configuration change. A notification system you haven't tested is a notification system you can't rely on.
You're reading the free modules of M365 Security: From Admin to Defender
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.