Azure Policy vs Microsoft Defender for Cloud: Which Enforces What?

When Both Tools Flag the Same Resource

Three months into their first Azure deployment, a team I was reviewing had a problem they couldn't articulate clearly. "Both things keep flagging our storage accounts," the engineer told me. "Azure Policy says our storage accounts aren't compliant. Defender for Cloud says our storage accounts have a recommendation to enable secure transfer. Are they the same thing? Why are we seeing it in two places?"

This is one of the most common points of confusion for engineers moving from on-premises environments to Azure. Both tools surface security and compliance issues. Both have dashboards. Both generate something that looks like a to-do list. But they exist for fundamentally different reasons, work at different layers, and respond to failures differently.

The short version: Azure Policy is governance and compliance enforcement — it defines rules for what your resources are allowed to do or be. Microsoft Defender for Cloud is security posture management and threat detection — it continuously evaluates whether your resources are configured securely and whether active threats are present.

One enforces. The other observes, recommends, and sometimes detects.

What Azure Policy Actually Does

Azure Policy is Azure's built-in governance engine. It operates at the control plane level — on top of Azure Resource Manager — meaning it intercepts every create, update, and read operation on Azure resources and evaluates it against a set of rules.

Initiatives, Policies, and Assignments

The building blocks are:

A Policy definition is a single rule. "Storage accounts must use HTTPS only." "Virtual machines must use approved VM sizes." "Resource groups must have a specific tag." Each definition specifies a condition and an effect.

An Initiative (also called a Policy Set) is a collection of related policies grouped together. Microsoft provides built-in initiatives for common compliance frameworks — CIS Microsoft Azure Foundations Benchmark, NIST SP 800-53, PCI DSS, SOC 2, ISO 27001. When you assign an initiative, all its constituent policies are evaluated together.

An Assignment is the act of applying a policy or initiative to a specific scope — a management group, subscription, or resource group. The same policy can be assigned to different scopes with different parameters.

The Effects That Actually Matter

The effect is what happens when a resource fails the policy condition. This is where Azure Policy's real power and real complexity live.

Audit — The resource is allowed to exist. A compliance violation is recorded. Nothing is blocked. This is useful for discovering violations without disrupting existing workloads, and for policies where denial would break too many things.

Deny — The resource creation or modification is rejected at the API level. If someone tries to create a storage account without HTTPS-only enabled, the ARM API returns a 403 with the policy details in the error. Nothing gets deployed. This is the effect you want for hard security requirements.

DeployIfNotExists (DINE) — When a resource is created or updated and doesn't have a specific configuration (like diagnostic settings or a specific extension), Azure Policy automatically deploys the missing configuration. This is powerful for ensuring things like Log Analytics agents, disk encryption, or monitoring settings are always present. It requires a Managed Identity with appropriate permissions to execute the remediation deployment.

Modify — Similar to DINE, but adds or removes tags or properties on existing resources. Useful for automatic tagging enforcement.

There's also AuditIfNotExists, which is like DINE without the automatic deployment — it audits resources that are missing a related resource.

Built-in vs Custom Policies

Microsoft ships hundreds of built-in policy definitions covering nearly every Azure service. Before writing a custom policy, search the built-in library — there's a good chance what you need already exists. Custom policies are written in JSON and use Azure Resource Manager condition expressions.

Remediation tasks are how you bring existing non-compliant resources into compliance. For Audit policies, you can create a remediation task manually or schedule it. For DINE policies, the remediation task triggers the deployment automatically. Note that Deny only prevents future violations — it doesn't remediate existing ones, so you'll need a separate remediation approach for resources that already exist.

What Microsoft Defender for Cloud Actually Does

Microsoft Defender for Cloud (formerly Azure Security Center) is a Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) platform. It operates at a higher level of abstraction than Azure Policy — it looks at your cloud environment holistically and tells you how secure your posture is, and optionally, whether active threats are present.

Secure Score and Recommendations

The Secure Score is Defender for Cloud's headline metric — a percentage representing how well your subscription follows Microsoft's security best practices. Every recommendation has a score impact, and fixing recommendations improves your score.

Recommendations are actionable findings. "Enable MFA for accounts with owner permissions on your subscription." "Storage accounts should restrict network access." "Virtual machines should encrypt temp disks, data disks, and cache." Each recommendation shows which resources are affected, what the risk is, and how to fix it. Some recommendations have a Quick Fix button that applies the remediation directly from the portal.

CSPM vs CWP

Defender for Cloud operates in two modes:

CSPM (Cloud Security Posture Management) is available in a free tier and continuously evaluates your Azure resources against security best practices. This is the part that generates recommendations and a Secure Score. The free tier covers Azure, and with the paid Defender CSPM plan, it extends to multi-cloud (AWS, GCP) and adds attack path analysis, cloud security explorer, and agentless scanning.

CWP (Cloud Workload Protection) is the paid, threat-detection layer. The Defender plans cover individual resource types: Defender for Servers, Defender for SQL, Defender for Storage, Defender for Containers, Defender for Key Vault, Defender for App Service, and others. These plans go beyond posture and add real-time threat detection, anomaly detection, and security alerts for active attacks.

The Regulatory Compliance Dashboard

Defender for Cloud's Regulatory Compliance dashboard maps your environment against specific compliance frameworks — the same ones Azure Policy uses (CIS, NIST, PCI DSS, etc.). This is where the overlap with Azure Policy becomes visible: the compliance status you see here is driven by Policy evaluations running under the hood.

The Overlap: Where They Work Together

The thing that makes this confusing is that Defender for Cloud and Azure Policy are deeply integrated. Defender for Cloud uses Azure Policy as its enforcement mechanism for recommendations. When you see a recommendation in Defender for Cloud like "Storage accounts should use private link," there is an Azure Policy definition running in the background that evaluates the same condition.

Here's a concrete example: the recommendation "Storage accounts should restrict network access using virtual network rules" appears in Defender for Cloud's Secure Score. If you navigate to Azure Policy and search for storage account policies, you'll find "Storage accounts should restrict network access" as a built-in policy definition. They're evaluating the same thing from different vantage points.

This means:

• Viewing the issue in Defender for Cloud shows you the security risk framing and what remediation looks like.
• Using Azure Policy gives you the ability to *enforce* it — to Deny non-compliant configurations from being created.

Defender for Cloud shows you the recommendation and scores your posture. Azure Policy enforces the requirement and blocks violations. You often need both.

The architecture looks like this:

Azure Resources
       |
       ▼
Azure Resource Manager (ARM)
       |
       ├──► Azure Policy Engine
       │         │
       │         ├── Evaluate conditions
       │         ├── Apply effects (Audit, Deny, DeployIfNotExists)
       │         └── Write compliance state to ARM
       │
       └──► Microsoft Defender for Cloud
                 │
                 ├── Read policy compliance state from ARM
                 ├── Run additional security assessments (agent-based + agentless)
                 ├── Generate Secure Score and recommendations
                 ├── Map to regulatory frameworks
                 └── (With paid plans) Detect active threats

Decision Framework: Which Tool for Which Scenario?

The table reveals the core distinction: Azure Policy is proactive and preventive. Defender for Cloud is reactive and observational (with threat detection as an active layer on top).

Practical Example: Enforcing Tagging With Azure Policy and Terraform

One of the most common governance requirements is mandatory resource tagging. Here's how to enforce it properly with Terraform:

# Define the policy assignment for required tags
resource "azurerm_policy_assignment" "require_tags" {
  name                 = "require-env-owner-tags"
  scope                = data.azurerm_subscription.current.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/96670d01-0a4d-4649-9c89-2d3abc0a5025"
  # Built-in: "Require a tag and its value on resources"
  display_name         = "Require environment and owner tags on all resources"
  description          = "Denies creation of resources missing required env or owner tags"
  enforcement_mode     = "Default"  # "Default" = enforce, "DoNotEnforce" = audit only

  parameters = jsonencode({
    tagName = {
      value = "environment"
    }
    tagValue = {
      value = "production"
    }
  })

  identity {
    type = "SystemAssigned"
  }

  location = "westeurope"
}

# Assign a built-in initiative for CIS benchmark
resource "azurerm_policy_set_definition" "cis_assignment" {}

resource "azurerm_subscription_policy_assignment" "cis_benchmark" {
  name                 = "cis-benchmark-v2"
  subscription_id      = data.azurerm_subscription.current.id
  policy_definition_id = "/providers/Microsoft.Authorization/policySetDefinitions/06f19060-9e68-4070-92ca-f15cc126059e"
  # Built-in: CIS Microsoft Azure Foundations Benchmark v2.0.0
  display_name         = "CIS Microsoft Azure Foundations Benchmark v2.0.0"
  enforcement_mode     = "DoNotEnforce"  # Audit first, then switch to Default
}

A few notes on this pattern: Start new policy assignments with enforcement_mode = "DoNotEnforce" to audit violations without blocking anything. Once you've reviewed the findings and are confident in the policy logic, switch to "Default" to enforce. Switching a Deny policy from audit to enforce on an active subscription with existing violations will not affect those resources retroactively, but it will block any new non-compliant resources.

For more complex governance patterns, see the [Azure auto-tag event-driven governance](/blog/azure-auto-tag-event-driven-governance) article, which covers DINE policies and Event Grid-based tagging approaches.

Pricing Reality Check

Azure Policy is free. You can create as many policy definitions, initiatives, and assignments as you need. Policy evaluations run continuously at no charge. This makes it a no-brainer for governance — there's no financial reason not to use it.

Microsoft Defender for Cloud has two tiers:

The free CSPM tier is included with every Azure subscription. It gives you Secure Score, basic recommendations, and the Regulatory Compliance dashboard. For most organizations starting out, this provides significant value at no cost.

The paid Defender CSPM plan adds multi-cloud support (AWS/GCP), attack path analysis, cloud security explorer, and agentless scanning. It's priced per billable resource. For organizations managing complex multi-cloud environments or needing advanced attack path visualization, it's worth it.

The Defender plans (for Servers, SQL, Containers, Storage, Key Vault, etc.) are priced separately, typically per resource per hour. Defender for Servers is often the largest cost because it applies to every VM. For a production environment with regulated workloads, Defender for Servers combined with Defender for SQL typically provides enough detection coverage to justify the cost against the alternative of building detection from scratch in your SIEM.

Where the paid plans are genuinely worth the cost: regulated industries (finance, healthcare, government), environments processing sensitive data, and organizations without dedicated security monitoring tooling. Where they may not be: small environments with homogeneous workloads where a well-tuned Azure Policy baseline + Log Analytics provides equivalent coverage at lower cost.

The Mistake That Costs People the Most

The most expensive mistake teams make is treating Defender for Cloud recommendations as a substitute for Azure Policy enforcement.

Defender for Cloud tells you that your storage accounts should restrict network access. It's right. But if you don't also have an Azure Policy with a Deny effect preventing non-compliant storage accounts from being created, the next engineer who runs a Terraform apply or clicks through the portal to create a storage account will create a public one by default. Defender will flag it. They'll fix it — maybe — when they get around to it. Meanwhile, a public storage account with sensitive data was live for hours or days.

Policy enforcement means the misconfiguration never happens. The deployment fails with a policy error message explaining exactly what's wrong. The engineer fixes their code before it reaches production.

Recommendations without enforcement is like a smoke alarm that tells you there was a fire last week. Useful information, but you'd prefer the fire suppression system that prevented it.

If you're building your cloud security foundation, start with Azure Policy to enforce your hard requirements, and use Defender for Cloud recommendations to find and prioritize everything else. The [cloud security fundamentals guide](/blog/cloud-security-fundamentals-beginners) walks through how to layer these controls into a coherent baseline for new Azure environments.