Most Azure governance conversations begin with the wrong question. “What policies should we write?” is a technical question. It assumes the hard part is knowing which guardrails to put in place. The hard part is not the guardrails. It is deciding who owns them, who enforces them, and what happens when they are violated. Most governance frameworks fail before anyone opens the Azure portal.
The Three Governance Decisions That Happen Before Any Policy
Who owns governance? Not the team that writes the policies — the team that is accountable for the environment being governed. In most organisations, IT operations, security, and the platform team all have partial ownership, and no single team has accountability. Partial ownership is indistinguishable from no ownership when a violation is discovered.
What is the enforcement model? Audit policies surface violations. Enforce policies prevent them. The choice between audit and enforce is a governance philosophy decision disguised as a technical one. Organisations that choose audit mode indefinitely have made a decision — they just haven’t said it out loud.
What happens when governance is violated? If the answer is “it shows up in the compliance dashboard,” governance is not enforced — it is reported. A governance framework needs a response process: who is notified, what the remediation expectation is, and what the escalation path is for violations that are not resolved.
[DAN: Add a specific example of a governance framework that looked complete on paper but had no response process — what the first significant violation looked like and what the organisation discovered about its governance posture when it happened.]
The Accountability Gap
The most common governance failure is diffuse accountability. Security wants the policies. The platform team writes them. Engineering teams are subject to them. Nobody is accountable for the compliance outcome.
When a violation occurs in a diffuse accountability model, the pattern is predictable: security asks why the policy didn’t prevent it; the platform team explains they wrote the policy but can’t control how it’s applied; engineering says they were never told the policy existed. The violation is genuine. The accountability is nowhere.
The fix is structural: a named owner for the governance posture, with authority to enforce policies and accountability for the compliance score. This is not a committee. It is a person.
What Governance That Works Looks Like From the Outside
A governance framework that is functioning produces recognisable signals:
- Fewer conversations about whether a policy should exist, more conversations about whether an exemption is justified
- Engineering teams know what the guardrails are before they build, not after they deploy
- Compliance score trends upward over time, or is stable — not declining
These signals are not produced by good policy writing. They are produced by a clear accountability model and an enforcement stance that the organisation has actually committed to.
Governance frameworks that work are not distinguished by the quality of their policies. They are distinguished by the clarity of their accountability model and the credibility of their enforcement. Write the accountability model before the first policy.
If your Azure governance framework looks complete on paper but isn’t producing the compliance posture you expect, get in touch — the gap is almost always structural, not technical.
