Microsoft Sentinel is now more than the original Azure SIEM experience
Microsoft’s current Sentinel overview describes Microsoft Sentinel as a cloud-native SIEM and broader unified security platform with detection, investigation, hunting, response, automation, data lake and newer AI-ready platform capabilities. The product has evolved substantially, so older implementation patterns should be reviewed rather than copied unchanged.
Microsoft also states that after March 31, 2027, Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal. Organizations designing processes in 2026 should therefore make the Defender portal experience part of training, operating procedures and integration planning.
| Design area | Question to answer | Typical output |
|---|---|---|
| Use cases | Which attacks or risky behaviors must the SOC detect? | Prioritized detection roadmap |
| Data sources | Which logs provide the evidence for those use cases? | Log-source matrix and ingestion path |
| Analytics | How will events become actionable detections? | Rule design, thresholds, tuning plan |
| Incidents | How will alerts be grouped, investigated and escalated? | SOC workflow and severity model |
| Automation | Which repetitive steps are safe to automate? | Playbooks / automation roadmap |
| Hunting | Which hypotheses need proactive investigation? | Hunting queries and cadence |
| Data lifecycle | Which data belongs in analytics vs longer-term lower-cost tiers? | Tier and retention design |
| Cost | How will ingestion, retention and related services be governed? | Cost model, budgets and monthly review |
Start with use cases, not connectors
Sentinel supports many data connectors and solutions. A connector is not a security outcome. Before onboarding a source, define the incident or investigation question the data helps answer. For example: privileged role abuse, suspicious sign-ins, endpoint compromise, malicious cloud-resource changes, network exploitation, data exfiltration or vulnerable workload activity.
Then map the minimum useful telemetry. This use-case-first approach reduces unnecessary ingestion, improves parser and normalization decisions, and gives analysts a reason to care about data quality. It also exposes gaps: a desired detection may depend on a log source the organization does not collect or on an identity/device control outside Sentinel.
Decision rule: ingest data into the analytics path when it supports a defined detection, investigation, compliance, or operational use case—not simply because a connector exists.
Build a log-source matrix before calculating cost
| Data source | Security purpose | Expected volume | Retention need | Owner |
|---|---|---|---|---|
| Microsoft Entra sign-in/audit | Identity detection and investigation | Estimate from tenant activity | Based on investigation/compliance need | Identity/SOC |
| Defender XDR / Defender alerts | Correlate endpoint/cloud incidents | Product-dependent | Follow product/SOC design | SOC |
| Azure Activity Log | Control-plane changes | Subscription activity | Investigation requirement | Cloud/SOC |
| Network/security devices | Ingress/egress and threat signals | Device/traffic dependent | Use-case dependent | Network/SOC |
| Servers/app logs | Workload-specific detection | Highly variable | Only justified sources/fields | Workload/SOC |
| Third-party SaaS | Business/security activity | Connector dependent | Use-case dependent | App owner/SOC |
The matrix should include estimated daily volume, peak behavior, parsing requirements, expected detections, retention and owner. This becomes the foundation for both architecture and pricing.
Sentinel pricing is a data architecture decision
Microsoft’s current Sentinel billing guidance explains that pricing depends on the data tier and includes pay-as-you-go and commitment options for analytics-tier ingestion, along with newer data-lake tier meters for ingestion, processing, storage, queries and advanced data-insight compute. Exact prices should be taken from current Microsoft pricing at design time.
The important design point is that not all security data needs the same latency and analytic capability. High-value, frequently queried detection data may justify the analytics tier. Lower-fidelity, secondary or long-term data may fit the data lake depending on use cases and current product capabilities. The architecture should classify data rather than applying one retention rule to everything.
Commitment tiers should follow stable data volume
Microsoft currently documents analytics commitment tiers beginning at defined daily ingestion levels and allows customers to adjust tiers under specific rules. The commercial decision should be based on an observed or well-modeled baseline, not an optimistic future ingest volume.
During a pilot, measure daily ingestion by table and source. Identify noisy sources, duplication, parsing problems and data that does not support use cases before purchasing a larger commitment. As with Azure compute commitments, a discounted rate does not make unnecessary consumption valuable.
Control ingestion before cutting detection
Microsoft’s current cost-reduction guidance for Sentinel includes options such as selecting appropriate pricing tiers, separating non-security data, using data-lake capabilities for suitable data, adjusting retention, and using data collection rules for certain Windows Security Events. These techniques should be evaluated against use cases.
The safest optimization order is to remove duplicate or low-value data, filter unnecessary fields/events where supported, tune verbose sources, classify data by analytic need, then adjust retention and commitments. Do not remove a log source simply because it is expensive if it supports a high-priority detection or investigation requirement.
Detection engineering needs a quality loop
Out-of-box analytics can accelerate deployment, but every environment has different users, applications, service accounts, network patterns and business hours. Rules should be tuned using alert history and analyst feedback. A detection that generates hundreds of benign alerts teaches analysts to ignore it.
| Detection quality signal | What it may mean | Action |
|---|---|---|
| High alert volume, low incident value | Threshold too broad or source noisy | Tune logic, exclusions or source quality |
| Repeated false positives from service accounts | Known behavior not modeled | Add controlled entity/context exclusions |
| No alerts for a high-risk use case | Data or logic gap | Test data, connector, parser and rule |
| Alert has no investigation context | Entities or normalization weak | Improve mapping/enrichment |
| Incident closes without follow-up | No learning loop | Feed analyst disposition into rule tuning |
Severity should map to business impact
Sentinel can provide alert severity, but the SOC should define its own incident severity model. A suspicious event affecting a privileged identity or critical production system can matter more than the same technical signal in an isolated lab. Enrichment with asset criticality, identity risk, threat intelligence and business ownership can improve prioritization.
The operating model should define who can raise or lower severity, when business owners are engaged, and which incidents require executive communication.
Automation should remove repetitive work, not judgment
Sentinel automation and playbooks can enrich incidents, notify owners, collect context, update tickets, block indicators or take containment actions. Start with low-risk repetitive steps. High-impact containment—disabling privileged accounts, isolating systems, blocking production traffic—should have clear authority and safeguards.
A good automation roadmap includes rollback, error handling and ownership. A playbook that silently fails during an incident can create false confidence.
The SOC operating model matters as much as the SIEM
| SOC responsibility | Decision to define |
|---|---|
| Monitoring coverage | Hours, severities and on-call expectations |
| Triage | Who reviews new incidents and within what target |
| Investigation | Which team owns identity, endpoint, cloud, network and application context |
| Containment | Which actions are preapproved and which require customer authorization |
| Escalation | When Microsoft, third-party vendors or executives are engaged |
| Case management | System of record and evidence requirements |
| Threat hunting | Cadence, hypotheses and output |
| Detection engineering | Who tunes rules and measures alert quality |
| Reporting | Which KPIs show risk and operating health |
Managed SIEM should not hide customer responsibility
A managed SOC or SIEM service can provide monitoring, triage, investigation and escalation within agreed scope. The customer still needs business owners, application context, authority for high-impact containment, risk acceptance, and internal communications. The service contract should define those boundaries before the first critical incident.
Shared responsibility is especially important for third-party and application logs. A SOC can investigate a suspicious application event, but the application team may be needed to understand whether the behavior is legitimate or to implement remediation.
Analytics tier versus data lake should follow investigation latency
The newer Sentinel data architecture creates more choice, which means teams should avoid a blanket rule such as “all security data stays hot for a year.” Classify sources by how quickly analysts need to search them, whether detections run against them, expected query frequency, retention obligations, and volume.
| Data pattern | Likely design question | Reason |
|---|---|---|
| High-value detection data | Does it need analytics-tier detection and fast investigation? | Supports near-real-time SOC workflows |
| High-volume secondary telemetry | Can it be stored in the data lake and queried when needed? | May reduce cost while preserving historical evidence |
| Compliance/long-term evidence | What total retention and query pattern are required? | Retention need may exceed daily analytic use |
| Non-security operational data | Should it remain outside Sentinel or in another workspace/path? | Avoid paying SIEM rates for data with no security use case |
| Rare forensic source | What retrieval latency and processing are acceptable? | Optimizes cost without removing evidence |
The correct design depends on current Microsoft capabilities and customer requirements. Teams should test representative hunting and investigation workflows against the chosen tiers before broad migration of retention policies.
A managed SIEM service needs explicit customer handoffs
| Event | Managed SOC can own | Customer must own or authorize |
|---|---|---|
| Suspicious sign-in | Triage, correlate, investigate, recommend containment | Business/user context and high-impact account actions as agreed |
| Cloud-resource alert | Investigate Sentinel/Defender evidence | Application/platform context and production changes |
| Malware incident | Correlate, escalate, coordinate | Business impact and recovery decisions |
| Data-exfiltration suspicion | Investigate available telemetry | Data-owner judgment, legal/privacy and business communications |
| Third-party service alert | Triage and collect evidence | Vendor relationship and application remediation |
| Critical incident | Coordinate within runbook | Executive decisions, customer communications and risk acceptance |
This distinction should be part of service onboarding. A 24×7 monitoring promise cannot compensate for a customer contact tree that fails at 2 a.m. or an incident runbook that requires approval from someone who is unreachable.
Common Sentinel implementation anti-patterns
- Connector-first architecture: logs are onboarded before use cases are defined.
- Retention by habit: every table keeps the same retention regardless of investigative value.
- Commitment before cleanup: the organization discounts a noisy ingestion baseline.
- Detection quantity as a KPI: hundreds of rules create analyst fatigue and false confidence.
- Automation without guardrails: high-impact response actions are enabled without rollback or approval.
- SIEM owns the incident: application and business owners do not understand their containment responsibilities.
- No detection-engineering owner: rules never improve after analyst feedback.
- Pricing model ignores related services: Logic Apps, Functions, retention or other components surprise finance later.
Practical scenario: less data, better detection
Practical scenario: a SOC initially sends a broad Windows event stream and verbose application logs into Sentinel. Ingestion grows quickly, yet analysts rely on only a fraction of the data for priority detections. The response should not be a blind retention cut. The team maps use cases to event classes, tunes collection using supported controls, moves suitable secondary data to a lower-cost path, and keeps high-value analytic data readily available.
The result is not “minimum logging.” It is intentional logging. Cost and alert quality improve because every major source has a security purpose, an owner and a retention decision.
A practical Sentinel implementation sequence
- Define threats and use cases. Prioritize based on business risk.
- Map data sources. Identify minimum useful telemetry, owners, volume and retention.
- Design workspace/data architecture. Account for analytics and data-lake needs under current guidance.
- Pilot connectors and measure ingestion. Validate parsing, latency, volume and data quality.
- Deploy and tune detections. Test with representative events and analyst review.
- Design incidents and automation. Establish severity, triage, escalation and safe playbooks.
- Transition to operations. Runbooks, SOC coverage, reporting and detection-engineering ownership.
- Optimize cost and quality continuously. Review ingestion, tiering, retention, alerts and use-case value.
Pilot exit criteria
- Priority use cases have mapped data sources and owners.
- Representative connectors deliver usable, parsed data.
- Daily ingestion and major cost drivers are measured.
- Detection rules generate expected test signals and are tuned for obvious noise.
- Incidents route to the correct SOC or support process.
- Automation is tested and high-impact actions have approval boundaries.
- Retention/tiering decisions are documented by use case.
- Analysts are trained in the Microsoft Defender portal direction of travel.
- Customer understands estimated recurring Sentinel and related-service cost.
Microsoft Sentinel cost includes more than one line item
Microsoft notes that Sentinel-related solutions can use other Azure services such as Logic Apps, Azure Functions, notebooks or other components that may have separate charges. The estimate should therefore include the full architecture rather than only ingestion.
Retention, data-lake queries, automation execution, dedicated infrastructure where used, and third-party connector architectures can affect total cost. The pricing model should state which services are included and which are variable.
Use KPIs that improve detection and response
- High-severity incident triage time and escalation performance.
- Alert-to-incident quality and false-positive/benign closure patterns.
- Aging of noisy rules that have not been tuned.
- Coverage of priority threat use cases.
- Critical data sources with connector or parsing health issues.
- Daily ingestion and top-volume tables versus forecast.
- Automation success/failure rate for important playbooks.
- Recurring incidents that should become prevention work.
When Sentinel is not the first security investment
If the organization lacks basic identity controls, endpoint/workload protection, asset ownership, or incident response authority, a large SIEM deployment can generate data faster than the team can use it. Sentinel may still be part of the roadmap, but foundational controls and operating ownership may deserve priority.
Likewise, if an existing SIEM meets current requirements, a migration should have a clear business case: Microsoft security integration, architecture simplification, cost model, analyst workflow, cloud scale or another concrete reason.
Where BI Cloud Tech can help
BI Cloud Tech can support Sentinel through Microsoft Sentinel expertise, a Threat Detection and Sentinel Assessment, and ongoing Security Monitoring and SOC for Azure. Scope can include use cases, data onboarding, detection engineering, cost modeling, automation, SOC design and operational handoff.
The service should define what is assessment, what is implementation, and what is ongoing monitoring. It should also make ingestion and related cost assumptions explicit instead of promising a static Sentinel price.
A practical next step
List the ten security incidents your organization most needs to detect. For each one, identify the data source, expected responder, containment authority and whether the current SIEM can answer the investigation question. Any row with missing data or ownership is a better starting point than “connect every log.” Contact BI Cloud Tech to plan a Sentinel assessment or implementation.