Queue triage, correlation, severity, ownership, investigation, containment, remediation, evidence, SLA, tuning, and shift handoff
Operate the Microsoft Defender XDR incident queue as a governed security-operations process—not a list of alerts to close. Build queue views, validate correlation and severity, assign accountable owners, reconstruct the attack story across endpoint, identity, email, cloud applications, data, and Sentinel sources, authorize response actions, preserve evidence, coordinate remediation, tune recurring noise, meet service objectives, and hand off every open incident without losing context.
Operating objective
Microsoft Defender XDR correlates related alerts, impacted entities, evidence, investigations, and response activity into incidents. In the unified Microsoft Defender portal, the queue can also include sources such as Microsoft Sentinel, Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, Entra ID Protection, Defender for Cloud, Purview, Data Loss Prevention, and other connected services. Correlation reduces alert-by-alert fragmentation, but it does not remove the need for human validation, business context, incident command, legal/privacy judgment, or recovery coordination.
The queue is the operational control plane for prioritization and ownership. Analysts use status, alert/incident severity, assignee, source, category, entity, device group, sensitivity, automation state, threat, policy, product, and data-stream filters to isolate the incidents that need attention. Microsoft supports saving useful filter combinations as URLs, making views such as new high-severity unassigned incidents, incidents assigned to a shift, or incidents from a specific service repeatable. Those views should be governed artifacts with owners and review dates.
Every new incident needs a documented triage decision: Is it a true security event, a benign positive, or an expected activity? Does correlation accurately group the attack? Which users, devices, mailboxes, applications, cloud resources, and data are impacted? Is the displayed severity proportionate to actual business impact? Is the attack active? What containment can be safely authorized? What evidence must be preserved? Who owns investigation, remediation, communications, legal/privacy notification, recovery, and closure? The incident stays open until those questions are answered or explicitly transferred.
Control statement: Every queue incident must have an accountable owner, validated severity and classification, scope statement, evidence timeline, investigation plan, containment/remediation decision, business and legal/privacy impact assessment, escalation/SLA status, communication record, recovery validation, closure rationale, and audit-ready handoff.
Queue views and prioritization
| Queue view | Purpose | Required action | Failure signal |
|---|---|---|---|
| New high-severity unassigned | Immediate sweep for potentially material attacks that lack an owner. | Acknowledge, validate active attack and impacted assets, assign incident commander/analyst, preserve evidence, and start the critical SLA. | Any incident remains unowned beyond the defined acknowledgement target. |
| New and in-progress assigned to me | Personal work queue for owned investigations and response actions. | Update scope, timeline, investigation results, pending decisions, next action, due time, blockers, and escalation. | Stale owner, no update, missed task, unresolved containment, or aging without an explicit plan. |
| Attack disruption or active automation | Review automatically contained assets, ongoing investigation, and system response. | Validate scope, business impact, containment safety, automation verdict, pending actions, false-positive risk, and need for manual expansion/rollback. | Automated action is assumed correct without analyst/business validation. |
| Unassigned medium/low backlog | Detect queue starvation and lower-severity attacks with cumulative or targeted impact. | Risk-rank by privileged/sensitive assets, recurrence, multi-source correlation, external exposure, user impact, and aging; assign or document batch disposition. | Backlog age rises, repeated detections remain untuned, or high-value entities hide in low severity. |
| Critical assets and sensitive data | Prioritize incidents affecting privileged accounts, executives, crown-jewel systems, or labeled sensitive information. | Apply enhanced escalation, evidence, legal/privacy review, containment approval, communications, and monitoring. | Portal severity is used without asset criticality or data sensitivity context. |
| Resolved in prior shift/day | Quality review of classification, determination, response, evidence, and follow-up. | Sample closure quality, reopen incomplete incidents, reconcile alerts/actions, identify tuning and control gaps, and verify follow-up ownership. | Resolved incidents lack classification, comments, remediation, evidence, or validation. |
| Recurring threat/detection/source | Find repeated false positives, recurring attacks, broken controls, or compromised assets. | Aggregate incident IDs, root causes, entities, detection logic, security gaps, submissions, exclusions, and remediation outcomes. | Analysts close the same pattern repeatedly without eliminating the cause. |
Incident correlation
An alert is a detection signal. An incident groups alerts and related context into a possible attack. Start with the incident attack story, then open each alert for detection-specific details. Confirm whether alerts belong together, whether relevant alerts are missing, and whether the incident contains multiple unrelated activities that need separate ownership.
Build first-seen and last-seen times across identities, devices, mailboxes, messages, applications, cloud resources, files, URLs, IPs, and data. Normalize time zones, ingestion delay, clock skew, and copied timestamps. Mark credential access, persistence, privilege escalation, lateral movement, collection, exfiltration, impact, and response actions.
Use incident evidence and entity pages to connect users, devices, mailboxes, apps, IPs, domains, URLs, files, certificates, cloud resources, and sensitive information. Distinguish impacted assets from related evidence and shared infrastructure. Identify privileged, externally exposed, executive, regulated, and business-critical entities.
List which services contributed alerts and which expected sources are absent. Missing endpoint onboarding, identity sensors, mailbox protection, app connectors, cloud telemetry, audit data, Sentinel connectors, or DLP signals can make an incident look smaller than it is. Record telemetry-health gaps as response risks.
Microsoft can correlate alerts automatically, but analysts may need to move alerts, merge incidents, link hunting results, or create a manual incident/alert when evidence is not represented. Preserve the reason, original IDs, affected entities, and before/after incident structure so audit history remains understandable.
Use entity-driven “Go hunt” queries and structured KQL to find related activity beyond the incident. Record query text, time range, schema/table, tenant/workspace, result count, selected rows, exports, and interpretation. Supported results can be linked to a new or existing incident, enriching the timeline and evidence.
Severity and business impact
| Dimension | Questions | Escalating evidence | Documented outcome |
|---|---|---|---|
| Attack stage and activity | Is the threat active? Has it reached credential access, persistence, lateral movement, exfiltration, or destructive impact? | New related alerts, ongoing command/control, privileged access, attacker persistence, or automated disruption. | Active/contained/eradicated state, last observed, confidence, and next monitoring point. |
| Asset and identity criticality | Are domain/tenant admins, emergency accounts, executives, finance, healthcare, production systems, or security tools involved? | Privileged role, crown-jewel system, broad administrative reach, critical service dependency, or shared account. | Criticality rating, business owner, elevated response path, and access-containment approval. |
| Data exposure | Was regulated, confidential, personal, financial, healthcare, customer, authentication, or intellectual-property data accessed or moved? | Sensitivity label, DLP/Insider Risk signal, download/export, mailbox access, cloud app transfer, or unusual volume. | Data classes, estimated records/objects, legal/privacy owner, notification decision, and evidence. |
| Scope and spread | How many users, devices, mailboxes, apps, sites, subscriptions, tenants, and geographies are affected? | Multi-source incident, multiple privileged entities, widespread token/session abuse, or rapidly increasing scope. | Known/possible affected inventory, search/query method, exclusions, and confidence. |
| Containment and recoverability | Can accounts, devices, messages, apps, indicators, and sessions be safely contained? Is clean recovery available? | Containment blocked, business-critical outage, backup uncertainty, encryption, destructive action, or persistent access. | Containment plan, approved downtime, recovery owner, RPO/RTO, validation, and residual risk. |
| External obligations | Do contract, insurance, regulator, customer, law enforcement, HR, legal, or privacy thresholds apply? | Confirmed regulated data, material business disruption, criminal activity, third-party impact, or deadline. | Decision authority, notification clock, counsel/insurer contact, preserved privilege, and communication log. |
Severity rule: Never downgrade an incident because an alert looks familiar or automation completed. Validate actual attack stage, affected critical assets, data, scope, persistence, business disruption, legal/privacy obligation, and recovery. Record who changed severity, when, why, and what new evidence supported the decision.
Twelve-step incident runbook
Open the incident, record ID/time/severity/status, capture initial properties and alerts, preserve volatile evidence, start SLA and notification clocks, tag the case, and prevent premature closure or destructive cleanup.
Assign primary analyst and incident commander where required. Identify endpoint, identity, email, cloud app, data, Sentinel, business, legal/privacy, communications, vendor, and recovery owners. Confirm availability and escalation.
Review attack story, automation/disruption markers, newest alerts, high-value entities, sensitive data, privileged activity, lateral movement, persistence, exfiltration, and business impact. Update severity only with evidence.
Normalize timestamps and document initial access, execution, persistence, credential access, discovery, movement, collection, exfiltration, impact, detections, automated actions, analyst actions, and communications.
Inventory impacted and related users, devices, mailboxes, apps, IPs, URLs, domains, files, cloud resources, messages, and data. Check onboarding, sensor, connector, audit, and service-health gaps that limit confidence.
Run approved entity and hypothesis queries over a time window before and after the known activity. Save KQL, results, exports, indicators, false matches, and linked records. Search for the same actor, technique, infrastructure, file, token, account, or behavior.
Choose proportionate actions: isolate device, disable user, revoke sessions, reset credentials, suspend app, remove messages, block indicators, restrict cloud access, or segment systems. Obtain business/legal approval for high-impact actions and define rollback.
Inspect automated investigation verdicts, automatic attack disruption, pending remediation, completed/failed actions, approvals, rejections, and scope. Validate what changed on each entity; do not treat “completed” as proof that the incident is contained.
Remove persistence, malicious artifacts, forwarding/rules, apps/consent, tokens, vulnerabilities, exposed credentials, misconfigurations, policy gaps, and compromised infrastructure. Track each task, owner, evidence, due time, exception, and verification.
Restore clean service, accounts, devices, mailboxes, apps, data, and configurations. Re-enable access in controlled stages. Validate security, business functionality, backup/restore evidence, user communications, and enhanced monitoring for recurrence.
Set true alert/benign positive/false positive and determination using evidence. Resolve only after alerts/actions are reconciled, containment and remediation are validated, owners accept recovery, and every follow-up has a named owner/date.
Complete lessons learned, root cause, detection/tuning changes, control remediation, queue/process findings, evidence package, notifications, insurer/regulator/customer commitments, metrics, ownership, and leadership review.
Investigation and evidence
Capture volatile process/network/session information, alert/incident properties, entity pages, message headers, files/hashes, URLs, IP/domain data, device timelines, identity sign-ins, cloud app activity, audit events, DLP/sensitivity context, hunting results, and timestamps before response changes the environment. Use approved secure storage and access.
Store exact query text, parameters, time range, tables/workspace, execution time, result count, selected rows, and analyst interpretation. A screenshot of a few results is not reproducible. Export or link relevant hunting records to the incident where supported and preserve hashes/IDs for material exports.
Record automated/manual actions, requester/approver, target, request/start/end time, result, failure, rollback, validation, and business impact. Reconcile incident timeline, Action Center history, individual product portals, API/ITSM records, and endpoint/network/email/cloud change logs.
Use a case/evidence ID, source, collector, collection method, time zone, hash where appropriate, storage location, access log, transfer record, retention/hold, legal privilege, and disposal authorization. Separate working analyst notes from immutable source exports and executive/legal communications.
Distinguish fact, portal verdict, analyst inference, user statement, vendor statement, and unverified assumption. Record alternative explanations, missing telemetry, time gaps, false-match risk, confidence, and tests that would confirm or refute each hypothesis.
Microsoft now supports manually creating incidents or alerts from the queue. Use this for validated activity that needs governance but is not represented by automatic detections. Define correlation behavior, metadata, affected assets, owner, evidence, and source; manually generated content flows through queue, entity, hunting, and API surfaces.
Response and automation governance
Automated investigations analyze evidence and can remediate supported threats through actions such as quarantining files, stopping processes, blocking URLs, or isolating devices. Review trigger, scope, verdict, evidence, action result, pending approval, and false-positive exposure. Automation reduces analyst workload; it does not assign business accountability.
Defender XDR can automatically contain or disable assets during high-confidence attacks. Incidents mark disruption activity. Treat it as emergency containment: verify affected entities, current attack state, business impact, whether the attacker has other access, completeness, safe rollback, and the remediation/recovery plan.
Use Action Center to review pending and completed remediation actions. Define which actions may run automatically, which require analyst approval, and which require business/legal authorization. Monitor stuck, failed, rejected, expired, duplicate, or out-of-scope actions and link the final result to incident closure.
Hunting-based custom detections can create alerts and response actions. Govern query owner, purpose, schedule, entity mapping, severity, threshold, suppression, response action, test cases, false-positive rate, change history, rollback, and expiry/review. A poorly scoped rule can create noise or unsafe automated actions.
Map incident ID, status, owner, severity, classification, entities, tasks, comments, SLA, links, and closure between Defender, Sentinel, ITSM, and orchestration systems. Define the system of record and direction of authority. Prevent duplicate tickets, status loops, owner overwrite, lost comments, and unauthorized automation.
Require additional approval for disabling privileged/business-critical users, isolating production systems, blocking shared infrastructure, deleting mail/data, revoking critical apps, resetting service credentials, taking public services offline, notifying external parties, or restoring from backup. Preserve decision and rollback evidence.
RBAC and administrative separation
Microsoft Defender unified RBAC provides centralized permissions across supported Defender services and unified portal experiences. Activation changes which model controls selected workloads. Inventory existing permissions, imported roles, device/resource scopes, Sentinel workspace roles, and service-specific exceptions before migration. Test each analyst persona.
Separate queue reader, triage analyst, investigator/hunter, endpoint responder, identity/email/cloud responder, automation approver, incident commander, auditor, detection engineer, RBAC administrator, and emergency operator. Limit data/source/device scopes where supported and avoid using Global Administrator for daily response.
Seeing an incident does not automatically justify executing every response. Split evidence access from destructive actions, approval, role assignment, integration credentials, and export. Apply phishing-resistant MFA, compliant/admin devices, dedicated accounts, session restrictions, logging, access reviews, and just-in-time privilege where practical.
Verify analysts can see intended incidents, entities, alerts, evidence, timelines, hunting tables, workspaces, device groups, mailboxes, cloud apps, and sensitive-data context—while excluded populations remain inaccessible. Missing visibility can silently understate incident scope.
When Sentinel is onboarded to the Defender portal, Azure RBAC and unified RBAC can both affect access. Microsoft notes that permission behavior can differ across Sentinel portal/data-lake experiences. Document workspace scopes, parallel roles, tenant/workspace selection, and incident ownership to prevent hidden or overexposed data.
Export role definitions, assignments, workload activation, Entra group membership, device/resource scopes, workspace roles, privileged-activation logs, access reviews, test cases, and exceptions. Review after organizational change, new integrations, incidents, and Microsoft permission-model changes.
Shift operations and handoff
| Operating event | Minimum review | Required handoff | Manager check |
|---|---|---|---|
| Shift start | New high/medium, unassigned, attack disruption, active automation, critical assets, sensitive data, aged backlog, service health, and prior handoff. | Accept named incidents/tasks, acknowledge blockers, confirm escalation contacts and critical business windows. | No high-severity/uncontained incident lacks an active owner and next action. |
| During shift | Queue refresh, new correlations/alerts, scope changes, action failures, SLA timers, communications, vendor requests, and follow-up tasks. | Incident comments/timeline updated after material evidence or action; ITSM status synchronized. | Aging and severity reflect real risk; response actions are validated, not merely requested. |
| Major incident declaration | Active attack, privileged/sensitive assets, broad scope, business impact, data exposure, recovery, legal/privacy/insurance thresholds. | Incident commander, war-room channel, decision log, reporting cadence, executive/legal owners, evidence custodian, and recovery lead. | Authority, communications, containment, evidence, and external deadlines are explicit. |
| Shift end | All assigned/open incidents, containment state, pending actions, newest evidence, hypotheses, blockers, SLA, communications, and next monitoring point. | Recipient name/time, concise incident status, completed actions, pending decisions, exact next step, due time, links, and escalation trigger. | No incident is handed off as “monitoring” without criteria, time, and owner. |
| Daily operations review | Opened/resolved/reopened, backlog, aging, false positives, recurring detections, missed SLA, automation, Action Center, telemetry gaps, and material incidents. | Corrective action owner/date, tuning candidate, control remediation, leadership note, and evidence location. | Closures are sampled for quality and incomplete cases are reopened. |
| Post-incident review | Timeline, root cause, detection/response gaps, business impact, legal/privacy decisions, recovery, evidence, communications, metrics, and commitments. | Approved lessons learned, detection/control backlog, owners/dates, validation plan, risk acceptance, and leadership review. | Actions are tracked to verified completion, not only documented. |
Classification and tuning
Evidence confirms malicious activity or a policy-violating security event. Record determination, scope, attacker/technique where known, containment, remediation, recovery, data/business impact, evidence, and follow-up. A true alert can be low impact after successful controls, but it still needs a defensible record.
The detection correctly identified the behavior, but the activity was authorized or expected. Validate the authorizer, change/ticket, actor, asset, time, scope, controls, and whether the behavior should remain detectable. Prefer narrow allow-listing and operational change over broad suppression.
The detection logic incorrectly interpreted benign activity. Preserve examples and counterexamples, query/detection details, entity/time distribution, business process, risk of missing real attacks, Microsoft/vendor submission, tuning change, pilot, regression test, approval, and rollback.
Define examples and peer review for common incident families. Compare classifications across analysts, shifts, teams, and sources. High disagreement signals unclear criteria or insufficient evidence. Use calibration sessions and reopen sampled incidents when standards are not met.
Recurring alerts caused by insecure legacy protocol, overprivilege, unmanaged device, weak mail policy, risky app consent, exposed service, or missing patch require remediation—not a permanent exclusion. Link the detection to the control owner and track risk acceptance if remediation is deferred.
Every suppression, indicator, allow/block entry, custom detection, threshold, query, automation, and exclusion needs an owner, scope, rationale, evidence, start/expiry, approval, monitoring, success metric, review date, and rollback. Remove obsolete tuning after the business process or threat changes.
Top incident-queue risks
The queue has no acknowledgement ownership or escalation, so an active attack continues while analysts assume someone else is handling it.
Analysts miss the correlated attack story, cross-domain entities, lateral movement, persistence, and business impact.
Critical identities, sensitive data, crown-jewel services, or broad scope hide inside a medium/low severity incident.
A completed automated investigation or disruption is treated as proof of containment, eradication, recovery, and business validation.
Accounts, devices, messages, apps, files, or systems are changed before volatile evidence, timelines, and custody are captured.
Unonboarded devices, sensor failures, audit gaps, stale connectors, or RBAC visibility make the incident appear smaller than reality.
The incident contains informal notes but no reproducible query, export, action history, timeline, custody, or authoritative decision record.
No owner, criteria, next check, due time, escalation trigger, or pending decision is transferred.
Recurring noise consumes analysts and hides attacks because detection tuning or the underlying control gap is never resolved.
A rushed suppression, allow list, or scope exclusion hides both benign activity and future malicious use of the same path.
Daily incident response depends on overprivileged accounts that expand compromise impact and weaken accountability.
Root-cause, detection, vulnerability, policy, recovery, legal, or business commitments disappear after queue closure.
Evidence, metrics, and recurring governance
Created-to-reviewed and created-to-assigned time by severity, shift, source, business criticality, and SLA; include unowned breaches.
First-seen/created/acknowledged-to-effective containment, with automated versus manual action, validation, failures, and residual access.
Containment-to-eradication and root-cause correction, including vulnerabilities, identities, apps, mail rules, policies, devices, and recovery.
New, in-progress, unassigned, stale, reopened, and SLA-breached incidents by severity/source/entity/owner and oldest pending action.
True alert, benign positive, false positive, disputed, changed, reopened, and sampled closure error rate by incident family and analyst.
Investigations/disruptions/actions started, completed, pending, failed, rejected, rolled back, out of scope, and validated effective.
Recurring detections, submissions, suppressions, exclusions, custom rules, false-positive reduction, missed detections, and overdue review.
Affected users/services/data, downtime, recovery, loss avoided/realized, notifications, legal/privacy decisions, and accepted residual risk.
Review new/high/unassigned, attack disruption, active automation, critical assets, sensitive data, pending actions, SLA, backlog, handoff, and service/telemetry health.
Sample closure quality, recurring incidents, hunting/detection gaps, action failures, tuning, RBAC, integrations, telemetry, vulnerabilities, and overdue remediation.
Review material incidents, trends, response objectives, business impact, root causes, control investment, legal/privacy obligations, vendor performance, exercises, and residual risk.
Related architecture and authoritative references
Frequently asked questions
An alert is a detection signal from a Defender, Sentinel, Entra, Purview, or connected source. An incident correlates related alerts, entities, evidence, investigations, and response activity into a possible attack story. Analysts should start with incident scope and chronology, then inspect each alert and source-specific evidence. Correlation still requires human validation and can be adjusted when alerts are missing, unrelated, or better represented elsewhere.
At minimum, maintain repeatable views for new high-severity unassigned, new/in-progress assigned to the current analyst or shift, attack disruption/active automation, unassigned backlog, critical assets/sensitive data, resolved quality review, and recurring detections. Microsoft supports saving useful filter combinations as URLs. Give each view an owner, purpose, SLA, escalation path, and review date.
Not automatically. Review the automation verdict, evidence, completed/pending/failed actions, affected entities, active attack state, scope, business impact, containment, eradication, recovery, recurrence monitoring, and follow-up. Resolve only when classification and determination are evidence-backed and remediation/recovery are validated or explicitly owned outside the incident with due dates.
Combine portal severity with attack stage and activity, privileged and business-critical assets, sensitive or regulated data, scope and spread, persistence, recoverability, business interruption, and external notification duties. Record who changed severity, the time, supporting evidence, confidence, and escalation decision. Never downgrade solely because an alert is familiar or automation ran.
No. Use Microsoft Defender unified RBAC and workload/resource scopes to give each analyst the evidence and response permissions required for their role. Separate investigation, destructive action, approval, automation, export, and RBAC administration. Protect privileged accounts with phishing-resistant MFA, dedicated administrative devices/accounts, logging, access review, and emergency procedures.
No. It is an operational starting point. Real incidents require authorized incident command, forensic judgment, evidence custody, business continuity, legal/privacy/compliance decisions, insurance/communications coordination, Microsoft and vendor support, and tenant-specific response. A checklist does not replace a professional audit, penetration test, forensic investigation, legal advice, or incident-response engagement.
Practical, evidence-first Microsoft security operations
IT Perfection can help Orange County and Southern California organizations design Defender XDR queue views, ownership and severity standards, shift handoff, hunting and evidence workflows, automated-response governance, unified RBAC, ITSM/Sentinel integration, false-positive tuning, service objectives, metrics, incident exercises, and remediation coordination with internal IT, security, legal, privacy, compliance, recovery, vendors, and business owners.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.
This guide is for initial operational guidance only. It does not replace legal advice, a professional cybersecurity audit, compliance assessment, penetration test, forensic investigation, malware analysis, breach-counsel advice, incident-response engagement, cyber-insurance coordination, or legal/compliance review.
