Key takeaways
- Microsoft Sentinel is a cloud-native SIEM with built-in automation, so detection, investigation and response sit in one platform.
- You pay Microsoft for the data you ingest. Several Microsoft sources are free, and commitment tiers start at 100 GB a day.
- Sentinel only protects you when someone connects the right data, tunes the detection rules and watches incidents around the clock.
- After 31 March 2027, Sentinel will be available only in the Microsoft Defender portal, so teams still using the Azure portal need to plan the move.
- Most mid-sized teams choose between running Sentinel in-house, co-managing it or using a fully managed service, and the deciding factors are staff and hours of cover.
Microsoft Sentinel is Microsoft’s cloud SIEM: it collects security data from across your business, detects threats and helps your team respond to them. This guide explains how it works, what it costs, what it takes to run day to day, and how to decide between running it yourself and handing it to a provider. Every Microsoft fact links to Microsoft’s own documentation.
What is Microsoft Sentinel, and what is it used for?
Microsoft Sentinel is Microsoft’s cloud-native SIEM and SOAR platform. It collects security data from Microsoft and non-Microsoft sources, detects threats using analytics and threat intelligence, and automates the response.
A SIEM (security information and event management) system pulls logs and alerts from across your environment into one place. That lets analysts spot attacks that no single tool would see on its own. Businesses use a SIEM for three main reasons: to detect threats early, to investigate incidents with the full picture, and to keep the log trail that auditors and regulators ask for.
Sentinel goes further than a classic SIEM in two ways:
- SOAR (security orchestration, automation and response): routine responses, such as disabling an account, can run automatically.
- User and entity behaviour analytics (UEBA): Sentinel learns what normal looks like for each user and device, and flags unusual activity.
Sentinel runs on a Log Analytics workspace inside your own Azure subscription, so your security data stays in your tenant. There is no hardware to buy and no servers to patch.
In practice, mid-sized businesses use Microsoft Sentinel to:
- spot compromised Microsoft 365 accounts from unusual sign-ins
- correlate alerts from Microsoft Defender, firewalls and cloud platforms into single incidents
- hunt for threats across months of log data
- keep security logs for audits and compliance
- automate first response, such as blocking a user or opening a ticket
Microsoft Sentinel was called Azure Sentinel until Microsoft renamed it at Ignite in November 2021. Both names refer to the same product.
SIEM vs SOAR vs XDR at a glance
Sentinel and Defender XDR work together. Defender XDR protects the devices, identities and email it manages directly, and Sentinel adds the data from everything else, such as firewalls, other clouds and business applications. For a closer look at the automation side, read how SIEM and SOAR differ. For a closer look at the automation side, read how SIEM and SOAR differ.
How does Microsoft Sentinel work?
Microsoft Sentinel works in four stages. It collects security data, detects threats, helps analysts investigate them, and responds automatically wherever you allow it to.
1. Collect
Sentinel pulls in data through data connectors. There are built-in connectors for Microsoft 365, Microsoft Defender, Entra ID and Azure, and others for firewalls, other clouds and business applications. Devices without a ready-made connector can send logs over CEF, Syslog or a REST API, or through a custom connector.
Sentinel then normalises the data (ASIM) so that a sign-in looks the same whichever system it came from. Data you need to keep but rarely query can sit in the cheaper Sentinel data lake.
2. Detect
Analytics rules scan incoming data for suspicious patterns and group related alerts into a single incident. That way an analyst sees one attack, not fifty separate alerts. Several tools add to detection:
- Threat intelligence flags known bad IP addresses and domains.
- Watchlists hold your own lists, such as VIP users or approved locations.
- A MITRE ATT&CK coverage view shows which attack techniques your rules cover and where the gaps are.
3. Investigate
Each incident opens with an investigation graph showing the users, devices and IP addresses involved and how they connect. Analysts can also hunt for threats that no rule caught, using saved queries, and run deeper analysis in Jupyter notebooks.
4. Respond
Automation rules handle routine steps, such as assigning, tagging or closing incidents. Playbooks, built on Azure Logic Apps, take action in other systems.
For example, an attacker might try a password many times from an unusual country. A playbook can block the account, open a ServiceNow ticket and alert the team on Microsoft Teams, all before an analyst picks up the incident.
How does Microsoft Sentinel use AI?
Microsoft Sentinel uses AI in three main ways:
- Machine learning in detection: some built-in analytics use machine learning to find unusual patterns.
- User and entity behaviour analytics (UEBA): Sentinel builds a baseline for each user and device, and flags activity that breaks from it.
- Generative AI: Microsoft Security Copilot can summarise incidents and suggest next steps, and the Sentinel MCP server lets AI agents query your security data. Some of these AI tools are billed separately, through Security Compute Units.
AI speeds up triage, but it does not replace the analyst who decides whether an incident is real and what to do about it.
What is Microsoft Sentinel good at, and where does it need help?
Microsoft Sentinel is strongest where your business already runs on Microsoft 365 and Azure. Many of those signals connect natively, and several are free to ingest.
Where Sentinel is a strong fit
- Identity attacks: Entra ID sign-ins show stolen passwords, impossible travel and password spraying.
- Microsoft 365 activity: Office 365 audit logs show mailbox, SharePoint and Teams changes.
- Microsoft Defender alerts: alerts from endpoints, email and cloud apps become part of wider incidents.
- Azure activity: changes to your cloud resources are logged and checked.
The real value comes from connecting these signals. Take a common phishing attack:
- A user signs in with a valid password from a new location.
- Minutes later, a new inbox rule starts forwarding their email outside the company.
- An unfamiliar app is then granted access to the mailbox.
Each event looks harmless on its own. Together, they look like account takeover. A SIEM like Sentinel exists to catch exactly that pattern.
Where Sentinel needs work
- Non-Microsoft sources: firewalls, other clouds and older systems can be connected, but they need connector setup, parsing and testing. Read more on how cloud SIEM compares with on-premises SIEM.
- Noisy logs: high-volume, low-value data raises your bill without improving detection.
- Ongoing attention: Sentinel is not antivirus or a firewall, and it is not set-and-forget. Microsoft Defender protects each entry point. Sentinel connects the events across them, and someone still has to tune the rules and act on the incidents.
Book a call with CyberQuell to have your Microsoft Sentinel environment monitored 24/7, with a 15-minute response SLA on critical and high-severity alerts and your workspace kept in your own tenant.
How much does Microsoft Sentinel cost?
You pay Microsoft for the data Microsoft Sentinel ingests and stores. You can pay as you go or sign up for a commitment tier, starting at 100 GB a day, and several Microsoft data sources are free. Prices vary by region, so check Microsoft’s Sentinel pricing page for current rates.
The biggest factor in your bill is how much data you send in. Every new log source adds cost and alert noise, so the aim is to collect smart, not to collect everything.
What you pay for
A few details catch people out:
- Alerts are free, but raw logs are not. Alerts from Defender products cost nothing to ingest. Raw Microsoft Defender data and Entra ID sign-in logs are paid.
- Commitment tiers lock in for 31 days. You can raise a tier at any time, but you can only lower it 31 days after your last change, and raising it restarts that 31-day period.
- Microsoft 365 E5 does not include Sentinel. However, E5, E7, A5, F5 and G5 customers get up to 5 MB per user per day of Microsoft 365 data free. For a 200-person company, that works out to about 1 GB a day.
- There is a smaller promotional tier. Microsoft offers a 50 GB a day commitment tier for smaller customers who sign up by 31 December 2026, with the price held until 31 March 2027 (pricing page).
- The portal move costs nothing. Moving Sentinel to the Defender portal adds no extra charge.
What makes bills grow
- A new connector that brings in more data than expected
- A spike in log volume during an incident
- Longer retention than you actually need
- Connectors left running that nobody uses
How to keep Microsoft Sentinel costs under control
Microsoft’s guidance on reducing Sentinel costs comes down to a few habits:
- Connect the free sources first.
- Filter out low-value data before it is ingested, using data collection rules.
- Send logs you must keep but rarely search to the data lake tier.
- Move to a commitment tier once your daily volume is steady.
- Pre-purchase commit units for a one-year term.
- Keep non-security data in a separate workspace.
- At 100 GB a day or more, consider a dedicated cluster.
- Track spend each month with the Workspace Usage Report workbook.
To estimate your own bill, use the Azure pricing calculator with your expected daily data volume.
For a full breakdown of what running a SIEM costs once staff and monitoring are added, read what SIEM as a service includes and what it costs.
For a line-by-line breakdown of tiers and worked monthly bills, read Microsoft Sentinel pricing explained.
What does it take to run Microsoft Sentinel well?
Microsoft Sentinel needs ongoing work after setup. Someone has to review incidents, tune detection rules, maintain automation, hunt for threats and watch costs, ideally around the clock.
Microsoft’s deployment guide splits the work across three roles:
- SOC architect: plans the workspace, data sources and costs.
- SOC analyst: deploys Sentinel and its content, and handles incidents.
- SOC engineer: fine-tunes rules, automation and coverage over time.
In a mid-sized business, one or two people often cover all three, alongside their regular IT work.
The recurring work
Where in-house teams usually struggle
- Hours of cover: a week has 168 hours and a standard working week covers about 40. Watching incidents around the clock takes shifts, not one person.
- Alert fatigue: untuned rules flood the queue, and real incidents get missed among the false alarms.
- Broken connectors: a data source that silently stops sending logs leaves a blind spot nobody notices.
- Skills: writing and tuning detections needs KQL (Kusto Query Language), the query language Sentinel uses.
How to tell it is working
Track three measures each month:
- the time from attack to detection
- the time from detection to response
- the share of alerts that turn out to be false alarms
All three should fall as rules are tuned.
If nobody on your team owns these tasks, you can have a managed service run Sentinel for you.
How are incidents handled in Microsoft Sentinel, from alert to recovery?
When Microsoft Sentinel raises an incident, analysts:
- triage it
- investigate how far it reaches
- contain the threat
- remove it
- recover the affected systems
- record what was learned
NIST’s incident response guidance, SP 800-61 Rev. 3 (April 2025), places this work within the wider NIST Cybersecurity Framework 2.0. Response is treated as part of everyday risk management, not a one-off emergency.
What each step looks like in Sentinel
What to automate and what to keep human
Automation works best for fast, low-risk steps:
- enriching an incident with threat intelligence
- notifying the right people
- disabling a clearly compromised account at night
Decisions with business impact still need a person. Examples are shutting down a server, resetting an executive’s access or telling customers. Agree these limits in writing before an incident happens, not during one.
Microsoft follows the same pattern for its own cloud services. Its containment, eradication and recovery process moves from limiting damage, to removing the threat, to restoring normal service.
For businesses without analysts on shift, 24/7 SOC monitoring and response covers these steps around the clock.
What changes for Microsoft Sentinel in the Defender portal in 2027?
After 31 March 2027, Microsoft Sentinel will be available only in the Microsoft Defender portal. Teams still working in the Azure portal need to plan the move now.
What you need to know
- No extra licence needed. Sentinel works in the Defender portal even if you don’t use Defender XDR or hold an E5 licence.
- No extra cost. Moving to the Defender portal does not change your Sentinel bill.
- New customers may already be there. Since July 2025, most new Sentinel customers have been onboarded to the Defender portal automatically.
- One incident queue. Sentinel and Defender XDR incidents appear together, and the Defender XDR engine correlates their alerts.
What changes for your analysts and automation
- The Fusion detection rule is switched off. The Defender XDR engine takes over alert correlation, so no correlation is lost.
- Every incident shows “Microsoft XDR” as its provider, and the incident provider condition is removed from automation rules. Rules that relied on it will run on all incidents.
- Playbooks may trigger up to 5 minutes later than before, and automation rules up to 10 minutes later.
- Some API and automation-rule behaviours change, so test integrations such as ticketing before you switch.
Before you move: a short checklist
- Review Microsoft’s onboarding prerequisites and the new unified role-based access control for the Defender portal.
- List the automation rules that use the incident provider, incident title or incident description as a condition, and update them.
- Check that ticketing integrations such as ServiceNow still work, because incident descriptions no longer sync to them.
- Train analysts on the combined incident queue in the Defender portal.
- After the move, check that incidents and playbooks arrive as expected, allowing for the delays above.
See how Microsoft Sentinel and Defender XDR differ.
How do you set up Microsoft Sentinel? A deployment checklist
Microsoft splits a Sentinel rollout into three phases: plan and prepare, deploy, then fine-tune and review. The checklist below follows Microsoft’s deployment guide. The best approach is to start small with your most valuable data sources and add more in phases.
Phase 1: Plan and prepare
- Check the Azure tenant prerequisites, including an Azure subscription and access to the data sources you plan to connect.
- Design your Log Analytics workspace. Decide whether you need one tenant or several, what compliance rules apply to where data is stored, and who can see the data.
- Prioritise your data connectors. Start with the sources that give the most security value, such as identity, email and endpoints.
- Plan roles and permissions so each person only sees and does what their job needs.
- Plan your costs, covering data ingestion, retention and any playbooks.
Phase 2: Deploy
- Enable Microsoft Sentinel, its health and audit feature, and the content solutions you need.
- Configure data connectors, analytics rules, automation rules, playbooks, workbooks and watchlists.
- Set up multiple workspaces if your environment needs them.
- Turn on user and entity behaviour analytics (UEBA).
- Configure the Sentinel data lake for data you need to keep long term.
Phase 3: Fine-tune and review
- Check that incidents reflect what is really happening in your environment.
- Tune analytics rules and handle false positives.
- Confirm that automation rules and playbooks respond as expected.
- Keep watchlists up to date as users and systems change.
- Review your commitment tier and track ingestion costs.
- Refine data collection rules to filter out irrelevant data.
- Check your rules against the MITRE ATT&CK framework to find coverage gaps.
- Set up a regular threat-hunting routine.
Moving from another SIEM
If you are replacing an existing SIEM, Microsoft has a dedicated migration guide. Three practices reduce the risk:
- Run both systems side by side until Sentinel’s detections are proven.
- Rebuild only the detections you actually need, not every old rule.
- Watch ingestion costs closely as each new source is connected.
With a managed provider, setup can be much faster. CyberQuell gets most managed Sentinel environments live within 72 hours of signing.
If you’re moving from Splunk, read our Splunk to Microsoft Sentinel comparison and migration guide.
Should you run Microsoft Sentinel in-house, co-managed or fully managed?
Each option fits a different team:
- In-house: you have analysts covering every hour of the day.
- Co-managed: you have a security team but need help with nights, weekends or specialist depth.
- Fully managed: security operations is nobody’s full-time job.
Is Sentinel the right SIEM in the first place?
Sentinel is usually a good fit if:
- your business runs mainly on Microsoft 365 and Azure
- you work in a regulated industry that needs long log retention
- you are replacing an older on-premises SIEM
If your estate is spread heavily across other clouds, compare options first.
How the three models compare
For a neutral view on staffing, NIST’s guide to building a small business cybersecurity team, from in-house to outsourcing walks through the trade-offs.
Questions to ask any managed Sentinel provider
- Which hours are actually covered, and by whom?
- How is the response SLA measured: from alert, from triage, or from your approval?
- Does the Sentinel workspace stay in your own tenant?
- How does the provider access it? Sentinel supports Azure Lighthouse, which gives access you can see and revoke.
- What happens to your rules, playbooks and data if you leave?
- What is the pricing model: per GB, per device or per user?
CISA’s risk considerations for managed service provider customers covers further checks on access, contracts and accountability.
For a closer look at how a managed detection service differs from running a SIEM yourself, read MDR vs SIEM.
CyberQuell offers a fully managed service. CyberQuell’s managed Sentinel service works like this:
- it monitors your environment 24/7
- it includes a 15-minute response SLA on critical and high-severity alerts
- your workspace stays in your own tenant
- access is through Azure Lighthouse
- pricing is a fixed monthly fee based on the devices monitored, with no setup fees
Final thoughts
Microsoft Sentinel gives mid-sized businesses an enterprise-grade SIEM without hardware to buy or servers to maintain. It is strongest where your estate already runs on Microsoft 365 and Azure, and its pay-for-what-you-ingest pricing stays manageable when you connect the free sources first and filter out low-value data. The platform is only half the job, though. Sentinel protects you when someone connects the right data, tunes the rules, watches incidents around the clock and acts quickly when something is real. With the move to the Defender portal due by 31 March 2027, now is a good time to decide who will do that work: your own team, a co-managed partner or a fully managed provider. If running Sentinel day to day is more than your team can take on, Book a call with CyberQuell to get your Microsoft Sentinel environment monitored 24/7. That includes a 15-minute response SLA on critical and high-severity alerts, and your workspace stays in your own tenant.
.png)
