There is a test I run when I want to understand whether an organisation’s Azure governance is real or performative. I find an engineer who works in the environment — not the person who owns the governance framework, not the security lead, not the platform architect — and I ask them one question: has a deployment you tried to make ever been blocked by a governance policy?
In an environment with genuine governance, the answer is yes. Usually quickly. Engineers in governed environments bump into enforcement. In a governance theatre environment, the answer is different. They say “we have policies” and then pause. They cannot name a policy that has ever stopped them doing something.
That pause tells you everything.
The Compliance Fudge: I have seen countless instances of “compliance score fudging.” The typical defense is: “Look how good our new workloads are! The non-compliant stuff is just legacy.” My question is always the same: What are you actually doing to remediate those non-compliant resources? If you are only governing the 20% of your estate that is new, while leaving the 80% legacy debt to drift, your “95% compliance score” is a work of fiction.
Governance that does not change behaviour is not governance. It is documentation. Audit mode policies are a reporting tool. They do not stop anything from happening. An environment built entirely on audit mode policies is a compliance reporting framework wearing governance branding.
The accountability version of this test is equally revealing. Ask the organisation who is accountable for the compliance posture. If the answer is a team name, a framework document, or a process, the answer is effectively nobody.
Related governance challenges: This accountability gap is structural. See Why Azure Governance Fails Before Anyone Writes a Policy to understand the three foundational decisions that must happen before any policy is written.
Testing the ‘Deny’ Switch: People are always nervous to switch from Audit to Deny in production—they fear the “breaking change.” My argument is that UAT environments are not just for users. They are for testing these governance processes too. If you aren’t testing your “Deny” policies in lower environments to see what breaks and how to resolve it, you are wasting your best laboratory. You shouldn’t be “hoping” it works in production; you should have the evidence from UAT that it does.
What makes this sustainable as a fiction is that auditors often collude with it structurally. An external audit asks: do you have a governance framework? Yes. Are policies defined? Yes. The audit passes. The audit has not asked whether any of those policies are in enforce mode. It has checked for the presence of documents and dashboards, which are easy to produce and mean almost nothing on their own.
The comfortable fiction holds until something forces the question. A breach, a regulatory investigation, or a significant misconfiguration. Then the question changes. It is no longer “do you have policies?” It is “did you enforce them?” And at that point, a compliance dashboard full of audit mode findings is not a defence. It is a record of how long the organisation knew about its own gaps and did nothing about them.
Having a governance framework and having governance are not the same thing. One is a set of documents. The other is a set of behaviours that the environment enforces, with a named human accountable for the outcome.
