Governance Is Not the Same as Control Everywhere
When organizations first discuss Azure governance, the conversation can become a list:
Naming.
Tags.
Policies.
RBAC.
Regions.
Budgets.
Security.
Resource locks.
Approval.
Standards.
All of those can matter.
But governance should begin one level higher:
What behavior are we trying to make consistent, and why?
Microsoft describes Azure governance as supporting compliance auditing and automated guardrails. Azure Policy complements RBAC by evaluating resource configuration while RBAC controls what authorized principals are allowed to do. Microsoft Learn: Azure governance design area
A useful distinction is:
RBAC: Who can perform an action?
Azure Policy: Is the resulting configuration allowed or compliant?
Those mechanisms solve different problems.
Start With Risks, Not the Azure Policy Catalog
Azure contains many built-in policy definitions.
That does not mean you need to assign all of them.
A small organization should start by identifying the things it genuinely cares about.
Security:
Can workloads expose storage or services publicly?
Cost:
Which regions or expensive resource families require tighter control?
Operations:
Must critical resources send required logs?
Ownership:
Can we tell which team owns a production resource?
Compliance:
Are there configurations that business or regulatory requirements prohibit?
Then map controls to those questions.
This prevents a common governance failure:
Deploying controls before anybody can explain the risk they address.
Use Three Governance Levels
A simple framework is:
1. Must enforce
Failure creates unacceptable risk.
Examples could include particular security or compliance requirements.
2. Must observe
The organization needs visibility before deciding whether enforcement is appropriate.
3. Should standardize
Consistency is valuable, but blocking deployment may cause more harm than the inconsistency itself.
| Level | Typical response | Question |
|---|---|---|
| Must enforce | Deny / controlled remediation | Is violation unacceptable? |
| Must observe | Audit | Do we need evidence first? |
| Should standardize | Guidance / automation | Is consistency worth blocking delivery? |
This creates proportionate governance.
Not every preference becomes a deployment blocker.
Audit Before You Deny
This is one of the strongest practical Azure Policy rules.
Microsoft currently recommends beginning with audit or auditIfNotExists rather than immediately applying enforcement effects such as deny, modify, or deployIfNotExists. That allows teams to understand the effect on existing and new resources before enforcement changes deployment behavior. Microsoft Learn: Azure Policy overview
A sensible policy lifecycle is:
Define → Audit → Review impact → Remediate → Test enforcement → Enforce
Why?
A policy that sounds harmless can interact with:
- existing resources;
- deployment pipelines;
- service-specific requirements;
- third-party templates;
- autoscaling;
- inherited assignments.
Blocking production deployment is a poor way to discover that interaction.
Visibility first gives the organization evidence.
Then enforcement can be deliberate.
Do Not Measure Governance by Policy Count
A platform with 300 policies is not necessarily better governed than one with 30.
The useful questions are:
- Does each policy have an owner?
- Can someone explain the requirement?
- Is its scope correct?
- Is the effect appropriate?
- Do workload teams understand failures?
- Is remediation defined?
- Are exceptions tracked?
- Is the policy still required?
Policy count can actually become a warning sign if controls accumulate without lifecycle management.
Microsoft recommends using initiatives to group policy definitions around common goals and managing policy definitions, initiatives, and assignments as code as the governance practice matures. Microsoft Learn: Azure Policy overview
The objective is manageable governance, not a large inventory.
Scope Is Part of the Policy
A good policy at the wrong scope is still a bad implementation.
Azure Policy can be assigned across hierarchy levels.
That means an overly broad assignment can affect many subscriptions and workloads.
Before assigning a policy, ask:
Who needs this control?
Which workloads do not?
Should this be tenant-wide, management-group-wide, subscription-specific, or narrower?
This is another reason management-group architecture matters.
Management groups allow subscriptions with similar governance requirements to inherit common policy without duplicating assignments everywhere. Microsoft’s landing-zone principles explicitly connect policy-driven governance with scalable management-group and subscription organization. Microsoft Learn: Azure landing zone design principles
Governance design and resource organization are therefore connected.
Exceptions Are Part of Governance—Not Evidence That Governance Failed
Real environments have exceptions.
The dangerous model is pretending they do not.
A new Azure service may not fit an old rule.
A migration may temporarily require a nonstandard configuration.
A legacy application may need remediation before it can comply.
The question is not:
“Can exceptions exist?”
It is:
“Can every exception be explained, owned, tracked, and revisited?”
Azure Policy supports exemptions that can identify resources or scopes not evaluated against an assignment, including the ability to represent waiver or mitigation scenarios and to set expiration. Microsoft distinguishes these from broad exclusions and recommends exemptions for more specific or time-bound cases that should remain visible in compliance reporting. Microsoft Learn: Azure Policy exemptions
A useful exception record should include:
- business reason;
- policy involved;
- affected scope;
- risk owner;
- mitigating control;
- approval;
- review date;
- expiration where appropriate.
An exception with an owner is governance.
An undocumented workaround is drift.
Tags Should Support Decisions
Tagging is another area where governance can become bureaucracy.
Organizations sometimes create large required-tag catalogs because tags seem free.
Then nobody maintains them.
A good tag should answer a real operational, financial, security, or lifecycle question.
Examples might include:
- Who owns this?
- Which application does it support?
- Which cost center is responsible?
- What environment is it?
- Which lifecycle or support process applies?
Avoid requiring information nobody uses.
And be careful about assuming every governance problem can be solved with a tag.
Subscriptions, resource groups, naming, management groups, CMDBs, Azure Resource Graph, and other sources may be better for some information.
The decision rule:
If nobody can explain which decision a tag supports, reconsider whether it should be mandatory.
Governance Needs an Exception Owner and a Remediation Owner
Many governance programs define the rule but not what happens next.
Policy marks a resource non-compliant.
Who fixes it?
A deployment is denied.
Who helps the application team understand why?
A legitimate exception is needed.
Who approves it?
An exemption expires.
Who reviews it?
Without those answers, Azure Policy becomes a reporting system or an obstacle rather than governance.
A simple responsibility model is:
| Responsibility | Owner should be clear |
|---|---|
| Define requirement | Security / platform / compliance |
| Implement policy | Platform engineering |
| Remediate workload | Workload owner |
| Approve exception | Risk/control owner |
| Review compliance | Governance/platform owner |
The exact organizational titles will vary.
The ownership must not.
Policy as Code Becomes Valuable When Governance Changes Regularly
A few early policy assignments may be manageable manually.
As governance grows, manual changes become harder to review and reproduce.
Microsoft’s Policy as Code guidance recommends keeping policy definitions in source control, testing and validating changes, and progressing policy changes through controlled environments before broad production enforcement. Microsoft Learn: Policy as Code
This gives governance the same characteristics we want from infrastructure:
- version history;
- peer review;
- repeatability;
- testing;
- rollback context;
- consistent deployment.
Again, the rule is not:
“Everything must be automated on day one.”
It is:
When governance becomes repeatable and consequential, manage it like consequential infrastructure.
Avoid Governance That Encourages Shadow Paths
There is another failure mode.
Controls become so restrictive that teams cannot deliver.
Subscription provisioning takes weeks.
Every new service requires manual approval.
Policy failures have no clear explanation.
Sandbox experimentation is impossible.
What happens?
Teams look for another route.
Microsoft’s landing-zone design guidance explicitly warns that slow or complicated subscription processes can push teams toward unmanaged subscriptions or alternative tenants—creating shadow IT. Microsoft Learn: Azure landing zone design principles
Governance must therefore protect the organization and preserve a usable delivery path.
A good guardrail says:
“Here is the safe way to do this.”
A bad guardrail only says:
“No.”
Provide a Place to Experiment
Not every Azure experiment belongs under production controls.
Microsoft’s landing-zone guidance explicitly recognizes sandbox subscriptions as environments where teams can explore Azure services with intentionally different restrictions while remaining separated from governed production landing zones. Microsoft Learn: Management group architecture
That is an important governance lesson.
Sometimes the solution to excessive exceptions is not weakening production controls.
It is creating an appropriate place for experimentation.
The platform can say:
Production has these guardrails.
Sandbox has different guardrails.
That is clearer than pretending every environment has identical risk.
Warning Signs That Governance Is Becoming Bureaucracy
Watch for these patterns:
- every policy uses
deny; - nobody knows why a policy exists;
- teams discover policies only when deployments fail;
- exemptions never expire;
- every tag is mandatory;
- subscription creation requires many manual approvals;
- policies are edited directly in production;
- the governance team owns rules but nobody owns remediation;
- sandbox experimentation is impossible;
- exceptions outnumber compliant patterns;
- teams create resources outside the governed environment to move faster.
Governance should reduce disorder.
If it primarily creates workarounds, reconsider the design.
A Practical Governance Checklist
Before adding another policy, ask:
- What risk or requirement does this control address?
- Who owns that requirement?
- Should we audit or enforce?
- Have we observed the impact before enforcing?
- Is the assignment scope correct?
- Does the workload team understand how to comply?
- Is remediation defined?
- Can legitimate exceptions be requested?
- Does an exception have an owner and review date?
- Are tags connected to real decisions?
- Are policies grouped meaningfully into initiatives?
- Should this governance configuration be managed as code?
- Is there a safe sandbox path for experimentation?
- Are our guardrails making compliant deployment easier?
If those questions have good answers, governance is likely serving the platform rather than dominating it.
Govern the Risk, Not the Engineer
Azure governance should provide consistency at a scale humans cannot manage manually.
That is its value.
Use policy to make important expectations visible.
Begin with audit where uncertainty exists.
Enforce when the requirement justifies blocking behavior.
Keep exceptions visible and owned.
Treat policy configuration as code as it matures.
And preserve an approved path for experimentation.
BI Cloud Tech’s Governance & Standards service, Azure Landing Zone expertise, and Landing Zone Readiness Assessment are relevant existing resources for organizations evaluating how much governance their Azure platform actually needs.
Good governance does not make every Azure decision centrally. It creates boundaries inside which teams can make more decisions safely for themselves.
