Azure Governance with Management Groups and Policy
How to structure Azure governance with Management Groups, Azure Policy, RBAC, and tags to keep security, cost, and compliance under control.
Without governance, the cloud becomes the wild west
The ease of creating resources in Azure is a double-edged sword. In minutes, anyone with access spins up a virtual machine, a database, or exposes a service to the internet. Without rules, this becomes chaos: non-standard resources, uncontrolled costs, security gaps, and no traceability. Governance is the set of mechanisms that keeps the cloud's freedom within safe rails.
As a Microsoft partner and CSP, RHC deploys governance that protects without paralyzing — giving teams autonomy within clear boundaries.
The four pillars of Azure governance
| Pillar | Tool | What it solves |
|---|---|---|
| Organization | Management Groups | Hierarchy and rule inheritance |
| Control | Azure Policy | Mandatory technical rules |
| Access | RBAC + Entra ID | Who can do what |
| Traceability | Tags + Cost Management | Cost and accountability |
Management Groups: the hierarchy
Leaving all subscriptions loose, with no structure, makes it impossible to apply rules consistently. Management Groups create a hierarchy above subscriptions, and whatever is applied at one level is inherited by the levels below.
A typical structure:
- Root (Tenant Root) — mandatory policies for the whole organization.
- Platform — identity, network, and management subscriptions.
- Landing Zones — production and non-production, with business workloads.
- Sandbox — experimentation with strict limits.
- Decommission — resources being shut down.
This way, a security rule applied at the root holds for the entire environment, with no need to repeat configuration in every subscription.
Azure Policy: rules that apply themselves
Azure Policy is the engine that turns intent into an automatic technical rule. Unlike a standards document nobody reads, policy acts — it audits, blocks, or fixes resources that deviate from the standard. Examples of common policies:
- Block disallowed regions — prevent resource creation outside approved regions (important for data sovereignty and latency).
- Enforce mandatory tags — reject resources without a cost center or owner.
- Restrict VM sizes — prevent expensive SKUs without approval.
- Require encryption on disks and storage.
- Deny public IP on workloads that should not be exposed.
Policies have effects: audit (only records), deny (blocks), and deployIfNotExists (fixes automatically). Grouping several policies into an initiative makes it easy to apply entire compliance frameworks at once.
RBAC: least privilege
Role-based access control (RBAC), integrated with Microsoft Entra ID, defines who can do what and where. The principle is least privilege: each person gets only the access needed for their role. Best practices:
- Assign roles to groups, not individuals.
- Use specific roles (Contributor of a resource group) rather than broad ones (Owner of the subscription).
- Enable Privileged Identity Management for just-in-time admin access, with approval and time limits.
- Review access periodically.
Tags: the basis of cost and accountability
Without tags, there is no FinOps and no traceability. Each resource should carry at least cost center, environment, project, and owner tags. With consistent tags, Cost Management generates reports by area and the team can answer "who spends what and why". Tags should be enforced by policy, not left to individual goodwill.
Microsoft Defender for Cloud and compliance
Security governance gains an ally in Microsoft Defender for Cloud, which continuously assesses the environment's posture against benchmarks and compliance frameworks, assigning a secure score and pointing to concrete improvement actions. It connects technical governance to regulatory requirements, showing how well the environment adheres to recognized standards.
Deploying governance without blocking the business
The biggest governance risk is excess: too many rules paralyze innovation and become targets for workarounds. The balanced approach:
- Start with auditing (audit effect) to understand the environment before blocking.
- Block the non-negotiable — critical security and compliance.
- Provide sandboxes with limits for free experimentation.
- Automate remediation where possible, reducing friction.
- Review and evolve policies as the environment changes.
Checklist / Key takeaways
- Structure Management Groups for consistent rule inheritance.
- Use Azure Policy to turn standards into automatic control.
- Apply RBAC with least privilege and just-in-time access.
- Enforce mandatory tags for cost and traceability.
- Monitor posture with Defender for Cloud and the secure score.
- Start with auditing, block the essential, and avoid excessive rules.
Well-executed governance is what lets you scale in Azure with security, predictable cost, and compliance — without turning IT into a bottleneck. RHC designs this balance for each client.
Frequently asked questions
Read next
Ready to do more with Microsoft?
Talk to an expert and discover how to optimize licensing, security and productivity.