In this module

AD5.2 The 15-Minute Monday Security Review

5-6 hours · Module 5 · Free

Operational Objective

A security monitoring cadence only works if it's structured, repeatable, and fast enough to sustain. The 15-minute Monday security review is the core of your monitoring program — a checklist of 5 checks across 3 portals that covers all four security layers in one pass. Each check has a specific target: what you're looking for, where to find it, and what to do if you find something. After the first few weeks, the review becomes muscle memory — you navigate the same portals in the same order, scan for the same patterns, and close the review in under 15 minutes for a normal week. This subsection builds the complete checklist with exact navigation paths, expected outcomes, and escalation triggers.

Deliverable: A printed or bookmarked 5-check Monday review checklist with exact portal navigation, expected outcomes, and escalation triggers — ready to execute every Monday morning.

Estimated completion: 25 minutes

Figure AD5.2 — The 5-check Monday security review. Each check takes 3 minutes, covers one or two security layers, and has specific things to look for. Total: 15 minutes. Do it every Monday morning before other work.

Check 1: Defender Incident Queue (3 minutes)

Navigate to security.microsoft.com → Incidents & alerts → Incidents. Sort by "Last activity" (newest first) and filter by "Status: Active."

What you're looking for: Any new incidents since last Monday. The Defender portal automatically correlates alerts into incidents — a phishing email, a suspicious sign-in, and a malware detection on the same user might be correlated into a single incident telling the story of an attack chain.

Normal week: 0-3 low-severity incidents (informational alerts, policy tips triggered, benign detections). Review each briefly — check the description, the affected user, and the severity. If they're genuinely low-risk (informational alerts about safe activity that triggered a detection), classify them and close them.

Abnormal week: A medium or high-severity incident. Don't close it. Read the attack story (AD5.4). Investigate the affected user. If the incident involves a confirmed threat (credential compromise, malware execution, data exfiltration), follow the appropriate response procedure from Module AD1 (compromised account) or Module AD2 (phishing investigation).

Escalation trigger: Any incident involving data exfiltration, ransomware indicators, or multiple affected users. If your organization has a managed SOC, these are the incidents to escalate immediately.

For a faster check, use the built-in filters: set "Service source" to "Microsoft Defender for Office 365" and "Microsoft Entra ID Protection" to see only the alerts relevant to your E3 deployment. Filter out informational severity to focus on medium and high.

Navigate to entra.microsoft.com → Monitoring → Sign-in logs. Set the date range to "Last 7 days." Apply the filter: "Conditional access: Failure" — this shows every sign-in blocked by conditional access in the last week.

What you're looking for: Blocked sign-ins from unfamiliar IPs or locations. Each CA failure is a sign-in that your controls stopped — but the attempt itself may indicate credential compromise.

Normal week: 0-5 CA failures, all from known users on personal devices (BYOD accessing from home) or from the mobile app triggering a compliance check. These are expected blocks from your CA003 policy — legitimate users on non-compliant devices being directed to use app protection instead.

Abnormal week: CA failures from IPs you don't recognize, from countries where you have no employees, or for users at times they don't normally work (02:00 sign-in attempts). Each of these warrants investigation: check the IP geolocation, check the user's normal sign-in pattern, and if the sign-in is suspicious, reset the password and check MFA methods.

Additionally, filter the sign-in log by "Risk level: High" or "Risk level: Medium" (if your tenant has Entra ID Protection P1 risk detections). These are sign-ins that Microsoft's risk engine flagged as suspicious based on behavior analysis — impossible travel, unfamiliar sign-in properties, leaked credentials.

Connect-MgGraph -Scopes "AuditLog.Read.All"
$weekAgo = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")

# CA failures in the last 7 days
$caFailures = Get-MgAuditLogSignIn -Filter "createdDateTime ge $weekAgo and status/errorCode ne 0" -Top 200 |
    Where-Object { $_.ConditionalAccessStatus -eq "failure" }

Write-Host "CA failures this week: $($caFailures.Count)"
$caFailures | Select-Object CreatedDateTime, UserPrincipalName,
    @{N="IP";E={$_.IpAddress}},
    @{N="Location";E={"$($_.Location.City), $($_.Location.CountryOrRegion)"}},
    @{N="App";E={$_.AppDisplayName}} |
    Format-Table -AutoSize

Check 3: Secure Score (3 minutes)

Navigate to security.microsoft.com → Exposure management → Secure score. Note the current score and compare it to last week.

What you're looking for: Score drops. If your score dropped since last Monday, something changed — a control was disabled, a policy was modified, or a new recommendation was added that reduced your relative score.

Normal week: Score stable or slightly increased. After deploying Modules AD1-AD4, your Secure Score should be significantly higher than when you started. The score stabilises once all major controls are deployed.

Abnormal week: Score dropped 5+ points. Click "History" to see which improvement actions caused the drop. Common causes: someone disabled a CA policy for troubleshooting and forgot to re-enable it, an Intune compliance policy was modified, or Microsoft added new recommendations that your environment doesn't meet yet.

If the drop is from a disabled control (CA policy off, compliance policy removed), investigate who changed it and why. Re-enable the control if it was disabled accidentally. If it was disabled deliberately for troubleshooting, ensure it's re-enabled after the issue is resolved.

Check the top 3-5 recommended improvement actions. Each action shows the point value, the affected category (Identity, Data, Device, App), and the implementation steps. You don't need to implement every recommendation — but reviewing them weekly keeps you aware of what Microsoft considers the next highest-impact improvement for your environment.

Check 4: Email Threats (3 minutes)

Navigate to security.microsoft.com → Reports → Email & collaboration → Threat protection status. Set the date range to "Last 7 days."

What you're looking for: Phishing emails that were delivered to user inboxes (not blocked by EOP, Safe Links, or Safe Attachments). The "Delivered" count in the phishing category should be near zero — these are the emails your controls missed.

Also check the user-reported phishing queue: security.microsoft.com → Email & collaboration → Submissions → User reported. Any new reports since last Monday? Review each one — if Microsoft's verdict says "Phishing," check message trace for other recipients and remediate (AD2.10 procedure).

Normal week: 0 delivered phishing, 0-2 user reports (mostly false positives — legitimate emails that looked suspicious).

Abnormal week: Delivered phishing > 0, or a cluster of user reports about the same email. This indicates a phishing campaign that bypassed your controls — investigate using the AD2.10 procedure (scope, impact, contain).

Check 5: Device Compliance + DLP (3 minutes)

Navigate to intune.microsoft.com → Devices → Compliance → Monitor → Device compliance status. Note the compliance rate.

What you're looking for: Compliance rate below your target (95%+). Any new non-compliant devices. Any devices in grace period for more than 3 days.

Then check purview.microsoft.com → Data Loss Prevention → Activity explorer → Last 7 days. Any new DLP matches? Any overrides?

Normal week: Compliance 95%+, 0-3 DLP matches (routine, low-volume sensitive data sharing with appropriate overrides).

Abnormal week: Compliance below 95% (investigate which devices dropped out and why), or DLP match volume spike (investigate whether it's a single user or a campaign of sensitive data sharing).

The Monday review in practice

Set a recurring calendar appointment: "Security Review" every Monday at 09:00, 30 minutes. The first 15 minutes are the 5 checks. The remaining 15 minutes are for investigating anything flagged during the checks.

On most Mondays, the checks take 10 minutes and the investigation takes 0 minutes — everything is normal. On the occasional Monday when something looks wrong, the investigation takes 15-30 minutes. On the rare Monday when a genuine incident is discovered, the investigation expands into the incident response procedures from earlier modules.

Record the check results in a simple log: date, incident queue status (clear/investigating), sign-in anomalies (count), Secure Score (current value), email threats (delivered phishing count), compliance rate, DLP matches. This log feeds your quarterly report — after 13 weeks, you have 13 data points showing consistent monitoring and a stable (or improving) security posture.

Compliance Myth: "If we don't get alerts, we don't need to check"

Alert notifications catch the events that trigger rules — but they don't catch configuration drift, compliance decay, or low-and-slow attacks that don't trigger any single alert. A Secure Score drop of 8 points doesn't generate an alert. A compliance rate declining from 97% to 91% over 3 weeks doesn't generate a single alert — it's a gradual drift that only a periodic check catches. The Monday review isn't just about alerts — it's about validating that the security posture is stable. Alerts are reactive. The weekly review is proactive.

Decision point

It's Monday morning. Your incident queue shows a new medium-severity incident: "Suspicious inbox manipulation rule" for user s.chen. The incident was created on Saturday. The alert shows that a new inbox rule was created that forwards all emails containing "invoice" or "payment" to an external email address. What's your immediate action?

Option A: Close the incident — it might be a legitimate rule s.chen created for personal organization.

Option B: Investigate immediately: check the sign-in log for s.chen around the time the rule was created (was it s.chen or an attacker?), check whether s.chen has MFA (was MFA bypassed?), disable the inbox rule immediately, and check message trace for any emails that were already forwarded. If the rule was created by an attacker, execute the AD1.9 compromised account procedure.

The correct answer is Option B. Inbox rules that forward "invoice" and "payment" emails to external addresses are a hallmark of Business Email Compromise. An attacker compromises the account, creates a forwarding rule to intercept financial communications, and waits for an invoice or payment request they can redirect. This is a high-priority investigation regardless of when it was created. Disable the rule first (stop the forwarding), then investigate whether the account was compromised.

Try it: Execute your first Monday security review

Do all 5 checks right now and record the results:

1. Incident Queue: security.microsoft.com → Incidents & alerts → Incidents → Active. Count: ___ 2. Sign-In Anomalies: entra.microsoft.com → Sign-in logs → filter CA: Failure → last 7 days. Count: ___ 3. Secure Score: security.microsoft.com → Exposure management → Secure score. Score: ___ 4. Email Threats: security.microsoft.com → Reports → Threat protection status → last 7 days → Delivered phishing: ___ 5. Device + DLP: intune.microsoft.com → Compliance status: ___% | purview.microsoft.com → DLP matches: ___

Time how long the review took: ___ minutes.

Set a recurring calendar appointment for every Monday at 09:00. The checklist above is your agenda. After 4 weeks, you'll have the review down to 10-12 minutes — the navigation becomes automatic and you know exactly what "normal" looks like for your environment.

Note: The Defender portal homepage (security.microsoft.com) includes summary cards showing active incidents, devices at risk, and users at risk. These cards provide a quick visual status before you dive into the filtered queue. If all cards show green/zero, the filtered queue is likely clear. If any card shows elevated numbers, start your checks with that area.

During your Monday review, you see that your Secure Score dropped by 12 points since last Monday. No new alerts are in the incident queue. What's the most likely cause?

An attacker lowered your Secure Score — Attackers can't modify your Secure Score. It's calculated by Microsoft based on your configuration.

Microsoft changed the scoring algorithm — Possible but rare. Microsoft usually announces scoring changes and the drop would be gradual, not 12 points.

A new vulnerability was discovered that affects your environment — New vulnerabilities might add recommendations but wouldn't typically cause a 12-point drop from existing controls.

A security control was disabled or modified — check the Secure Score history to see which improvement actions lost points, then investigate whether a CA policy was turned off, a compliance policy was removed, or a configuration profile was changed — Correct. A 12-point drop indicates a significant control change. The Secure Score history shows exactly which actions lost points. Common causes: someone disabled a CA policy while troubleshooting, an Intune profile was removed during a configuration change, or MFA registration was reset for a group. Find the change, assess whether it was intentional, and re-enable if it was accidental.

Operational Artifact — Monday Security Review Checklist

Print this checklist and pin it to your monitor or bookmark it in your browser:

MONDAY SECURITY REVIEW — 15 MINUTES ☐ Check 1: Incident Queue (security.microsoft.com → Incidents) — new Active incidents? ☐ Check 2: Sign-In Anomalies (entra.microsoft.com → Sign-in logs → CA failures) — unfamiliar IPs? ☐ Check 3: Secure Score (security.microsoft.com → Secure score) — score stable? ☐ Check 4: Email Threats (security.microsoft.com → Reports → Threat protection) — delivered phishing? ☐ Check 5: Device + DLP (intune → Compliance + purview → DLP Activity) — rate stable? Matches normal?

Record results in the weekly security log. Investigate any anomalies. Escalate medium/high incidents.

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.

View Pricing See Full Syllabus