# Give every Azure Policy exemption an owner, scope, expiry, and review > Azure Policy exemptions preserve compliance visibility while recording a Mitigated or Waiver decision, but expiration is optional and the object remains after expiry. Treat each exemption as a governed, time-bound risk record. - Canonical URL: https://update.dsesecurity.com/updates/azure-policy-exemption-lifecycle/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:00:00+00:00 - Modified: 2026-08-11T14:48:24+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Azure Policy exemptions preserve compliance visibility while recording a Mitigated or Waiver decision, but expiration is optional and the object remains after expiry. Treat each exemption as a governed, time-bound risk record. ## Potentially affected Azure management groups, subscriptions, resource groups, and resources; Azure Policy assignments and initiatives; cloud platform, security, compliance, application, and resource-owner teams; Azure RBAC and Resource Graph reporting. ## DSE recommendation Inventory live exemptions, validate assignment and definition scope, require owner and approval metadata plus expiresOn, narrow each exception to the minimum resource and policy set, and monitor active, expired, and changing records. ## Article ## Source facts: an exemption is a resource with scope and retained state Microsoft’s [Azure Policy exemption documentation](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure) describes an exemption as a child object on the resource hierarchy or individual resource being exempted. It links to a specific policy or initiative assignment through policyAssignmentId. When an initiative is involved, policyDefinitionReferenceId can limit the exemption to selected definitions instead of bypassing the entire initiative. Two categories express different decisions. Mitigated means the policy’s intent is satisfied another way. Waiver means noncompliance is temporarily accepted, or a resource is excluded from selected definitions without excluding it from the entire initiative. The free-form metadata property can hold organization-specific fields such as requester, approver, approval date, and ticket reference. The optional expiresOn timestamp controls when the exemption stops being honored. Microsoft notes that expiry does not delete the object; it remains for recordkeeping. Applicable resources report an Exempt compliance state, and the compliance substate can show what the state would be without the exemption. Resource selectors can narrow certain exemptions by attributes such as location or resource type. Creation requires Azure RBAC permission to write exemption objects and the additional exempt/Action permission on the target assignment. That boundary is important because an exemption changes how governance evaluates resources even though it does not edit the underlying policy definition. ## DSE recommendation: make the object implement the risk decision Define a minimum record before granting any exemption: business service, resource owner, exact Azure resource scope, assignment, initiative definition references, category, technical reason, risk, compensating control, requester, approver, ticket, start, expiry, remediation plan, and validation evidence. Put durable identifiers in metadata so the Azure object and governance register can be reconciled automatically. - Choose the correct mechanism. Use an exemption when a tracked resource should remain visible but has a specific mitigation or waiver. Reconsider policy scope, effect, parameters, or an assignment exclusion when the requirement actually applies to a whole designed class rather than an exception. - Minimize scope. Attach the exemption at the lowest appropriate resource hierarchy or individual resource. For initiatives, identify only the necessary definition references. Avoid exempting a subscription from an entire initiative to solve one resource’s problem. - Make time explicit. Require expiresOn for waivers and normally for temporary mitigations. Set the review early enough to test remediation before expiry. If a permanent alternative control is proposed, require evidence and a periodic recertification date in metadata. - Separate duties. Limit who can request, approve, and create exemptions. Review assignments that grant both exemption write and exempt/Action, alert on changes, and use an emergency process that demands prompt retrospective approval. - Verify the result. Confirm the intended resource reports Exempt, inspect compliance substate, and ensure neighboring resources and unrelated initiative definitions remain evaluated. Record a query or portal view that another operator can reproduce. - Close the lifecycle. Before expiry, remediate, renew through a new approval, or accept a documented service impact. After expiry, verify enforcement and application health. Retain the object as evidence where appropriate, but distinguish expired history from active authorization. Use Azure Resource Graph or equivalent reporting to track active and expired exemptions, days to expiry, missing metadata, broad scopes, category, assignment, owner, and compliance substate. Reconcile deleted resources and moved subscriptions because hierarchy changes can affect object existence or applicability. An exemption is healthy only when a decision maker can tell what was bypassed, why, for whom, until when, and what will happen next. Hold a recurring review with policy, security, and service owners. Sample the mitigation evidence rather than accepting metadata at face value, compare waiver age with the promised remediation plan, and challenge repeated renewals. A renewal should be a new risk decision supported by current facts, not an automatic extension because the object already exists. ## Official references - Microsoft Learn, [Azure Policy exemption structure](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure), August 4, 2026. ## Primary reference - Name: Microsoft Learn: Azure Policy exemption structure - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure - Source publication date: 2026-08-04 ## Citation and use Preferred citation: “Give every Azure Policy exemption an owner, scope, expiry, and review,” DSE Security, https://update.dsesecurity.com/updates/azure-policy-exemption-lifecycle/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.