No expiration. No exemption.
The real problem
Most teams do not get in trouble because they created one exemption. They get in trouble because the exemption never leaves. A waiver created for a migration weekend becomes a six-month exception. A workaround for a legacy appliance becomes a normal operating state. Then the policy dashboard still looks clean enough that nobody feels the pain until audit, outage, or incident review.
Azure Policy exemptions are useful because they preserve an explicit record instead of hiding the issue. Microsoft documents that exemptions count toward overall compliance, can be scoped to assignments or initiative members, and can be made time-bound with the expiresOn property. That is exactly why they need stronger operational discipline than a one-line approval in a ticket.
Treat exemptions like leases. Owner, reason, end date, and review cadence are non-negotiable. |
What Azure Policy exemptions actually do
At the platform level, an exemption is a first-class object under Microsoft.Authorization/policyExemptions. The important parts are simple:
It targets a policy assignment or initiative assignment through policyAssignmentId.
If the target is an initiative, you can narrow the exemption to specific policyDefinitionReferenceId values instead of exempting the whole initiative.
The exemptionCategory is either Waiver or Mitigated.
expiresOn is optional in the platform, but once the date passes, the exemption is no longer honored, even though the object remains for record-keeping.
You can use resourceSelectors to narrow the exemption to a subset of resources by location, type, and other supported selector kinds.
That last point matters. The platform lets you be precise. If your internal process still issues broad, permanent exemptions, the tool is not the bottleneck. Your operating model is.
Opinionated blueprint: the minimum standard
This is the floor, not the gold-plated version. If your process does less than this, expect exemption sprawl.
Core record fields
Field | Why it exists | Minimum standard | Example |
Owner | Someone has to carry the risk and renewal decision. | Named service or platform owner, not a shared mailbox. | network-platform |
Ticket reference | Creates an audit trail and change context. | Change, incident, risk, or work item linked in metadata. | CHG-10427 |
Reason | Explains why the policy is being bypassed. | Business reason plus remediation path. | vendor patch pending |
Exemption category | Separates temporary acceptance from alternative control. | Use Waiver for temporary acceptance. Use Mitigated when the intent is met another way. | Waiver |
Expiry | Forces review and prevents forgetting. | Set expiresOn at creation. No blank dates. | 2026-07-15 |
Control fields
These are the fields that stop a valid exemption from decaying into silent debt.
Field | Why it exists | Minimum standard | Example |
Approval | Shows who accepted the risk. | Named approver and approval date in metadata. | approvedBy + approvedOn |
Scope | Keeps blast radius small. | Use the narrowest scope and definition reference possible. | single RG member |
Review cadence | Prevents set-and-forget behavior. | Weekly report, monthly review, renewal by exception only. | 30d |
How long should an exemption live?
I would not let the answer default to forever. Make teams justify longer terms instead of letting them inherit them.
Scope | Default max | When it makes sense | Escalation rule |
Resource or RG | 30-60 days | Short-term migration, break/fix, vendor patch window | Renewal needs fresh evidence |
Subscription | 90 days | Temporary landing zone mismatch or inherited debt | Director or governance approval |
Management group | Avoid if possible | Only for carefully controlled platform transitions | Treat it as an executive-level exception |
Simple policy The burden of proof should increase with scope and duration. The wider the exemption, the shorter the default term and the stronger the approval path. |
Practical operating workflow
1) Make the request concrete Capture the assignment, the exact resource scope, why the policy is being bypassed, and what will make the exemption removable.
2) Narrow the blast radius If the assignment is an initiative, exempt only the relevant policyDefinitionReferenceId values. If only one location or resource type needs relief, use resourceSelectors instead of broad scope.
3) Set expiresOn at creation Do not allow a second step later for adding the date. If the platform allows creation, your process should require expiry before approval.
4) Store operating metadata At minimum, keep requestedBy, approvedBy, approvedOn, ticketRef, owner, and reviewCadence in metadata. Microsoft explicitly supports custom metadata properties for this purpose.
5) Report weekly and review monthly Use Azure Resource Graph to catch expiring items, then force renewal decisions before the clock runs out.
6) Remove or renew with evidence If the issue is fixed, delete the exemption. If it is still needed, make the owner re-justify it and set a new date instead of carrying the old approval forever.
Query pack for aging exemptions
Microsoft publishes an Azure Resource Graph sample to find policy exemptions that expire within 90 days. Start there, then add your own watch lists for items with no expiry and items missing metadata.
Expiring within 90 days
PolicyResources
| where type == 'microsoft.authorization/policyexemptions'
| extend expiresOnC = todatetime(properties.expiresOn)
| where isnotnull(expiresOnC)
| where expiresOnC >= now() and expiresOnC < now(+90d)
| project name, properties.displayName, expiresOnCMissing an expiry date