A policy in audit mode does not prevent anything. It records that somebody created a storage account with public access and lets the deployment succeed, which is useful for reporting and useless as a control. Most tenants we review have a well designed policy set where the important rules were never switched from audit to deny, usually because nobody wanted to break a deployment.
Knowing what each effect really does
Audit flags non-compliance and permits it. Deny blocks the deployment outright. DeployIfNotExists and Modify change resources so they comply, which is powerful and needs a managed identity with enough rights to make those changes, so that identity becomes worth reviewing in its own right. Assignment scope decides reach: a policy applied at a management group covers everything beneath it, while one applied to a single subscription leaves the rest of the estate untouched. Read the scope and the effect together, because a deny policy assigned to a test subscription is not protecting production.
Exemptions are where control leaks away
Every estate accumulates exemptions, and most have no expiry. A team needs a public endpoint for a migration, an exemption is created, the migration finishes and the exemption remains. Over two years the exemption list becomes a map of the least controlled parts of your tenant. List every exemption with its scope, its reason and its expiry date, remove the ones with no owner, and put an end date on the rest. The NCSC’s cloud security guidance stresses that governance should be verifiable, and an exemption nobody reviews is the opposite of that.
“Ask an engineer to deploy a deliberately non-compliant resource in front of you. It takes two minutes and it settles the argument. Half the time the deployment succeeds, and the room discovers that the compliance dashboard has been describing a control that never blocked anything.”
William Fieldhouse, Director, Aardwolf Security Ltd
Resources that existed before the policy
Deny applies to new deployments and leaves everything created earlier exactly as it was. That is the gap most compliance dashboards obscure, because a resource marked non-compliant sits quietly in a report while looking like a known issue. Work through the existing non-compliant list deliberately: fix what can be fixed, use remediation tasks for the changes that can be automated, and document the remainder as accepted risk with an owner. Otherwise you end up with a policy set that protects the future and a legacy estate nobody addresses.
Testing the guardrails as a control
Treat policy the way you would treat a firewall rule set, and prove it by attempting what should be blocked. Deploy a storage account with public access, a virtual machine with a public address, and an unencrypted disk, then confirm each is refused. Check who can create exemptions or alter assignments, since that permission undoes everything else. An Azure cloud security assessment covers both the policy set and the identities that can change it, while cloud vulnerability scanningcatches the configuration drift that appears between reviews.
Frequently asked questions about Azure Policy
These questions come up when a governance baseline is being tightened.
Should you start in audit mode?
Yes, briefly. Audit shows the impact before you enforce, which avoids breaking deployments on day one. Set a date to switch to deny at the same time you enable audit, or the temporary state becomes permanent.
Does policy replace role-based access control?
No. Access control decides who may act, and policy decides what may exist. You need both, and the interesting gaps appear where somebody has the rights to change the policy that constrains them.
