Azure Policy Exemptions: Admin Runbook

Azure Policy exemptions sound boring until they save your change window and your audit trail. Used well, they give teams a controlled way to acknowledge a temporary exception without pretending the resource is compliant. Used badly, they become sticky notes on a monitor: helpful for three days, suspicious forever.

This runbook covers when to use exemptions, how to structure them with expiry and ownership metadata, and how to review them before they become permanent furniture.

What Azure Policy exemptions do

An exemption is a child resource at management group, subscription, resource group or resource scope. It points to a policy assignment and tells Azure Policy not to evaluate that scope for the assignment, or for selected definitions inside an initiative.

Exempted resources still appear in compliance reporting as Exempted. Unlike quietly carving resources out with broad exclusions, an exemption says: “we know about this, here’s why, and here’s when we’ll look again.”

Exemption, exclusion or policy change?

Metadata every exemption should carry

The exemption structure supports a flexible metadata object. The platform won’t enforce your approval model, so your process must. At minimum, capture:

• Business reason: why the resource can’t comply yet.
• Owner: the team accountable for remediation (requestedBy).
• Approver: who accepted the risk (approvedBy).
• Ticket reference: the change, incident, work item or risk record (ticketRef).
• Expiry: when the exemption stops being honored (expiresOn, in UTC).
• Replacement control: required for mitigated exemptions.

Waiver vs. mitigated

The two categories mean different things in a governance review: “we accept this risk for 30 days” versus “another control covers this risk.” Don’t blur them.

A practical Azure CLI pattern

The CLI provides az policy exemption create, list, show, update and delete. A resource group-scope example:

az policy exemption create \
  --name "ex-waiver-webapp-eastus-2026q4" \
  --display-name "Temporary waiver for webapp regional migration" \
  --description "Allows the workload to remain outside approved regions until migration completes." \
  --exemption-category "Waiver" \
  --policy-assignment "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/policyAssignments/allowed-locations" \
  --resource-group "rg-prod-webapp" \
  --expires-on "2026-12-15T23:59:00Z" \
  --metadata '{"requestedBy":"Web Platform Team","approvedBy":"Cloud Governance Board","ticketRef":"CHG-18421","remediationOwner":"web-platform","reviewCadence":"weekly"}'

The name encodes type, workload, scope and quarter. Pick any convention, but make it searchable so you can find the exception that expires tonight.

Target initiative definitions with reference IDs

For initiative assignments, use policyDefinitionReferenceId to exempt only the definitions that need it, so one bypass doesn’t switch off twelve guardrails:

{
  "properties": {
    "policyAssignmentId": "/providers/Microsoft.Management/managementGroups/prod/providers/Microsoft.Authorization/policyAssignments/baseline-governance",
    "policyDefinitionReferenceId": [
      "allowedLocations",
      "requiredTags"
    ],
    "exemptionCategory": "Waiver",
    "expiresOn": "2026-11-30T23:59:00Z",
    "metadata": {
      "requestedBy": "ERP Team",
      "approvedBy": "Cloud Governance Board",
      "ticketRef": "ADO-4921"
    }
  }
}

Expiration isn’t deletion

When expiresOn passes, the exemption object is kept for record-keeping but no longer honored. You keep the audit trail, but expired objects pile up unless you review and remove them deliberately.

Review exemptions with compliance data

Compliance data is available in the portal, CLI, Azure Monitor logs and Azure Resource Graph. Evaluations run on assignment, resource and exemption changes, on a daily cycle and on demand, so allow time after creating or deleting an exemption.

Ask whether exempted resources are shrinking, stable with approved reasons, or growing. Steady growth points to a policy design problem, a migration backlog, or a team using exemptions as a deployment strategy, and more exemptions won’t fix any of those.

Azure Policy exemptions checklist

• Keep scope tight: resource or resource group over subscription, unless the exception genuinely applies broadly.
• Prefer expiry for waivers, and make renewal an explicit approval.
• Standardize metadata: owner, approver, ticket, reason, remediation date and review cadence.
• Use initiative reference IDs to exempt only the needed definitions.
• Separate waivers from mitigations in the review path.
• Audit and remove expired exemptions once the audit trail is no longer needed.
• Watch for clustering: many exemptions on one policy suggest the policy needs tuning.

A lightweight operating model

• Platform team: owns definitions, assignments, naming and reporting.
• Workload team: owns the remediation plan and justification.
• Security or governance approver: accepts the risk or validates the compensating control.
• Automation: reports exemptions expiring in 7, 14 and 30 days.

Azure Policy exemptions are part of governance when they’re scoped, documented, approved, monitored and allowed to expire. Treat each one as a temporary engineering decision with a named owner. For fixing drift rather than excusing it, see Azure Policy remediation tasks.

Last reviewed: October 2026

Sources

• Azure Policy exemption structure (Microsoft Learn)
• Understand scope in Azure Policy (Microsoft Learn)
• Get policy compliance data (Microsoft Learn)
• az policy exemption command reference (Microsoft Learn)