Setup from scratch

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

Build stage

Stage 0 - Tenant and Subscription Topology

Decide the tenant, subscription, region, naming, and tag boundaries before creating resources.

Current

Decisions to Make First

DecisionOptionsTrade-offReversibilityRecommendation if unsure
Dedicated security subscription vs. shared subscriptionDedicated 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.HardUse a dedicated security subscription unless the tenant is a lab or short-lived pilot.
Management group placementDedicated 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.MediumPut shared security services under a security platform or management subscription hierarchy.
Workspace regionCo-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.IrreversiblePick the long-term residency and data-source region before any data lands.
Naming convention and tag taxonomyEncode 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.HardWrite the naming and tagging convention before creating the resource group.

Actions

  1. Create the resource group in the selected subscription and region.

  2. 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.
Build stage

Stage 1 - Workspace Architecture

Create the Log Analytics workspace, enable Sentinel, and make the high-consequence table and cost choices.

Current

Decisions to Make First

DecisionOptionsTrade-offReversibilityRecommendation if unsure
Workspace topologySingle 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.IrreversibleUse one workspace unless residency, strict isolation, or MSSP customer boundaries require more.
Table plan per sourceAnalytics, 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.MediumKeep identity, incident, alert, and detection-driving data in Analytics.
Commitment tierPay-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.MediumStart with pay-as-you-go unless you have reliable source-by-source daily volume estimates.

Actions

  1. Provision the Log Analytics workspace.

  2. Enable Microsoft Sentinel by creating the SecurityInsights onboarding state.

  3. Apply table plan and retention decisions to the first connector tables before broad ingestion starts.

Capability Automation Coverage

MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_log_analytics_workspace Reference
GitHub ActionsSupported Reference
Azure DevOpsSupported Reference
MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_log_analytics_workspace_table Reference
GitHub ActionsSupported Reference
Azure DevOpsSupported Reference
MethodSupportReference or Gap
PortalSupported Reference
PowerShellSupported Reference
REST APISupported Reference
GraphGapSentinel workspace KQL is queried through Azure Monitor Logs, not Microsoft Graph.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_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 ActionsSupported Reference
Azure DevOpsSupported 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.
Build stage

Stage 2 - Retention and Data Lifecycle

Set the investigation lookback and long-term retention model before analysts rely on the data.

Current

Decisions to Make First

DecisionOptionsTrade-offReversibilityRecommendation if unsure
Interactive retention beyond the included Sentinel periodKeep 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.EasySet interactive retention to the expected incident lookback SLA for high-value tables.
Archive vs. delete beyond retentionLong-term retention, archive/search, or hard delete after retention.Long-term retention preserves compliance and rare investigation paths. Deleted data is gone.IrreversibleArchive regulated or high-dispute data; delete only data with a documented retention limit.

Actions

  1. Set workspace and table-level retention explicitly for the first high-value tables.

Capability Automation Coverage

MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_log_analytics_workspace_table Reference
GitHub ActionsSupported Reference
Azure DevOpsSupported 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.
Build stage

Stage 3 - Sentinel Identity and RBAC

Add Sentinel-specific access, automation identity, and table access boundaries.

Current

Decisions to Make First

DecisionOptionsTrade-offReversibilityRecommendation if unsure
Automation identity modelSystem-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.MediumUse managed identity for single-tenant playbooks; use service principals deliberately for MSSP/cross-tenant workflows.
Sentinel role assignment scopeBuilt-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.EasyStart with built-in Sentinel roles at workspace scope, then add table-level boundaries only for named sensitivity requirements.
Standing access vs. PIM/JITStanding 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.EasyUse standing Reader/Responder for SOC operations and PIM for Contributor-level changes.

Actions

  1. Assign Microsoft Sentinel Reader, Responder, and Contributor roles only where each persona needs them.

  2. 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.
Build stage

Stage 4 - Enablement Choices

Decide awkward-to-reverse operational choices before data and analysts depend on them.

Current

Decisions to Make First

DecisionOptionsTrade-offReversibilityRecommendation if unsure
UEBA at onboarding vs. laterEnable 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.MediumEnable early only after legal/HR/privacy scope is documented.
Primary SOC queueSentinel 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.MediumPick one primary analyst queue and treat the other as a supporting surface.
Content Hub solution install strategyInstall 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.EasyInstall only content for connected or next-planned sources.

Actions

  1. Enable UEBA only after the data scope and stakeholder approval are recorded.

  2. Install Content Hub solutions only for data sources you will connect in Stage 5.

Capability Automation Coverage

MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMGapUEBA configuration has partial workspace/provider settings coverage; model explicit settings with REST/azapi after validating current tenant support.
BicepGapUse REST/azapi for currently supported UEBA settings rather than a dedicated Bicep resource.
TerraformGapNo dedicated azurerm resource is recorded for UEBA configuration. Use REST/azapi if automating tenant-specific settings.
GitHub ActionsSupported Reference
Azure DevOpsSupported Reference
MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphSupported Reference
ARMGapNo ARM resource is recorded for this capability.
BicepGapNo Bicep resource is recorded for this capability.
TerraformGapIncidents are operational records, not desired-state configuration. Manage incident state through REST/Graph automation, not Terraform.
GitHub ActionsSupported Reference
Azure DevOpsSupported Reference
MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMGapContent Hub package installation is exposed through Microsoft.SecurityInsights content package APIs rather than a stable first-class ARM/Bicep authoring model.
BicepGapUse REST or deploy the underlying artifacts directly as ARM/Bicep after package selection.
TerraformGapNo azurerm resource exists for Content Hub package installation. Use REST/azapi or deploy the package artifacts as explicit resources.
GitHub ActionsSupported Reference
Azure DevOpsSupported 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.
Build stage

Stage 5 - Data Connectors

Connect sources in dependency order and verify data, not just connector status.

Current

Decisions to Make First

DecisionOptionsTrade-offReversibilityRecommendation if unsure
Connector orderIdentity 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.EasyUse Entra ID, Azure Activity, and Defender XDR as the first connector wave.
Analytics vs. Basic/Auxiliary per connectorAnalytics 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.MediumDo not put first-wave identity, security alert, or incident tables into reduced query tiers.

Actions

  1. Connect first-wave Microsoft sources, then confirm each expected table receives recent records.

  2. Use DCRs for custom logs and transformation/routing scenarios rather than ad hoc ingestion scripts.

Capability Automation Coverage

MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_sentinel_data_connector_* Reference

azurerm has separate resources for several connector types; use azapi_resource for connector kinds not covered by azurerm.

GitHub ActionsSupported Reference
Azure DevOpsSupported Reference
MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapUse ARM, Azure CLI, REST, or Terraform for DCR/DCRA deployment in this reference; no PowerShell-first workflow is modeled here.
REST APISupported Reference
GraphGapData Collection Rules are Azure Monitor ARM resources, not Microsoft Graph resources.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_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 ActionsSupported Reference
Azure DevOpsSupported 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.
Build stage

Stage 6 - Detection and Automation

Define the incident lifecycle before rules and playbooks start changing analyst queues.

Current

Decisions to Make First

DecisionOptionsTrade-offReversibilityRecommendation if unsure
Analytics rule rollout strategyCurated 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.EasyEnable only rules whose tables are populated and whose owner is known.
Automation rule aggressivenessManual 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.MediumStart with tagging, ownership, and enrichment. Delay auto-close until precision is measured.
Watchlist source of truthManual 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.EasyManual upload is acceptable for bootstrap; production watchlists need an owner and sync plan.

Actions

  1. Deploy an analytics baseline only for connected tables and documented owners.

  2. Deploy automation rules and playbooks with least-privilege identities.

  3. Create initial watchlists and document whether each one is manual or synced.

Capability Automation Coverage

MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_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 ActionsSupported Reference
Azure DevOpsSupported Reference
MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_sentinel_automation_rule Reference
GitHub ActionsSupported Reference
Azure DevOpsSupported Reference
MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_sentinel_watchlist Reference

Use azurerm_sentinel_watchlist_item or azapi_resource for item-level automation depending on provider coverage.

GitHub ActionsSupported Reference
Azure DevOpsSupported 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.
Build stage

Stage 7 - IaC Transition Point

Choose the state ownership model before the second tenant or second engineer depends on it.

Current

Decisions to Make First

DecisionOptionsTrade-offReversibilityRecommendation if unsure
Portal bootstrap then import vs. Terraform from day oneCreate 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.HardUse Terraform from day one for production and customer-repeatable builds.
Repository and module boundaryOne 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.HardUse isolated state per tenant/customer even if modules are shared.

Actions

  1. Select the Terraform root/state pattern before importing or applying production resources.

  2. Use AzAPI for Sentinel preview resources that are not yet covered by azurerm.

Capability Automation Coverage

MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo dedicated PowerShell cmdlet surface is recorded for workspace manager. Use ARM/REST/AzAPI for repeatable deployment.
REST APISupported Reference
GraphGapWorkspace manager is a Microsoft.SecurityInsights ARM resource family, not a Microsoft Graph Security resource.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazapiazapi_resource Reference

azurerm does not have dedicated workspace manager resources; use azapi_resource for Microsoft.SecurityInsights/workspaceManagerAssignments, groups, members, and configurations.

GitHub ActionsSupported Reference
Azure DevOpsSupported 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.
Build stage

Stage 8 - Validation and Handoff

Prove the build works as operated, then leave a decision record for the next engineer.

Current

Decisions to Make First

DecisionOptionsTrade-offReversibilityRecommendation if unsure
Validation depthConnector 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.EasyDo table queries plus one synthetic incident and playbook execution before handoff.
Decision record ownershipNo 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.EasyWrite a dated decision record covering Stages 0 through 7.

Actions

  1. Run KQL checks for each connected table and record ingestion volume after the first 24 to 48 hours.

  2. Create a synthetic/test alert, confirm incident creation, automation rule execution, and playbook execution.

Capability Automation Coverage

MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphSupported Reference
ARMGapNo ARM resource is recorded for this capability.
BicepGapNo Bicep resource is recorded for this capability.
TerraformGapIncidents are operational records, not desired-state configuration. Manage incident state through REST/Graph automation, not Terraform.
GitHub ActionsSupported Reference
Azure DevOpsSupported Reference
MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMSupported Reference
BicepSupported Reference
TerraformSupportedazurermazurerm_application_insights_workbook Reference
GitHub ActionsSupported Reference
Azure DevOpsSupported Reference
MethodSupportReference or Gap
PortalSupported Reference
PowerShellGapNo product-specific PowerShell automation surface is recorded for this capability yet.
REST APISupported Reference
GraphGapNo supported Microsoft Graph configuration surface is recorded for this capability yet.
ARMGapIOC ingestion is an operational STIX upload API flow, not ARM desired state.
BicepGapUse the Sentinel Threat Intelligence upload API for custom IOC ingestion.
TerraformGapThreat intelligence indicators are operational data. Ingest with the Sentinel STIX upload API from a pipeline/script step, not Terraform.
GitHub ActionsSupported Reference
Azure DevOpsSupported 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.

markdown
# 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: