Microsoft’s Azure Policy exemption documentation 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.
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.
\nexpiresOn 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.exempt/Action, alert on changes, and use an emergency process that demands prompt retrospective approval.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.
\nHold 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.
\n\n