A compliance percentage is a ratio of resources the engine looked at to resources it approved of. Both halves of that fraction are decisions somebody made, which is why the number can improve without a single resource changing.
Nine states, and the four people misread
Compliant and Non-compliant are the two everybody knows. The other seven carry information that the headline figure throws away.
| State | What it actually tells you |
|---|---|
Exempt | Somebody decided this resource does not have to comply, and recorded it. This is good news compared with the alternative, which is a scope exclusion that produces no state at all. |
Unknown | Only ever appears for a manual policy. It means a human has not attested yet, and it will stay this way indefinitely because nothing automated will ever resolve it. |
Protected | Only ever appears for denyAction coverage. It describes what the assignment can do, not whether the resource is in any particular condition. |
Conflicting | Two or more assignments at the same scope carry contradicting rules, the classic case being two policies appending the same tag with different values. Nobody is winning. This is a design defect being reported as a data point. |
Error | A template or evaluation error. Worth treating as an outage of the control rather than as a compliance reading, because the control is not running. |
Not started | The evaluation cycle has not begun for this policy or resource. Common, temporary, and frequently mistaken for compliance in a screenshot taken too early. |
Not registered | Either the Microsoft.PolicyInsights provider is unregistered, or the account reading the page lacks permission to see compliance data. The second cause matters because the page looks broken rather than restricted. |
Two of those deserve to be reported as work rather than as status. A resource in Conflicting has no governance applied and the estate does not know it. A resource in Error has a control that is not executing. Both hide comfortably inside a percentage that treats them as neither compliant nor non-compliant.
Non-compliance means different things for different effects
For audit, auditIfNotExists and modify, a resource is non-compliant whenever the rule’s condition is true, whether it is new, updated or long-standing. For append, deny and deployIfNotExists, only existing resources report non-compliant, because new and updated ones were already refused or already remediated at request time.
That asymmetry produces a reading trap. A non-compliant count under a deny assignment is a measure of your historical estate and not of anything happening now. It cannot grow from new deployments, because those were blocked. If it is growing, something is bypassing the assignment, and that is a much more interesting finding than the count itself.
The two-condition effects have their own logic and it is the one most often written incorrectly. Under auditIfNotExists and deployIfNotExists, a resource is non-compliant when the if condition is true and the existence condition is false. A rule that reports nothing is usually not a compliant estate. It is an existence condition satisfied by something you did not mean to accept.
The clock
An assignment takes about five minutes to start applying. A newly assigned scope produces its first compliance results in roughly thirty minutes. New and updated resources show up in results within about fifteen. Everything else refreshes on a cycle that runs once every 24 hours.
The practical consequence is that a compliance page is a photograph of a moment up to a day ago, and treating it as live state produces two recurring mistakes. Somebody fixes a resource, refreshes, sees no change and concludes the fix did not work. Or somebody screenshots a clean dashboard for a report without noticing that half the estate is still in Not started. On-demand scans exist through the CLI, PowerShell, REST, the VS Code extension and a GitHub Action, and they are asynchronous, scoped to a subscription or resource group, and slow because they evaluate everything.
One exception is worth knowing before you build anything that depends on triggering a scan. Not every resource provider participates. Virtual Network Manager supports neither on-demand evaluation nor the daily cycle, so a gate waiting on its compliance result waits forever.
Attestations, and controls a scanner cannot see
Manual policies invert the model: the state starts at Unknown and a person moves it by creating an attestation, which can carry a justification, links to evidence, and metadata. The assignment can recommend where evidence should live, through a storage recommendation in its metadata, which is a small feature with a large effect on whether attestations are auditable a year later.
The temptation with manual controls is obvious and I would rather name it than pretend otherwise. Attesting compliance is one command, it requires no evidence to be true, and it turns an uncomfortable Unknown into a comfortable Compliant on a dashboard somebody reports upward. Whether that is governance or theatre depends entirely on the review process wrapped around it, and the product cannot help you there.
An attestation is a claim by a person, stored next to measurements made by a machine, and displayed identically to both.
Scope manual policies at the boundary that matches what is being attested, which is usually a subscription or a management group. A manual control targeting individual resources produces an attestation backlog nobody clears.
How the number goes up without anything improving
There are at least five ways, and I have seen all of them presented as progress. Exclude a non-compliant subscription from the assignment and its resources vanish from the denominator. Exempt them instead and they move to a state most summaries do not count as failure. Set a definition’s effect parameter to Disabled and the rule reports nothing while remaining assigned and looking present in every inventory. Assign a rule whose if condition never matches anything, which is indistinguishable from a rule that matches and passes. Or add a large volume of trivially compliant resources, which raises the ratio without touching a single problem.
None of these require bad faith and most arise from ordinary work. The response is not suspicion, it is measuring the things the percentage omits: how many resources are Not started, how many controls are in Error, how many assignments are Disabled, how many exemptions exist and how many have expiry dates, and whether the denominator moved for a reason anybody can name. Those five figures next to the headline number turn a score into a report.
Where Defender for Cloud takes over
Defender for Cloud’s regulatory compliance experience runs on this engine. The frameworks it offers are initiatives, the controls are definitions, and the manual ones are manual policies. What Defender adds is the framework mapping, the security opinion about which controls matter, and a presentation built for a security audience rather than a platform one.
The seam is worth stating clearly because both products show compliance percentages and they are not the same percentage. Azure Policy answers whether your estate matches the rules you assigned. Defender for Cloud answers whether your estate matches a published standard, using its own selection of controls and its own weighting. A team can raise one and not the other, and the argument that follows is avoidable if somebody says at the start which question is being asked. The Defender series on this site owns that side and this article does not cross into it.
Why there is no build sheet for this article
The reproducible loop here, query compliance, remediate, verify, is already built in the remediation build sheet, and the on-demand scan and attestation commands are single lines that appear where they are used. A separate sheet would repeat both. What this article contributes is knowing which of nine states you are looking at and what the percentage is not telling you, and that is a reading skill rather than a procedure.
From here
This article is about reading a compliance number produced by rules you chose. The next one is about the harder version, where the rules were chosen by a published standard somebody audits you against, the number blends your work with Microsoft’s, and the vendor prints a warning about what it does not mean.
Azure Policy
‹ Previous: [AP 9.1] Build Sheet: The Staged Rollout of a Deny
Next: [AP 11] Regulatory Initiatives: What Azure Can Prove and What It Cannot ›
