1.7 Unified Portal Operations: Daily SOC Workflow
Unified Portal Operations: Daily SOC Workflow
Introduction
This subsection is not in Microsoft Learn. It teaches the practical operational rhythm of a SOC analyst — the daily workflow that Microsoft’s product training never covers because it is organizational, not technical.
The Defender XDR portal is your workspace. Knowing where the buttons are is necessary but not sufficient. What matters is how you use the portal efficiently: what you check first, how you prioritize, when you investigate versus when you escalate, and how you document your work so the next analyst can pick up where you left off.
This subsection describes the daily workflow practiced by analysts in operational SOCs. It is based on real shift patterns, not theoretical frameworks.
Shift start routine (15 minutes)
Every shift starts the same way, regardless of what happened on the previous shift:
1. Check the incident queue (5 minutes). Filter to Status = New, sort by Severity desc. Count the new incidents. Read the names and severities. Identify anything that needs immediate attention.
2. Read the shift handover (3 minutes). If your SOC uses a handover document (Teams channel, wiki, email), read it. What was the previous shift working on? Are there open incidents assigned to the team? Any pending approvals in the Action center?
3. Check data pipeline health (5 minutes). Run the connector health query from Module 6.8 (Scenario 5 — the SOC shift-start dashboard). If a data connector stopped flowing, your detections are blind — fix this before investigating anything else.
4. Check threat analytics (2 minutes). Navigate to Threat analytics. Are there new threat reports marked “Impact” on your environment? If Microsoft published a new threat and your environment is exposed, this takes priority over the queue.
Triage rhythm
During the shift, work through the incident queue using this rhythm:
For each new incident:
- Open → 5-minute triage (subsection 1.2)
- Classify: TP, FP, BTP, or Unknown
- If FP: close with comment, move on
- If TP: assign to yourself, begin investigation or escalate to Tier 2
- If Unknown: assign, investigate, re-classify when evidence is sufficient
Time allocation guidance:
- Informational incidents: 2-5 minutes (usually FP or BTP, close quickly)
- Low severity: 5-15 minutes (often single-alert, narrow scope)
- Medium severity: 15-60 minutes (may require investigation across products)
- High severity: 60+ minutes (full investigation, may involve multiple analysts)
When to escalate
Escalate to Tier 2 or your SOC lead when:
- The incident involves a privileged account (Global Admin, domain admin, service account)
- The incident involves data exfiltration (confirmed, not suspected)
- The attacker has persisted for more than 24 hours (established foothold)
- The incident affects more than 10 users (campaign, not targeted)
- You are unsure whether to contain (the risk of a false positive containment is high)
- The incident involves legal, regulatory, or PR implications
Documentation during investigation
Every action you take during an investigation should be recorded in the incident comments. The standard format:
[Timestamp] [Analyst name] — [Action taken]
Example:
14:32 A.Doe — Triaged incident. TP confirmed. Phishing email from northgate-voicemail.com
delivered to 19 users. 5 users clicked. Proceeding to sign-in investigation.
14:45 A.Doe — Sign-in analysis confirms j.morrison compromised from 198.51.100.44 at 08:14.
Disabled account, revoked sessions. Investigating s.patel next.
15:02 A.Doe — s.patel also compromised from same IP at 08:22. Disabled, revoked.
No evidence of further lateral movement. Proceeding to eradication.
This documentation serves two purposes: (1) another analyst can pick up your investigation if your shift ends, and (2) the incident comments become the source material for the formal incident report (Module 14).
Check your understanding
1. You arrive at shift start. The incident queue has 8 new incidents (3 high, 2 medium, 3 low). Your first action after reading the queue is to check data pipeline health. Why before investigating incidents?