This chapter covers Microsoft Sentinel incident management, a core skill for the SC-200 exam. You will learn how incidents are created, investigated, triaged, and resolved. This topic area represents approximately 15–20% of exam questions, often appearing in scenario-based items that test your ability to manage the full incident lifecycle. Mastering incident management is critical for passing SC-200 and for real-world security operations.
Jump to a section
Think of Microsoft Sentinel as a hospital emergency room (ER) for your entire digital environment. Incidents are like patients arriving with various symptoms (alerts). The ER triage nurse (the incident creation engine) assesses each patient's severity based on vital signs (alert severity, entity risk scores) and groups together patients who are part of the same outbreak (correlation rules, fusion). The ER doctor (the analyst) then investigates: they review the patient's chart (incident timeline), order lab tests (advanced hunting queries), and consult specialists (playbooks). The doctor documents a diagnosis (classification) and prescribes treatment (automated response via playbooks). The patient's entire journey from arrival to discharge is tracked (incident lifecycle). Just as a hospital uses an electronic health record (EHR) system to manage patient data, Sentinel uses a workspace to store all incident data. The goal is to treat (remediate) the patient (threat) effectively and efficiently, learning from each case to improve future triage (analytics rules).
What is Incident Management in Sentinel?
Incident management in Microsoft Sentinel is the process of handling security incidents from creation to closure. An incident is a collection of related alerts that together indicate a possible security threat. Sentinel automatically creates incidents based on analytics rules, fusion of multiple alerts, or integration with other Microsoft security products like Microsoft 365 Defender.
Why Incident Management Exists
In a typical SOC, analysts face alert fatigue — hundreds or thousands of alerts daily. Incidents consolidate related alerts into a single case, reducing noise and providing context. This enables efficient triage, investigation, and remediation. Sentinel's incident management provides a built-in workflow that aligns with the NIST incident response lifecycle: preparation, detection & analysis, containment & eradication, and post-incident activity.
How Incident Creation Works
Analytics Rules: Scheduled or near-real-time rules create alerts. When alerts are generated, Sentinel can automatically group them into incidents based on the rule's incident creation settings. By default, each alert becomes its own incident. You can configure rules to group alerts into a single incident if they match a specific entity (e.g., same user or IP) within a defined time window (default 5 hours, configurable up to 24 hours).
Fusion: A machine learning model correlates alerts from multiple sources to detect multi-stage attacks. Fusion creates high-fidelity incidents with a severity of 'High' or 'Critical'.
Microsoft 365 Defender Integration: Incidents from Microsoft 365 Defender are automatically synced to Sentinel. This includes alerts from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps.
Incident Components
Title: Automatically generated or customizable via automation rules.
Severity: Low, Medium, High, or Critical. Set initially by the analytics rule and can be changed manually or via automation.
Status: New, Active, or Closed.
Owner: Assigned analyst or group.
Tags: Custom labels for classification (e.g., "Phishing", "Ransomware").
Alerts: The individual alerts that make up the incident.
Entities: Related resources such as user accounts, IP addresses, hosts, and URLs. Entities are extracted from alerts and can be linked to threat intelligence.
Timeline: A chronological list of events and alerts.
Comments: Analyst notes.
Bookmarks: Saved queries or points in time for later reference.
Incident Lifecycle
Creation: An incident is created automatically by an analytics rule, fusion, or via API.
Triage: An analyst reviews the incident, assigns ownership, sets severity, and classifies it (true positive, false positive, or benign positive).
Investigation: The analyst uses the incident timeline, entity mapping, and advanced hunting to understand the scope and impact.
Remediation: Automated playbooks (logic apps) or manual actions are taken to contain and eradicate the threat.
Closure: The incident is closed with a classification and a reason (e.g., resolved, mitigated, false positive).
Automation Rules
Automation rules allow you to automate incident management tasks. They are triggered when an incident is created or updated. You can define conditions (e.g., severity is High) and actions (e.g., assign to a specific owner, change status, run a playbook). Automation rules are evaluated in order of priority (lowest number = highest priority). You can create up to 200 automation rules per workspace.
Playbooks
Playbooks are workflows built on Azure Logic Apps that automate response actions. They can be triggered from automation rules or manually from an incident. Common playbook actions include: blocking an IP address, resetting a user's password, opening a ticket in ServiceNow, or sending a message to Microsoft Teams.
Incident Investigation
Investigation Graph: A visual tool that shows connections between entities and alerts. It helps analysts understand the attack chain.
Hunting: Use KQL queries to proactively search for threats. Bookmark findings to attach to incidents.
Entity Pages: Dedicated pages for each entity (e.g., a user) that show related incidents, alerts, and threat intelligence.
Integration with Microsoft 365 Defender
Incidents from Microsoft 365 Defender are automatically ingested into Sentinel. They appear with a unique ID and are linked to the original incident in the Defender portal. Any changes made in one portal (e.g., closing the incident) are synced to the other. This bidirectional sync ensures consistency.
Key Defaults and Limits
Incident creation grouping: Default grouping window is 5 hours, can be set from 5 minutes to 24 hours.
Maximum alerts per incident: 150 alerts (if more, Sentinel creates multiple incidents).
Incident retention: 90 days by default, can be extended up to 2 years with a retention policy.
Automation rules: Up to 200 per workspace.
Playbooks: No hard limit, but Logic Apps has its own limits (e.g., 30-day timeout for workflows).
Verification Commands
In the Sentinel portal, you can view incidents by navigating to Incidents under Threat Management. Use filters to sort by severity, status, or owner. To check automation rule execution, go to Automation > Incident automation rules and select a rule to see its run history.
Interaction with Related Technologies
Azure Logic Apps: Powers playbooks. Ensure Logic Apps is in the same region as Sentinel for low latency.
Microsoft 365 Defender: Bidirectional sync for incidents. Requires appropriate licenses (E5 or separate add-ons).
Threat Intelligence: STIX/TAXII connectors bring in threat indicators that can be used in analytics rules.
Azure Active Directory: Entity enrichment for user accounts.
Azure Monitor: Underlying data platform for log analytics workspace.
Common Configuration Steps
Create analytics rules to generate incidents.
Configure automation rules to assign incidents and run playbooks.
Build playbooks in Azure Logic Apps for common response actions.
Use the investigation graph for deep analysis.
Set up Microsoft 365 Defender connector to sync incidents.
Best Practices
Use automation to reduce manual work: assign incidents based on severity, run playbooks for common threats.
Classify incidents consistently: use tags and classification fields.
Regularly review closed incidents for lessons learned.
Use the incident timeline to document the investigation process.
Troubleshooting
Incidents not created: Check analytics rule status, ensure it's enabled and producing alerts. Verify that the rule's incident creation setting is not off.
Automation rule not running: Check priority order; ensure conditions match. Review run history for errors.
Playbook failure: Verify Logic Apps permissions (managed identity or service principal). Check Logic Apps run history.
Microsoft 365 Defender incident not syncing: Ensure connector is enabled and licensed properly. Check for network connectivity.
Create an Analytics Rule
Navigate to Analytics in Sentinel and click 'Create' > 'Scheduled query rule'. Define the rule logic using KQL to detect a specific threat. Set the alert details (name, severity). Under 'Incident creation', choose 'Create incident from alerts triggered by this rule'. Optionally, enable alert grouping: select 'Group all alerts into a single incident' and set the grouping window (e.g., 5 hours). This step generates alerts and automatically creates incidents based on those alerts.
Configure an Automation Rule
Go to Automation > Incident automation rules > Create. Define conditions: e.g., 'When incident is created' and 'Severity equals High'. Set actions: e.g., 'Assign to SecOps Team' and 'Run playbook - BlockIP'. Set priority (e.g., 0 for highest). The rule will trigger automatically for new incidents matching the conditions. This reduces manual triage time.
Triage an Incident
Open the Incidents blade. Locate a new incident and click on it. Review the overview: severity, status, owner. Check the alerts and entities. Use the timeline to see the sequence of events. Change status from 'New' to 'Active'. Assign an owner. Add tags like 'Phishing' or 'Investigation'. This step is where the analyst takes ownership and begins assessment.
Investigate Using the Graph
In the incident details, click 'Investigate' to open the investigation graph. Nodes represent entities (users, IPs, hosts) and alerts. Click on a node to see details. Use the 'Explore' button to run queries. Drag and drop nodes to map relationships. This visual tool helps identify the attack path and affected assets.
Remediate and Close
Based on investigation, take action. For example, run a playbook to isolate a machine. Or manually reset a user's password. After remediation, go back to the incident, set classification (e.g., 'True Positive'), and add a comment summarizing the response. Change status to 'Closed'. Optionally, add a reason like 'Resolved'. This completes the incident lifecycle.
Enterprise Scenario 1: Large Financial Institution
A global bank uses Sentinel to monitor 50,000 endpoints and 200,000 users. They receive over 10,000 alerts daily. Without incident grouping, analysts would be overwhelmed. They configure analytics rules to group alerts by user account within a 1-hour window. Automation rules assign High severity incidents to senior analysts and run a playbook that isolates the affected device via Microsoft Defender for Endpoint. They also integrate with ServiceNow via a playbook to create a ticket for each closed incident. A common issue is that grouping windows are too short, causing duplicate incidents. They adjusted to 2 hours after analysis.
Enterprise Scenario 2: Healthcare Provider
A hospital network uses Sentinel to monitor patient data access. They have a rule that detects multiple failed logins followed by a successful login (indicator of brute force). Incidents are created with entities like user and IP. The SOC team uses the investigation graph to see if the IP is known malicious (via threat intelligence). They have a playbook that blocks the IP in Azure Firewall and sends a Teams message to the security team. Performance consideration: the Logic App timeout is set to 1 hour to ensure long-running playbooks don't fail. Misconfiguration: they initially set the grouping window to 24 hours, which caused an incident with 200 alerts (exceeding the 150 limit), resulting in multiple incidents for the same attack. They reduced it to 6 hours.
Enterprise Scenario 3: Retail Company
A large e-commerce platform uses Sentinel to protect its cloud infrastructure. They use Microsoft 365 Defender integration to bring in incidents from Defender for Cloud Apps. They have an automation rule that changes severity to 'Critical' if the incident involves a privileged user. They also use tags to mark incidents that require legal hold. A common problem is that automation rules run in order, and if a lower-priority rule changes the owner before a higher-priority rule assigns a playbook, the playbook might not run. They learned to carefully order rules: highest priority for playbooks, then owner assignment.
What SC-200 Tests
Objective 2.4: Manage incidents in Microsoft Sentinel. This includes creating, triaging, investigating, and resolving incidents. Also covers automation rules and playbooks.
Objective 2.5: Use threat intelligence to enrich incidents.
Objective 2.6: Manage Microsoft 365 Defender incidents in Sentinel.
Common Wrong Answers
Confusing automation rules with playbooks: A common trap is thinking automation rules do the actual response (like blocking an IP). In reality, automation rules trigger playbooks; the playbook does the action. On the exam, a question might ask 'How to automatically block an IP when an incident is created?' The correct answer is 'Create an automation rule that runs a playbook', not 'Create an automation rule that blocks the IP'.
Assuming incident grouping is always best: Another trap is thinking you should always group alerts into one incident. The exam tests that grouping is optional and has limits (150 alerts). If alerts are unrelated, grouping can hide issues. The correct approach is to group only when alerts share entities.
Mixing up severity and classification: Severity is set by the rule and can be changed; classification (true positive, false positive) is set at closure. A question might ask 'What field indicates whether an incident is a real threat?' The answer is 'Classification', not 'Severity'.
Forgetting bidirectional sync with Microsoft 365 Defender: Questions about incident management in a hybrid environment often test that changes in Sentinel sync to Defender and vice versa. A wrong answer might suggest changes are one-way.
Specific Numbers and Terms
Grouping window: Default 5 hours, range 5 min to 24 hours.
Max alerts per incident: 150.
Automation rules: Up to 200 per workspace.
Incident retention: 90 days (default).
Playbook trigger: Can be 'When incident is created' or 'When incident is updated'.
Fusion: Machine learning correlation, creates high/critical severity incidents.
Edge Cases
Alert grouping with different entities: If you group by user, but alerts have no user entity, they will not be grouped.
Automation rule priority: Rules with lower priority numbers run first. If two rules conflict (e.g., one assigns owner A, another assigns owner B), the rule with higher priority (lower number) wins.
Playbook failure: If a playbook fails, the incident is still created. You must check Logic Apps run history.
How to Eliminate Wrong Answers
If an answer says 'automation rule can directly block an IP', it's wrong — automation rules trigger playbooks, not actions.
If an answer says 'incident grouping is mandatory', it's wrong — it's optional.
If an answer says 'severity is final and cannot be changed', it's wrong — you can change it manually or via automation.
If an answer says 'Microsoft 365 Defender incidents are read-only in Sentinel', it's wrong — they are fully editable and sync bidirectionally.
Incidents are collections of related alerts; grouping is optional and limited to 150 alerts.
Default grouping window is 5 hours; configurable from 5 minutes to 24 hours.
Automation rules trigger playbooks, not actions directly.
Incident retention is 90 days by default; can be extended up to 2 years.
You can create up to 200 automation rules per workspace.
Microsoft 365 Defender incidents sync bidirectionally with Sentinel.
Fusion creates high/critical severity incidents from multi-stage attacks.
These come up on the exam all the time. Here's how to tell them apart.
Automation Rules
Triggered on incident creation or update.
Can change incident properties (owner, status, severity).
Cannot run custom code or API calls directly.
Evaluated in priority order (lowest number first).
Up to 200 per workspace.
Playbooks
Triggered by automation rules or manually.
Built on Azure Logic Apps.
Can run complex workflows, API calls, and conditional logic.
Have their own execution history and error handling.
No hard limit, but Logic Apps has regional limits.
Mistake
Automation rules can directly execute actions like blocking an IP.
Correct
Automation rules only trigger playbooks. The playbook (Logic App) performs the action. Automation rules cannot directly run code or execute API calls.
Mistake
Incident grouping always creates one incident per attack.
Correct
Grouping is limited to 150 alerts. If an attack generates more than 150 alerts, multiple incidents are created. Also, grouping only works if alerts share the same entity within the grouping window.
Mistake
Incident severity is set in stone once created.
Correct
Severity can be changed manually or via automation rules after creation. The initial severity comes from the analytics rule, but you can override it.
Mistake
Microsoft 365 Defender incidents in Sentinel are read-only.
Correct
They are fully editable and changes sync bidirectionally. Closing an incident in Sentinel also closes it in Microsoft 365 Defender.
Mistake
You can group alerts from different analytics rules into one incident.
Correct
Grouping only applies to alerts from the same analytics rule. To group alerts from different rules, you need to use Fusion or create a custom solution.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use an automation rule. When creating the rule, set conditions (e.g., severity equals High) and then add an action: 'Assign owner' and choose the analyst or group. The rule will automatically assign new incidents that match the conditions.
An alert is a single notification from an analytics rule indicating a potential threat. An incident is a collection of one or more alerts that are grouped together based on shared entities or time. Incidents provide a single case for investigation.
Yes. You can change severity manually from the incident details page. You can also use an automation rule to automatically change severity based on conditions (e.g., if the incident involves a privileged user).
Enable alert grouping in your analytics rule. Configure it to group alerts into a single incident based on a specific entity (e.g., user account) within a time window. This way, multiple alerts from the same attack are combined into one incident.
Sentinel will create multiple incidents, each containing up to 150 alerts. The grouping logic will try to keep related alerts together, but you may end up with several incidents for the same attack. To avoid this, adjust the grouping window or rule logic to reduce alert volume.
Use a playbook. Create a Logic App that connects to your ticketing system (e.g., ServiceNow, Jira) via its API. Then create an automation rule that runs this playbook when an incident is created or updated. The playbook will create a ticket automatically.
Yes, if you have the Microsoft 365 Defender connector enabled, incidents sync bidirectionally. Closing an incident in Sentinel will automatically close the corresponding incident in Microsoft 365 Defender, and vice versa.
You've just covered Sentinel Incident Management — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?