On this page

Policy Baseline

A long policy catalogue looks impressive and helps almost no one. What matters is the small set of guardrails enforced before workloads spread everywhere, while the environment is still small enough to shape. This page defines that baseline and the lifecycle that operates it.

Purpose

This page defines Azure Policy as the central governance engine for the platform — used to enforce standards, evaluate compliance, deploy supporting configuration, and remediate drift.

Design Reasoning

A good policy baseline is not a pile of individual assignments. It is packaged into initiatives, parameterized, assigned at appropriate scopes, and operated with a lifecycle.

Azure Policy effects fall into a few categories you will actually use:

Deny — block non-compliant create/update requests (allowed locations, public access, resource types).
Audit / AuditIfNotExists — report non-compliance without blocking; the safe way to measure impact first.
Modify / Append — adjust requests, typically to add or inherit tags.
DeployIfNotExists — deploy supporting configuration (diagnostic settings, agents) when it is missing.

Manual, DenyAction, and Disabled also exist; the four above cover most of a landing zone baseline. Crucially, only Modify and DeployIfNotExists support remediation — and both require a managed identity with the right permissions.

Audit before you deny

Start guardrails that could break in-flight workloads in Audit, measure the real impact, communicate required changes, and only then tighten to Deny, Modify, or DeployIfNotExists. Breaking teams is how governance loses trust permanently.

Policy exemptions must be treated as managed exceptions — each with a reason, an owner, and an expiration date — not as a quiet way to make a warning disappear.

Architecture Decision Record

Decision	Choice	Rationale
Policy packaging	Group related policies into initiatives	Initiatives simplify assignment, parameterization, review, and lifecycle management.
Rollout model	Audit, then enforce	A staged lifecycle surfaces impact before enforcement, avoiding broken deployments and lost trust.

Tradeoff: Initiatives add a layer of indirection over individual policies. For anything beyond a handful of assignments, that indirection is what keeps the baseline reviewable.

Recommended Configuration

The guardrails worth enabling first, with the effect to start from:

Area	Approach	Effect
Allowed locations	Initiative parameter for permitted regions	Deny
Required tags	Built-in required-tag policies and tag inheritance	Deny or Modify
Public IP restrictions	Built-in or custom policies by resource type	Deny
Storage public access	Built-in storage policies	Deny
Storage secure transfer	Built-in storage policies	Deny
Diagnostic settings	Initiative using category groups	DeployIfNotExists
Resource type restrictions	Built-in “not allowed resource types” policy	Deny
Private endpoints for sensitive services	Built-in where available, custom where not	Audit, then Deny or DeployIfNotExists

In a landing zone, DeployIfNotExists and Modify should deploy or adjust supporting resources and configuration — diagnostic settings, tags, agents — not full application workloads.

Example Implementation

A management-group-scoped assignment of a DeployIfNotExists initiative, with the system-assigned identity that remediation requires:

1
targetScope = 'managementGroup'
2

3
@description('Resource ID of the diagnostic-settings initiative to assign.')
4
param policyDefinitionId string
5

6
@description('Name of the policy assignment.')
7
param assignmentName string = 'diag-settings-baseline'
8

9
@description('Resource ID of the central Log Analytics workspace.')
10
param logAnalyticsId string
11

12
resource assignment 'Microsoft.Authorization/policyAssignments@2025-03-01' = {
13
  name: assignmentName
14
  location: 'switzerlandnorth'
15
  identity: {
16
    type: 'SystemAssigned'
17
  }
18
  properties: {
19
    displayName: 'Deploy diagnostic settings baseline'
20
    policyDefinitionId: policyDefinitionId
21
    enforcementMode: 'Default'
22
    parameters: {
23
      logAnalytics: {
24
        value: logAnalyticsId
25
      }
26
    }
27
  }
28
}

The managed identity still needs a role assignment (for example, Contributor or a least-privilege custom role) at the remediation scope so it can deploy the missing configuration.

Validation Steps

1
# Assignments at the intermediate root scope
2
az policy assignment list \
3
  --scope /providers/Microsoft.Management/managementGroups/contoso
4

5
# Exemptions for a subscription — every one should have an owner and expiry
6
az policy exemption list --scope /subscriptions/<subscription-id>
7

8
# Remediation tasks (policyinsights extension)
9
az policy remediation list --management-group contoso

Operate the baseline as a lifecycle:

Start with Audit or AuditIfNotExists.
Measure impact across the estate.
Communicate the required changes.
Move to Deny, Modify, or DeployIfNotExists.
Create remediation tasks where needed.
Review exemptions regularly.

Common Mistakes

Exemptions without expiration dates, which become permanent, undocumented exceptions.
Many individual assignments instead of initiatives, which makes the baseline unreviewable.
Using DeployIfNotExists to deploy workloads rather than supporting configuration.
Assigning policies too broadly at the tenant root.
Missing managed identity permissions for remediation, so remediation silently fails.
Leaving policies in Audit forever, which provides visibility but never a guardrail.