Azure Policy can evaluate resource configurations against organizational rules, but real estates contain legitimate exceptions. A system may meet a control through a different mechanism, or a migration may temporarily require a state that does not comply with the assigned policy. An exemption is a formal way to represent that situation; it is not a proof that the resource is secure or a substitute for remediating noncompliance. The strength of the governance program depends on why the exception exists, how narrowly it is scoped, when it expires, and what evidence demonstrates that the decision is still valid.<\/p>\n
Microsoft distinguishes policy-exemption categories including A policy definition expresses a condition and an associated effect, but its purpose may be broader than its syntax. A policy requiring private connectivity for a key vault aims to reduce exposure to public networks; a policy constraining allowed regions may serve data-residency or operational requirements. Before exempting a resource, articulate the business and security outcome the rule was intended to protect.<\/p>\n Inspect the policy assignment and its scope. A resource may be covered through a management group, subscription, resource group, or individual assignment, and an initiative may contain many policy definitions with different implications. An exemption placed at an unnecessarily broad level could exclude resources that were not part of the original decision. Start with the narrowest scope compatible with the actual exception.<\/p>\n For a grouped initiative, check whether the exemption should refer only to selected policy definition reference IDs instead of the entire initiative. Microsoft supports policy exemption structure fields for this purpose. The decision record should specify which evaluated condition is being bypassed, which other conditions continue to apply, and how the affected resource can be identified after a redeployment or name change.<\/p>\n A A The distinction also matters for audit interpretation. An exemption changes how Azure Policy<\/a> reports the evaluated resource; it does not automatically perform a technical mitigation. A management report should separate \u201cexcluded from policy compliance calculation\u201d from \u201cprotected through an alternative control.\u201d Combining those claims can falsely inflate confidence in the estate’s actual security posture.<\/p>\n An exemption can include an expiration, which provides a useful governance deadline. The expiration date should follow the practical milestone: completion of a migration, expiry of a supplier dependency, scheduled hardware replacement, or next approved architecture review. Arbitrary annual extensions without new evidence turn a temporary exception into perpetual privilege to ignore the control.<\/p>\n Assign a named owner and make the review actionable. Before expiry, collect a fresh configuration snapshot, examine compensating controls, and decide whether the resource can now comply. If the exemption is renewed, record what changed or why the original blocker persists. The organization should not simply copy the previous justification into a new ticket after the owner leaves.<\/p>\n Plan for what happens when an exemption expires. Policy evaluation may again surface a noncompliant resource, and a deny effect can affect future write operations depending on the policy and resource state. Teams should test the operational consequence before an expiry creates a surprise production incident. The goal is not to avoid expiration but to transition deliberately back to compliant enforcement.<\/p>\n An auditor needs more than a screenshot showing \u201cExempt.\u201d Useful evidence includes the exact policy definition and assignment, resource scope, reason for the category, linked change or risk decision, owner, approver, creation and expiration dates, and test output supporting any compensating control. When the exception concerns a network boundary, include the effective network path rather than merely the configured intent.<\/p>\n Record relevant evaluation and activity timestamps. Azure Policy compliance state may lag configuration changes because evaluation is periodic or event-driven according to service behavior. An exemption entered after a resource changed should not be presented as proof that the preceding period was compliant. Distinguish when the noncompliant state existed, when the risk was recognized, and when the waiver or mitigation was authorized.<\/p>\nMitigated<\/code> and Waiver<\/code>. A mitigated state indicates that the policy’s intended outcome is achieved another way, while a waiver accepts a particular noncompliant state. Those are materially different risk statements. The category should be chosen from documented facts, not because one label appears more reassuring on an executive dashboard.<\/p>\nIdentify the original control objective<\/h3>\n
Use the correct category for the accepted risk<\/h3>\n
Mitigated<\/code> exemption should point to a compensating mechanism that actually achieves the policy intent. If a storage resource cannot use the prescribed control but is protected through an equally effective approved architecture, capture the design, boundaries, and validation result. Merely stating that a different firewall exists is not sufficient unless the team has shown that it governs the same exposure.<\/p>\nWaiver<\/code> acknowledges accepted noncompliance. The owner should document the reason, impact, affected data or services, constraints preventing immediate correction, and planned remediation where applicable. A waiver that lasts indefinitely without reassessment may become a way of hiding technical debt from compliance reporting. Its justification should make clear who knowingly accepted the exposure.<\/p>\nBuild expiration into the exception lifecycle<\/h3>\n
Preserve evidence that can be independently checked<\/h3>\n