Edit

Azure Policy compliance states

  • Article

How compliance works

When initiative or policy definitions are assigned, Azure Policy determines which resources are applicable then evaluates those which haven't been excluded or exempted. Evaluation yields compliance states based on conditions in the policy rule and each resources' adherence to those requirements.

Available compliance states

Non-compliant

Policy assignments with audit, auditIfNotExists, or modify effects are considered non-compliant for new, updated, or existing resources when the conditions of the policy rule evaluate to TRUE.

Policy assignments with append, deny, and deployIfNotExists effects are considered non-compliant for existing resources when the conditions of the policy rule evaluate to TRUE. New and updated resources are automatically remediated or denied at request time to enforce compliance. When a previously existing non-compliant resource is updated, the compliance state remains non-compliant until the resource deployment and Policy evaluation complete.

Note

The DeployIfNotExist and AuditIfNotExist effects require the IF statement to be TRUE and the existence condition to be FALSE to be non-compliant. When TRUE, the IF condition triggers evaluation of the existence condition for the related resources.

Policy assignments with manual effects are considered non-compliant under two circumstances:

  1. The policy definition has a default compliance state of non-compliant and there is no active attestation for the applicable resource stating otherwise.
  2. The resource has been attested as non-compliant.

To determine the reason a resource is non-compliant or to find the change responsible, see Determine non-compliance. To remediate non-compliant resources for deployIfNotExists and modify policies, see Remediate non-compliant resources with Azure Policy.

Compliant

Policy assignments with append, audit, auditIfNotExists, deny, deployIfNotExists, or modify effects are considered compliant for new, updated, or existing resources when the conditions of the policy rule evaluate to FALSE.

Policy assignments with manual effects are considered compliant under two circumstances:

  1. The policy definition has a default compliance state of compliant and there is no active attestation for the applicable resource stating otherwise.
  2. The resource has been attested as compliant.

Error

The error compliance state is given to policy assignments that generate a system error, such as template or evaluation error.

Conflicting

A policy assignment is considered conflicting when there are two or more policy assignments existing in the same scope with contradicting or conflicting rules. For example, two definitions that append the same tag with different values.

Exempt

An applicable resource has a compliance state of exempt for a policy assignment when it is in the scope of an exemption.

Note

Exempt is different than excluded. For more details, see scope.

Unknown

Unknown is the default compliance state for definitions with manual effect, unless the default has been explicitly set to compliant or non-compliant. This state indicates that an attestation of compliance is warranted. This compliance state only occurs for policy assignments with manual effect.

Protected

Protected state signifies that the resource is covered under an assignment with a denyAction effect.

Not registered

This compliance state is visible in portal when the Azure Policy Resource Provider hasn't been registered, or when the account logged in doesn't have permission to read compliance data.

Note

If compliance state is being reported as Not registered, verify that the Microsoft.PolicyInsights Resource Provider is registered and that the user has the appropriate Azure role-based access control (Azure RBAC) permissions as described in Azure RBAC permissions in Azure Policy. To register Microsoft.PolicyInsights, follow these steps.

Not started

This compliance state indicates that the evaluation cycle hasn't started for the policy or resource.

Example

Now that you have an understanding of what compliance states exist and what each one means, let's look at an example using compliant and non-compliant states.

Suppose you have a resource group - ContosoRG, with some storage accounts (highlighted in red) that are exposed to public networks.

Diagram of storage accounts exposed to public networks in the Contoso R G resource group.

In this example, you need to be wary of security risks. Assume you assign a policy definition that audits for storage accounts that are exposed to public networks, and that no exemptions are created for this assignment. The policy checks for applicable resources (which includes all storage accounts in the ContosoRG resource group), then evaluates those resources that aren't excluded from evaluation. It audits the three storage accounts exposed to public networks, changing their compliance states to Non-compliant. The remainder are marked compliant.

Diagram of storage account compliance in the Contoso R G resource group.

Compliance rollup

Compliance state is determined per-resource, per-policy assignment. However, we often need a big-picture view of the state of the environment, which is where aggregate compliance comes into play.

There are several ways to view aggregated compliance results in the portal:

Aggregate compliance view Factors determining compliance state
Scope All policies within the selected scope
Initiative All policies within the initiative
Initiative group or control All policies within the group or control
Policy All applicable resources
Resource All applicable policies

Comparing different compliance states

So how is the aggregate compliance state determined if multiple resources or policies have different compliance states themselves? Azure Policy ranks each compliance state so that one "wins" over another in this situation. The rank order is:

  1. Non-compliant
  2. Compliant
  3. Error
  4. Conflicting
  5. Protected (preview)
  6. Exempted
  7. Unknown (preview)

Note

Not started and not registered aren't considered in compliance rollup calculations.

With this ranking, if there are both non-compliant and compliant states, then the rolled up aggregate would be non-compliant, and so on. Let's look at an example:

Assume an initiative contains 10 policies, and a resource is exempt from one policy but compliant to the remaining nine. Because a compliant state has a higher rank than an exempted state, the resource would register as compliant in the rolled-up summary of the initiative. So, a resource only shows as exempt for the entire initiative if it's exempt from, or has unknown compliance to, every other single applicable policy in that initiative. On the other extreme, a resource that is non-compliant to at least one applicable policy in the initiative has an overall compliance state of non-compliant, regardless of the remaining applicable policies.

Compliance percentage

The compliance percentage is determined by dividing Compliant, Exempt, and Unknown resources by total resources. Total resources include resources with Compliant, Non-compliant, Unknown, Exempt, Conflicting, and Error states.

overall compliance % = (compliant + exempt + unknown + protected)  / (compliant + exempt + unknown + non-compliant + conflicting + error + protected)

In the image shown, there are 20 distinct resources that are applicable and only one is Non-compliant. The overall resource compliance is 95% (19 out of 20).

Screenshot of policy compliance details from Compliance page.

Next steps