Deploy Microsoft Sentinel From Scratch
A greenfield Sentinel build is mostly a chain of decisions with different reversal costs. Use this guide to decide deliberately, deploy in dependency order, and leave a handoff record that explains why the tenant looks the way it does.
Stage Map
Stage 0 - Tenant and Subscription Topology
Decide the tenant, subscription, region, naming, and tag boundaries before creating resources.
Decisions to Make First
| Decision | Options | Trade-off | Reversibility | Recommendation if unsure |
|---|---|---|---|---|
| Dedicated security subscription vs. shared subscription | Dedicated security tooling subscription, or shared workload subscription. | Dedicated gives cleaner cost attribution and policy/RBAC scope. Shared is faster to start but mixes security tooling with workload ownership. | Hard | Use a dedicated security subscription unless the tenant is a lab or short-lived pilot. |
| Management group placement | Dedicated security management group, or inline placement under workload hierarchy. | Management group placement controls inherited Azure Policy and RBAC. Moving later can re-trigger policy evaluation across the hierarchy. | Medium | Put shared security services under a security platform or management subscription hierarchy. |
| Workspace region | Co-locate with primary data sources, or use the tenant default/security operations region. | Region affects availability, latency, residency, and rebuild effort. Log Analytics workspace region migration is not a normal move operation. | Irreversible | Pick the long-term residency and data-source region before any data lands. |
| Naming convention and tag taxonomy | Encode customer/business unit and environment, or use generic names. | Generic names are quick, but they become a problem for Lighthouse, automation, cost allocation, and incident handoff. | Hard | Write the naming and tagging convention before creating the resource group. |
Actions
Create the resource group in the selected subscription and region.
Record the subscription, resource group, workspace prefix, region, and required tags as a tenant decision record.
Validate
- Subscription, resource group, region, naming convention, and required tags are written down.
- The chosen region supports Microsoft Sentinel and the expected data residency boundary.
- Cost owner and operations owner are known before Stage 1.
Stage 1 - Workspace Architecture
Create the Log Analytics workspace, enable Sentinel, and make the high-consequence table and cost choices.
Decisions to Make First
| Decision | Options | Trade-off | Reversibility | Recommendation if unsure |
|---|---|---|---|---|
| Workspace topology | Single workspace, multiple workspaces by business unit, or multiple workspaces by customer/tenant. | Single workspace keeps analytics and KQL simpler. Multi-workspace can satisfy residency or isolation needs but creates query federation and rule duplication work. | Irreversible | Use one workspace unless residency, strict isolation, or MSSP customer boundaries require more. |
| Table plan per source | Analytics, Basic Logs, or Auxiliary table plan. | Analytics is the right default for detections and multi-table hunting. Basic and Auxiliary lower cost for verbose data but add query and feature constraints. | Medium | Keep identity, incident, alert, and detection-driving data in Analytics. |
| Commitment tier | Pay-as-you-go or Sentinel/Log Analytics commitment tiers. | Commitment tiers can lower unit cost, but a wrong early commitment turns unknown ingestion into a cost trap. | Medium | Start with pay-as-you-go unless you have reliable source-by-source daily volume estimates. |
Actions
Provision the Log Analytics workspace.
Enable Microsoft Sentinel by creating the SecurityInsights onboarding state.
Apply table plan and retention decisions to the first connector tables before broad ingestion starts.
Capability Automation Coverage
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_log_analytics_workspace Reference |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_log_analytics_workspace_table Reference |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Supported | Reference |
| REST API | Supported | Reference |
| Graph | Gap | Sentinel workspace KQL is queried through Azure Monitor Logs, not Microsoft Graph. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_log_analytics_saved_search Reference Terraform can deploy saved searches and Sentinel rule queries, but query authoring and ASIM parser design remain KQL content work. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
Validate
- Workspace exists in the intended subscription, resource group, and region.
- Microsoft Sentinel is enabled on that exact workspace.
- Initial table plan and retention defaults match the cost model.
Stage 2 - Retention and Data Lifecycle
Set the investigation lookback and long-term retention model before analysts rely on the data.
Decisions to Make First
| Decision | Options | Trade-off | Reversibility | Recommendation if unsure |
|---|---|---|---|---|
| Interactive retention beyond the included Sentinel period | Keep default interactive retention, or extend table/workspace interactive retention. | Longer interactive retention speeds investigations. Archive and search jobs cost less but add time and workflow friction. | Easy | Set interactive retention to the expected incident lookback SLA for high-value tables. |
| Archive vs. delete beyond retention | Long-term retention, archive/search, or hard delete after retention. | Long-term retention preserves compliance and rare investigation paths. Deleted data is gone. | Irreversible | Archive regulated or high-dispute data; delete only data with a documented retention limit. |
Actions
Set workspace and table-level retention explicitly for the first high-value tables.
Capability Automation Coverage
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_log_analytics_workspace_table Reference |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
Validate
- Retention values match the documented investigation and compliance lookback.
- At least one search job or restore workflow is tested for non-interactive data.
- Cost estimate reflects retention, not just ingestion.
Stage 3 - Sentinel Identity and RBAC
Add Sentinel-specific access, automation identity, and table access boundaries.
Decisions to Make First
| Decision | Options | Trade-off | Reversibility | Recommendation if unsure |
|---|---|---|---|---|
| Automation identity model | System-assigned managed identity, user-assigned managed identity, or app registration/service principal. | Managed identities avoid secrets inside one tenant. Cross-tenant Lighthouse automation often needs an app registration or delegated model. | Medium | Use managed identity for single-tenant playbooks; use service principals deliberately for MSSP/cross-tenant workflows. |
| Sentinel role assignment scope | Built-in Sentinel roles at workspace scope, custom roles, or table-level RBAC. | Built-in roles are fast and support SOC operations. Table-level RBAC is useful for sensitive table segregation but adds access testing burden. | Easy | Start with built-in Sentinel roles at workspace scope, then add table-level boundaries only for named sensitivity requirements. |
| Standing access vs. PIM/JIT | Standing Responder/Reader access, or PIM/JIT for Contributor-level changes. | SOC response may require standing responder access. Editing rules, connectors, and automation should be tightly controlled. | Easy | Use standing Reader/Responder for SOC operations and PIM for Contributor-level changes. |
Actions
Assign Microsoft Sentinel Reader, Responder, and Contributor roles only where each persona needs them.
Create automation identities before building playbooks or connector automation.
Validate
- Responder test identity can triage incidents but cannot edit analytics rules.
- Contributor changes require the intended approval or PIM flow.
- Playbook identity can read/write only the Sentinel and downstream resources it needs.
Stage 4 - Enablement Choices
Decide awkward-to-reverse operational choices before data and analysts depend on them.
Decisions to Make First
| Decision | Options | Trade-off | Reversibility | Recommendation if unsure |
|---|---|---|---|---|
| UEBA at onboarding vs. later | Enable UEBA during onboarding, or defer until privacy and scope are approved. | UEBA needs historical behavior to become useful. Delaying means waiting later, but enabling without stakeholder approval can create privacy issues. | Medium | Enable early only after legal/HR/privacy scope is documented. |
| Primary SOC queue | Sentinel incident queue, or Microsoft Defender XDR unified incident queue. | A single declared queue avoids duplicate triage. Changing the queue later is a training and process problem, not only a configuration change. | Medium | Pick one primary analyst queue and treat the other as a supporting surface. |
| Content Hub solution install strategy | Install broadly, or install only solutions mapped to connected data sources. | Broad installation creates template sprawl. Narrow installation keeps tuning work tied to data that actually exists. | Easy | Install only content for connected or next-planned sources. |
Actions
Enable UEBA only after the data scope and stakeholder approval are recorded.
Install Content Hub solutions only for data sources you will connect in Stage 5.
Capability Automation Coverage
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Gap | UEBA configuration has partial workspace/provider settings coverage; model explicit settings with REST/azapi after validating current tenant support. |
| Bicep | Gap | Use REST/azapi for currently supported UEBA settings rather than a dedicated Bicep resource. |
| Terraform | Gap | No dedicated azurerm resource is recorded for UEBA configuration. Use REST/azapi if automating tenant-specific settings. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Supported | Reference |
| ARM | Gap | No ARM resource is recorded for this capability. |
| Bicep | Gap | No Bicep resource is recorded for this capability. |
| Terraform | Gap | Incidents are operational records, not desired-state configuration. Manage incident state through REST/Graph automation, not Terraform. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Gap | Content Hub package installation is exposed through Microsoft.SecurityInsights content package APIs rather than a stable first-class ARM/Bicep authoring model. |
| Bicep | Gap | Use REST or deploy the underlying artifacts directly as ARM/Bicep after package selection. |
| Terraform | Gap | No azurerm resource exists for Content Hub package installation. Use REST/azapi or deploy the package artifacts as explicit resources. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
Validate
- UEBA status matches the tenant decision record.
- Analysts know the primary incident queue before the first production alert.
- Installed content maps to data sources that are already connected or explicitly scheduled.
Stage 5 - Data Connectors
Connect sources in dependency order and verify data, not just connector status.
Decisions to Make First
| Decision | Options | Trade-off | Reversibility | Recommendation if unsure |
|---|---|---|---|---|
| Connector order | Identity first, Azure control plane next, Defender XDR next, then workload and third-party sources. | Identity and control-plane logs make early detections meaningful. Workload connectors without identity context create blind spots. | Easy | Use Entra ID, Azure Activity, and Defender XDR as the first connector wave. |
| Analytics vs. Basic/Auxiliary per connector | Analytics for detection-driving tables, Basic/Auxiliary for verbose low-touch tables. | Cost optimization at ingestion can remove or limit query capabilities that detections and workbooks expect. | Medium | Do not put first-wave identity, security alert, or incident tables into reduced query tiers. |
Actions
Connect first-wave Microsoft sources, then confirm each expected table receives recent records.
Use DCRs for custom logs and transformation/routing scenarios rather than ad hoc ingestion scripts.
Capability Automation Coverage
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_sentinel_data_connector_* Reference azurerm has separate resources for several connector types; use azapi_resource for connector kinds not covered by azurerm. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | Use ARM, Azure CLI, REST, or Terraform for DCR/DCRA deployment in this reference; no PowerShell-first workflow is modeled here. |
| REST API | Supported | Reference |
| Graph | Gap | Data Collection Rules are Azure Monitor ARM resources, not Microsoft Graph resources. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_monitor_data_collection_rule Reference Pair with azurerm_monitor_data_collection_endpoint and azurerm_monitor_data_collection_rule_association for endpoint and resource association coverage. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
Validate
- Each enabled connector has recent records in its destination table.
- No analytics rule is enabled for a table that still has no data.
- Custom log streams have a DCR, stream declaration, and transformation decision.
Stage 6 - Detection and Automation
Define the incident lifecycle before rules and playbooks start changing analyst queues.
Decisions to Make First
| Decision | Options | Trade-off | Reversibility | Recommendation if unsure |
|---|---|---|---|---|
| Analytics rule rollout strategy | Curated baseline mapped to connected sources, or broad rule enablement followed by tuning. | Broad enablement creates noisy disabled or empty rules. Curated rollout makes tuning traceable to real data. | Easy | Enable only rules whose tables are populated and whose owner is known. |
| Automation rule aggressiveness | Manual triage first, auto-assign/tag, playbook enrichment, or auto-close low-fidelity incidents. | Analysts quickly learn to trust automation. Rolling back aggressive automation after false closes damages that trust. | Medium | Start with tagging, ownership, and enrichment. Delay auto-close until precision is measured. |
| Watchlist source of truth | Manual CSV upload, Logic App sync, Function sync, or CMDB/HR source pipeline. | Manual watchlists become stale silently. Automated sync is more work but keeps VIP, asset criticality, and allow-list data defensible. | Easy | Manual upload is acceptable for bootstrap; production watchlists need an owner and sync plan. |
Actions
Deploy an analytics baseline only for connected tables and documented owners.
Deploy automation rules and playbooks with least-privilege identities.
Create initial watchlists and document whether each one is manual or synced.
Capability Automation Coverage
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_sentinel_alert_rule_scheduled Reference Fusion, ML behavior analytics, and some NRT rule kinds are not covered by azurerm; use azapi_resource against Microsoft.SecurityInsights/alertRules for those kinds. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_sentinel_automation_rule Reference |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_sentinel_watchlist Reference Use azurerm_sentinel_watchlist_item or azapi_resource for item-level automation depending on provider coverage. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
Validate
- Synthetic alert creates the expected incident.
- Automation rule fires and produces an observable incident change.
- Playbook execution history proves downstream actions succeeded.
- Watchlist-backed rules return expected enrichment values.
Stage 7 - IaC Transition Point
Choose the state ownership model before the second tenant or second engineer depends on it.
Decisions to Make First
| Decision | Options | Trade-off | Reversibility | Recommendation if unsure |
|---|---|---|---|---|
| Portal bootstrap then import vs. Terraform from day one | Create first resources in the portal and import, or author/apply Terraform before creating resources. | Portal-first gets to value faster but creates import and drift work. Terraform-first is slower but starts with state authority. | Hard | Use Terraform from day one for production and customer-repeatable builds. |
| Repository and module boundary | One root per tenant, or shared root with per-tenant tfvars and isolated state. | Shared state is easy until tenant count grows. Per-tenant state reduces blast radius and makes customer lifecycle operations cleaner. | Hard | Use isolated state per tenant/customer even if modules are shared. |
Actions
Select the Terraform root/state pattern before importing or applying production resources.
Use AzAPI for Sentinel preview resources that are not yet covered by azurerm.
Capability Automation Coverage
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No dedicated PowerShell cmdlet surface is recorded for workspace manager. Use ARM/REST/AzAPI for repeatable deployment. |
| REST API | Supported | Reference |
| Graph | Gap | Workspace manager is a Microsoft.SecurityInsights ARM resource family, not a Microsoft Graph Security resource. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azapiazapi_resource Reference azurerm does not have dedicated workspace manager resources; use azapi_resource for Microsoft.SecurityInsights/workspaceManagerAssignments, groups, members, and configurations. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
Validate
- A plan-only run works for the tenant without modifying resources.
- State is isolated from other customers or unrelated environments.
- Any portal-created resource is imported or explicitly marked as unmanaged.
Stage 8 - Validation and Handoff
Prove the build works as operated, then leave a decision record for the next engineer.
Decisions to Make First
| Decision | Options | Trade-off | Reversibility | Recommendation if unsure |
|---|---|---|---|---|
| Validation depth | Connector status only, table queries, synthetic alert, or end-to-end incident/playbook test. | Connector status proves configuration only. End-to-end testing proves the analyst workflow and automation boundary. | Easy | Do table queries plus one synthetic incident and playbook execution before handoff. |
| Decision record ownership | No record, ad hoc notes, or dated tenant decision record attached to the customer/build. | Without a decision record, the next engineer cannot tell what was deliberate and what was accidental. | Easy | Write a dated decision record covering Stages 0 through 7. |
Actions
Run KQL checks for each connected table and record ingestion volume after the first 24 to 48 hours.
Create a synthetic/test alert, confirm incident creation, automation rule execution, and playbook execution.
Capability Automation Coverage
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Supported | Reference |
| ARM | Gap | No ARM resource is recorded for this capability. |
| Bicep | Gap | No Bicep resource is recorded for this capability. |
| Terraform | Gap | Incidents are operational records, not desired-state configuration. Manage incident state through REST/Graph automation, not Terraform. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Supported | Reference |
| Bicep | Supported | Reference |
| Terraform | Supported | azurermazurerm_application_insights_workbook Reference |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
| Method | Support | Reference or Gap |
|---|---|---|
| Portal | Supported | Reference |
| PowerShell | Gap | No product-specific PowerShell automation surface is recorded for this capability yet. |
| REST API | Supported | Reference |
| Graph | Gap | No supported Microsoft Graph configuration surface is recorded for this capability yet. |
| ARM | Gap | IOC ingestion is an operational STIX upload API flow, not ARM desired state. |
| Bicep | Gap | Use the Sentinel Threat Intelligence upload API for custom IOC ingestion. |
| Terraform | Gap | Threat intelligence indicators are operational data. Ingest with the Sentinel STIX upload API from a pipeline/script step, not Terraform. |
| GitHub Actions | Supported | Reference |
| Azure DevOps | Supported | Reference |
Validate
- Each connector has recent table data, not only a connected status.
- Responder-scoped identity has the expected access and no more.
- Synthetic alert produces an incident and runs the intended automation.
- Ingestion volume is compared against the pre-deployment cost estimate after initial burst behavior settles.
- Decision record is attached to the tenant handoff.
Tenant Decision Record Template
The handoff artifact is the decisions, not just the resources. Keep this with the customer or tenant build.
# Sentinel tenant decision record
Tenant:
Subscription:
Resource group:
Workspace:
Region:
Date:
## Decisions
- Stage 0 topology:
- Stage 1 workspace architecture:
- Stage 2 retention and lifecycle:
- Stage 3 RBAC and automation identity:
- Stage 4 enablement:
- Stage 5 connectors:
- Stage 6 detection and automation:
- Stage 7 IaC ownership:
## Validation
- Connector data checks:
- Synthetic incident:
- Automation/playbook run:
- RBAC as-tested:
- First 24-48h ingestion review: