What is Microsoft Sentinel? A Practical SIEM Guide
Microsoft Sentinel is a cloud-native SIEM and SOAR platform built on Azure. It collects logs from across your environment, from Entra sign-ins to firewall traffic to endpoint alerts, and gives you one place to detect, investigate and respond to security events.
The “cloud-native” part matters more than it sounds. A traditional SIEM usually means racking hardware or standing up VMs, sizing storage in advance, and paying for capacity whether you use it or not. Sentinel runs on Azure Log Analytics, scales with your actual data volume, and you pay for what you ingest and retain. That changes the calculus for smaller teams who couldn’t previously justify a SIEM at all.
How Sentinel actually works
Data comes in through connectors: Microsoft 365, Entra ID, Defender, Azure resources, and a long list of third-party sources via Syslog, CEF, or REST API. Once it’s in, everything is queryable using Kusto Query Language, the same language behind Azure Monitor and Application Insights.
From there, three things happen:
Analytics rules run scheduled or near-real-time queries against your data and raise an incident when something matches. Microsoft ships a large library of built-in rules mapped to MITRE ATT&CK, and you can write your own in KQL for anything specific to your environment.
Machine learning adds behavioural detection on top of rule-based logic. This is where Sentinel catches things a static rule would miss: a user account behaving differently to its normal pattern, an unusual sign-in sequence, a slow-building anomaly that no single log line would flag on its own.
Threat intelligence feeds, both Microsoft’s own and any external feeds you connect, get matched against your data automatically, so a known-bad IP or domain touching your environment triggers a detection without you having to write a rule for it yourself.
SOAR: automating the response, not just the detection
Detection is only half the job. Sentinel’s playbooks, built on Azure Logic Apps, let you automate what happens after an incident fires: isolate a device, disable an account, open a ticket, notify a channel, enrich the incident with extra context before an analyst even looks at it.
For a small team this matters more than the analytics rules do. A one-person or two-person security function can’t watch a queue in real time. A well-built playbook can contain the obvious stuff automatically and leave the judgement calls for a human.
What are the options for deploying a SIEM in Azure?
There isn’t just one way to do this, and the right answer depends on what you’re starting from:
- Sentinel on a new Log Analytics workspace is the clean-slate option, and the one most organisations use if they don’t already have significant Azure Monitor investment.
- Sentinel on an existing Log Analytics workspace works if you’re already sending diagnostic logs somewhere in Azure and want to bring Sentinel on top rather than duplicating ingestion.
- Multi-workspace architectures exist for larger, multi-tenant, or MSSP scenarios, where different business units or clients need logically separated data with a unified view on top. Overkill for a single small organisation, genuinely necessary for anyone managing security across several.
- Hybrid, keeping an existing on-premises SIEM for specific legacy sources while Sentinel handles the cloud estate, is a real transitional option rather than an all-or-nothing switch.
Most small and mid-sized organisations should start with the first option and grow into complexity only if they actually need it.
Is now the time to ditch a traditional SIEM for Sentinel?
Honestly, it depends on what’s driving the traditional SIEM’s cost. If it’s the licensing and hardware overhead of running infrastructure you don’t need, and your data is already substantially in Microsoft 365 and Azure, Sentinel is very likely a real cost and capability improvement, not just a lateral move. The native integration with Defender and Entra alone removes a meaningful amount of the connector-building work a traditional SIEM ingestion pipeline usually needs.
If your environment is heavily on-premises, multi-cloud with substantial non-Microsoft infrastructure, or you’ve already sunk serious engineering time into a mature traditional SIEM setup with custom detections tuned over years, the calculation is less obvious. Migrating detection logic is real work, and “it’s cloud-native” isn’t by itself a reason to throw away a system that’s already tuned and trusted.
The honest middle ground: pilot Sentinel alongside an existing SIEM before switching entirely. Bring in a subset of high-value log sources, build out a handful of analytics rules, and see whether the detection quality and workflow actually suit your team before committing to a full migration.
Running Sentinel as a small or one-person team
This is where a lot of vendor content stops being useful, because most Sentinel guidance assumes a dedicated SOC. If you’re the whole security function, the practical priorities are different:
Start narrow. Connect your highest-value sources first (Entra sign-in logs, Defender alerts) rather than trying to onboard everything at once. A smaller, well-tuned rule set beats a huge one generating noise you don’t have time to triage.
Lean on automation early, not as a later optimisation. Every playbook you build now is an hour of manual triage you don’t have to do later, and as a small team that hour matters more than it would on a bigger one.
Budget time for tuning, not just setup. An analytics rule that fires constantly on legitimate activity gets ignored within a week, and an ignored alert is worse than no alert at all. This is the unglamorous, ongoing part of running a SIEM that nobody puts in the getting-started guide.
For more on what running security solo actually looks like day to day, see Running Security as a One-Person Team.
Frequently asked questions
Is Microsoft Sentinel actually a SIEM? Yes, and a SOAR platform on top of that. Microsoft markets it as “cloud-native SIEM and SOAR” specifically because it does both jobs: the SIEM half collects and correlates logs to detect incidents, the SOAR half (Logic Apps playbooks) automates the response once an incident fires.
Was Sentinel previously called Azure Sentinel? Yes. Microsoft renamed it from Azure Sentinel to Microsoft Sentinel in 2021, alongside a broader rebrand of Azure-hosted Microsoft 365 security tooling. You’ll still see “Azure Sentinel” in older documentation and blog posts, it’s the same product.
How does Sentinel compare to Splunk? They solve the same core problem from different starting points. Splunk is platform-agnostic by design and has a longer track record with complex, heavily customised on-premises environments; Sentinel’s advantage is native integration with Microsoft 365, Entra and Defender, so if your environment is substantially Microsoft-based, a lot of connector and correlation work Splunk would require you to build yourself comes largely pre-wired in Sentinel. Organisations with a genuinely multi-vendor, non-Microsoft-heavy estate often still find Splunk’s flexibility worth its higher operational overhead. Neither is objectively better, they suit different environments.
Do I need a Microsoft 365 E5 licence to use Sentinel? No. Sentinel is billed separately, based on data ingestion and retention, regardless of which Microsoft 365 licence tier you’re on. E5 gives you some Defender and Purview capabilities that feed useful data into Sentinel, but it isn’t a prerequisite for Sentinel itself.
Can Sentinel replace Defender, or do I need both? They’re complementary, not competing. Defender products (for Endpoint, for Identity, for Cloud Apps) do detection and response at the individual signal source. Sentinel correlates across all of those sources, plus everything else you connect, to catch patterns no single product would see on its own.
How much does it actually cost to run? It scales with data volume, which makes it hard to give a single number. The practical approach is to estimate ingestion from your highest-value sources first, use Sentinel’s cost calculator against that estimate, and expand once you have a real sense of your own data volume rather than guessing from someone else’s environment.