Defender for Cloud baseline: plan coverage, auto-provisioning, and turning recommendations into guardrails

1. Confirm landing zone scope and target workspaces

   List every subscription that will enrol in Defender for Cloud. Decide whether they point to a central Log Analytics workspace or a per-environment set (prod vs non-prod). Capture workspace IDs and regions; they will be referenced in automation and policy.

2. Enable plan coverage through IaC, not the portal

   Use Terraform, Bicep or the REST API to enable the Defender plans you need. This makes the state auditable. Typical minimum: servers, SQL (PaaS and IaaS), storage, containers, and Key Vault.

   resource defenderPlans 'Microsoft.Security/pricings@2023-01-01-preview' = [
     for plan in [
       'VirtualMachines'
       'SqlServers'
       'StorageAccounts'
       'Containers'
       'KeyVaults'
     ]: {
       name: plan
       properties: {
         pricingTier: 'Standard'
       }
     }
   ]

3. Lock auto-provisioning to the desired agent set

   Turn on AMA, agentless scanning, and any extension deployment via IaC. Disable the old Log Analytics agent if you are migrating. Record which toggle maps to which use case so you can explain the bill later.

4. Route telemetry into the correct workspaces

   For every subscription, assign the Diagnostic Settings template so Defender data lands in the agreed workspace. Confirm the retention settings and costs are covered by the platform team budget.

5. Create a policy initiative for mandatory recommendations

   Pick the recommendations that map to genuine risk (public storage, SQL missing TDE, missing MFA on SQL logins, etc). Build an Azure Policy initiative and assign it at the landing-zone management group. This keeps Defender from nagging endlessly — it becomes an enforceable guardrail instead.

6. Automate assignment of security contacts and notifications

   Configure the Microsoft.Security/securityContacts resource to point at platform inboxes, service management tooling, and (if applicable) SIEM connectors. Store the runbook for rotating these contacts when teams change.

7. Surface Defender insights in your operations tooling

   Pipe Defender alerts into Sentinel, ticketing, or chat notifications. Make sure the operational teams know what to do with them; create short runbooks for the common alert types.

8. Define the exemption workflow

   Document how a workload team requests an exemption when a recommendation or policy assignment is incorrect for their scenario. Track expiry dates and owners. Avoid indefinite blanket exemptions.

9. Backfill historical coverage gaps

   Review existing subscriptions for plan coverage drift. Run a CLI or REST script to confirm the desired plans are enabled everywhere. This is often a one-off night shift to clean up legacy subs.

10. Publish cost visibility

    Share dashboards showing Defender charges per subscription. This prevents surprise resistance the next time you enforce a plan upgrade.

Validation checklist

• ✓

  Every target subscription shows the expected Defender plans enabled via IaC state.

• ✓

  Auto-provisioning toggles match the documented baseline (AMA, agentless scanning, etc).

• ✓

  Security contacts and notification channels receive Defender alerts during testing.

• ✓

  Diagnostic settings push Defender data into the agreed Log Analytics workspace(s).

• ✓

  Policy initiatives exist for the high-impact recommendations you care about.

• ✓

  Exemptions are tracked with owners and expiry dates.

• ✓

  Operations teams confirm Defender alerts reach their tooling and have clear response steps.

• ✓

  Cost dashboards or reports show Defender charges per subscription.