For most organisations the honest answer to why they use Azure Policy is that somebody signed an obligation. Microsoft ships that obligation as an initiative you can assign in an afternoon, and prints a warning on every page describing what the resulting number does not mean.
The disclaimer is the most important sentence Microsoft writes about this
Every regulatory mapping page carries the same warning, and it says three separate things. There is often no one-to-one or complete match between a control in the standard and the policy definitions attached to it. Compliant in Azure Policy refers only to the policy definitions themselves and does not mean you meet the control. And the standard contains controls that no Azure Policy definition addresses at all.
Microsoft’s own conclusion is that compliance in Azure Policy is a partial view of your overall compliance status. That is not a caveat buried in a footnote, it is the framing the vendor chose, and it is the sentence I would put in front of any executive who has been shown a percentage against a standard they are audited on.
The number measures how many of the mapped definitions pass. It does not measure whether you meet the standard, and Microsoft says so on every page that produces it.
None of which makes the initiatives useless. They are the fastest way to turn a written obligation into something measured continuously across an estate, and continuous partial measurement beats an annual spreadsheet by a wide margin. The failure is not using them. It is presenting their output as an answer to a question they were never built to answer.
Three owners in one number
A regulatory initiative labels every control with a responsibility: Customer, Microsoft, or Shared. That is shared responsibility expressed as data rather than as a diagram, and it is the most useful thing these initiatives do.
The Microsoft-owned controls are the ones worth understanding, because they behave unlike anything else in the product. They carry the policy type Static, the portal sometimes describes them as Microsoft managed, and their compliance results do not come from evaluating your estate at all. They come from third-party audits of Microsoft’s own infrastructure. You cannot influence them, you cannot remediate them, and they are counted.
So a compliance figure against a standard blends work you did with work Microsoft did, and the ratio varies by standard. Anyone reporting the number upward should be able to say which part they earned. It is also, handled well, a genuinely useful conversation with an auditor: here is the boundary, here is what we are responsible for, here is where Microsoft’s attestations carry it, and here is our evidence for our half.
Coverage varies more than anyone expects
The initiatives are not comparable in depth, and the numbers make the point better than an argument does. As at August 2026, the HITRUST and HIPAA initiative carries 589 policy definitions. ISO 27001:2013 carries 448. The Dutch BIO cloud theme in its second version carries 278, New Zealand’s information security manual 209, ISO/IEC 27002:2022 carries 145, ISO/IEC 27017:2015 carries 92, and IRS 1075 carries 43.
The one worth pausing on is ISO/IEC 27001:2022, which carries 58 where the 2013 mapping carries 448. An organisation migrating from the older standard to the current one, which is a sensible and correct thing to do, moves to an initiative with a small fraction of the coverage. The compliance dashboard will very likely look better afterwards while measuring far less. If you are making that transition, say so before the number moves rather than after somebody notices and forms their own theory.
These initiatives are versioned like any other built-in and they move, sometimes substantially. Their change history sits in the Azure Policy GitHub repository under the regulatory compliance set definitions, and for anything you are audited against, that history is worth watching rather than discovering.
The manual half
Every one of these initiatives contains a substantial set of definitions that offer only the manual effect and Disabled, published under identifiers prefixed CMA. They cover the controls no scanner can observe: whether approval is required for account creation, whether label activity is reviewed, whether user groups with access to sensitive data are examined. Their default state is Unknown and nothing automated will ever resolve them.
This is where a compliance programme either becomes real or becomes theatre, and the product cannot decide which. An attestation is one command, requires no evidence to be true, and converts an uncomfortable Unknown into a comfortable Compliant on a dashboard somebody reports upward. The mechanism does let you attach evidence links, an owner, an assessment date and an expiry, and an organisation that uses all four has something an auditor can work with. One that uses none of them has a green square.
Your own framework, in the same shape
Regulatory compliance is not a special product feature. It is built on the grouping portion of an ordinary initiative definition: each group names a control, categorises it into a compliance domain, and references a metadata object describing that control. The only structural requirement is that the initiative’s category is set to Regulatory Compliance.
Which means your internal control framework can be expressed the same way. Microsoft documents that customers can author their own regulatory compliance initiatives, either from scratch or copied from a built-in, and a custom one can be surfaced on the Defender for Cloud dashboard alongside the published standards. For an organisation with its own security standard, this is the most valuable thing in this article: your controls, named as your controls, grouped into your domains, measured continuously, sitting next to ISO and PCI in the same view.
Build it from built-in definitions wherever possible, for all the reasons the customising article gives. The framework is yours. The rules underneath it mostly should not be.
Still a preview
The concept page carries a note saying Regulatory Compliance is a preview feature, and that existing compliance standard initiatives are still being updated to support it. Checked August 2026. That is a striking status for a capability organisations point auditors at, and it is worth knowing before somebody asks you to warrant the output rather than merely present it.
My position is that this changes how you describe the tool and not whether you use it. Assign the standard, measure continuously, attest the manual controls with real evidence, keep the exemption ledger honest, and describe the result as what Microsoft says it is: a partial and continuously updated view of a subset of your obligation. That description is more useful to an auditor than a percentage, and considerably safer for you.
From here
The build sheet that follows assigns a standard to the Northfork estate, separates the controls you own from the ones Microsoft answers for, attests a manual control with evidence and an expiry, and produces the coverage statement that should accompany any compliance figure leaving your team.
Azure Policy
‹ Previous: [AP 10] Compliance: What the Number Means and What It Hides
Next: [AP 11.1] Build Sheet: Assign a Standard, Read Coverage, Attest the Rest ›
