Azure Policy defines which resources are allowed to exist; Azure role-based access control defines who is allowed to manage them.
Azure governance is the operating model that brings those controls together with identity, monitoring, cost management, security posture, and compliance evidence. A well-governed Azure environment gives teams room to build while keeping subscriptions aligned with security standards, financial controls, and regulatory obligations.
Last updated for 2026 guidance: several Azure governance names and patterns have changed over time. Azure Security Center is now Microsoft Defender for Cloud, and Azure Blueprints is deprecated; modern governance design usually relies on management groups, Azure landing zones, Azure Policy initiatives, infrastructure as code, and carefully scoped access controls instead.
Governance starts with structure, not individual resources
Governance decisions are difficult to retrofit once subscriptions have grown in different directions. The practical starting point is usually a management group hierarchy that reflects ownership, risk, and operating model rather than a flat collection of subscriptions. Microsoft’s Azure governance guidance frames these services as a way to apply consistent rules across cloud environments, but the design still needs to match the organisation.
A common pattern is to keep platform subscriptions separate from application landing zones. Connectivity, identity, management, and security services sit in controlled platform areas, while application teams receive governed subscriptions through a subscription vending process. That process can pre-apply policy assignments, role assignments, budgets, diagnostic settings, and required tags before a product team starts deploying workloads.
The hierarchy below is only a starting model. Regulated environments, acquisitions, regional operating companies, and delegated business units may need a different shape, but the goal is the same: apply broad controls high in the hierarchy and reserve workload-specific decisions for lower scopes.
Example — management group hierarchy for governed subscriptions
- Tenant root group
- Platform
- Identity
- Connectivity
- Management
- Landing zones
- Production
- Non-production
- Sandbox
This structure separates shared platform responsibilities from workload ownership. In practice, teams should test policy inheritance before scaling the model, because a deny policy assigned too high in the hierarchy can block legitimate platform operations as easily as it blocks risky deployments.
Landing zone design is also where cost governance becomes visible. Tags for application, owner, environment, data classification, and cost centre should be agreed before subscription vending becomes routine. Without a tagging taxonomy, FinOps reporting becomes a cleanup exercise rather than a governance control.
Azure Policy sets technical guardrails
Azure Policy evaluates resources against defined rules. It can deny non-compliant deployments, audit them, append or modify properties, or deploy supporting configuration when it is missing. This makes it suited to technical guardrails such as allowed regions, required tags, diagnostic settings, encryption requirements, and network exposure controls.
Azure Policy should not be treated as a last-minute compliance layer. It works best when policy definitions and initiatives are managed like application code: stored in version control, reviewed through pull requests, tested in sandbox subscriptions, and rolled out gradually. A safer release path is to start with audit effects, validate the findings, then move to deny or modify effects where the operational impact is understood.
Built-in policies and initiatives should be reviewed before writing custom policies. Many teams create custom definitions too early, then discover later that built-ins already covered the requirement and were easier to maintain. Built-ins also help with common baselines such as the Azure Security Benchmark, which can be used as a measurable starting point for security governance.
The following policy definition illustrates a simple guardrail: storage accounts must use secure transfer. It is intentionally narrow, because effective governance usually comes from many focused controls grouped into initiatives rather than a few overly complex policies.
Example — Azure Policy definition for secure transfer on storage accounts
{
"properties": {
"displayName": "Require secure transfer for storage accounts",
"policyType": "Custom",
"mode": "Indexed",
"description": "Audit storage accounts where secure transfer is not enabled.",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
"notEquals": true
}
]
},
"then": {
"effect": "audit"
}
}
}
}
The important design choice is the effect. Using audit first gives platform and application teams evidence before enforcement begins. Once false positives and legacy exceptions have been handled, the same control may be moved into a stronger initiative with a deny effect for new deployments.
Operationally, policy assignments can be managed through the Azure portal under Policy > Assignments, or through infrastructure-as-code tools such as Bicep, Terraform, Template Specs, and CI/CD pipelines in GitHub Actions or Azure DevOps. Canary assignments are useful: apply a new initiative to a sandbox or one non-production subscription, inspect compliance results, then expand the assignment scope.
RBAC controls actions, scope, and separation of duties
Azure role-based access control governs what a principal can do at a given scope. Built-in roles such as Owner, Contributor, and Reader are useful starting points, but production governance usually requires more care than assigning broad roles at subscription level. Role assignments should be scoped to management groups, subscriptions, resource groups, or resources according to the work being performed.
RBAC and Microsoft Entra roles are related but distinct. Azure RBAC controls access to Azure resources. Microsoft Entra roles control directory and identity administration in Microsoft Entra ID. Confusing the two can lead to gaps where a user has too much control over infrastructure, identity, or both.
Role sprawl is one of the most common governance problems in mature Azure estates. It often begins with temporary Contributor or Owner assignments that never expire, service principals with broad permissions, and custom roles copied across subscriptions without review. Least privilege requires periodic access reviews, privileged access workflows, and a clear owner for custom roles.
The following custom role shows the principle in a limited form. It permits a network operations team to read network resources and manage network security groups, without granting broad rights across the whole subscription.
Example — custom RBAC role for network security group operations
{
"Name": "Network Security Group Operator",
"IsCustom": true,
"Description": "Manage network security groups without broad subscription administration rights.",
"Actions": [
"Microsoft.Network/networkSecurityGroups/*",
"Microsoft.Network/virtualNetworks/subnets/read",
"Microsoft.Resources/subscriptions/resourceGroups/read"
],
"NotActions": [],
"AssignableScopes": [
"/subscriptions/00000000-0000-0000-0000-000000000000"
]
}
The role is deliberately narrow. Before assigning a custom role, teams should verify whether a built-in role already meets the need and whether the assignable scope can be restricted further. Broad custom roles can become harder to reason about than built-in roles if they are not reviewed.
Compliance is a continuous evidence process
Compliance in Azure is not the same as legal compliance, and cloud tooling cannot replace legal interpretation. It can, however, help implement and evidence technical controls that support obligations under frameworks and regulations such as GDPR, HIPAA, and ISO/IEC 27001.
Microsoft Defender for Cloud is the current service for security posture management and regulatory compliance views. The old Azure Security Center name still appears in some legacy marketplace references, including the Azure Security Center marketplace listing, but governance teams should plan around Microsoft Defender for Cloud terminology and capabilities.
Defender for Cloud’s regulatory compliance dashboard maps assessed resources against selected standards and recommendations. A useful operating rhythm is to review the dashboard with policy compliance results, vulnerability findings, and exception registers rather than treating it as a separate security report. The dashboard helps prioritise remediation, but the underlying ownership still sits with platform and workload teams.
Annotated view of how regulatory compliance evidence is typically interpreted: standard, control area, resource status, and remediation path:
- Defender for Cloud regulatory compliance view
- Standard or benchmark
- Control family
- Passed resources
- Failed resources
- Exempted resources
- Recommendation details and remediation guidance
Exception management deserves careful design. A policy exemption should have a business reason, owner, review date, and evidence trail. Open-ended waivers create audit friction and can hide technical debt; time-bound exemptions make risk visible and give teams a trigger to revisit the decision.
Data governance also sits alongside these controls. Azure Policy can enforce resource configuration, RBAC can restrict access, and encryption can protect data, but data discovery, classification, and lineage are usually handled through Microsoft Purview. That distinction matters because a compliant storage account configuration does not automatically prove that sensitive data is known, classified, and governed through its lifecycle.
Monitoring and audit signals keep governance measurable
Governance controls need feedback. Azure Monitor provides metrics and logs for Azure resources, while Log Analytics gives teams a workspace for querying operational and security data. These services help turn policy decisions into measurable outcomes.
The Azure Activity Log is especially important for governance because it records control-plane operations. Role assignment changes, policy assignments, resource deployments, and network security changes can be reviewed and correlated with incidents or audit requests.
Monitoring should be enabled through platform standards rather than manual configuration. Diagnostic settings, workspace destinations, retention expectations, and alert routing can be deployed as part of the landing zone or subscription vending process. This reduces the chance that a workload goes live without the logs needed for security investigation or compliance evidence.
Security controls support governance at the resource layer
Governance is often discussed at the management group and subscription level, but resource-level configuration still matters. Encryption, network filtering, identity-based access, and secure defaults are the controls auditors and security teams eventually inspect in deployed workloads.
Azure encryption guidance explains how data can be protected at rest and in transit. Where workloads manage their own keys, key material should be protected through dedicated key management services rather than stored in deployment scripts, source repositories, or application settings.
Network security groups remain a core control for filtering traffic to and from Azure subnets and network interfaces. They should be paired with route design, private connectivity, firewall controls where appropriate, and policy rules that prevent unnecessary public exposure.
The decision framework is straightforward: use Azure Policy to define allowed configurations, RBAC to define permitted actions, Defender for Cloud to assess posture and regulatory alignment, Azure Monitor to capture evidence, and Microsoft Purview to understand sensitive data. Misusing one tool to solve another tool’s problem is a frequent source of rework.
Why Azure Blueprints is no longer the preferred path
Azure Blueprints provided a way to package policy assignments, role assignments, templates, and resource groups for repeatable environments. That pattern was useful, but Azure Blueprints is now deprecated, so new governance designs should not depend on it as the primary approach.
The modern replacement is not a single service. Azure landing zones provide the architectural pattern, Azure Policy initiatives provide guardrails, Bicep or Terraform can deploy infrastructure as code, Template Specs can package reusable Azure Resource Manager templates, and deployment workflows can apply changes through tested pipelines. Deployment Stacks may also be relevant where teams need managed lifecycle control for collections of Azure resources, but adoption should follow current Microsoft guidance and service maturity.
This shift has practical consequences for DevOps. Governance artifacts should move through the same engineering practices as workload code: versioning, review, automated validation, staged rollout, and rollback planning. Platform teams that manage policy and RBAC manually in the portal often struggle to explain exactly when a control changed and why.
Building governance that teams can operate
Good Azure governance is neither a one-time design document nor a collection of isolated controls. It is an operating discipline that connects management group structure, landing zone automation, Azure Policy, RBAC, Defender for Cloud, monitoring, data governance, and exception handling into one repeatable model.
The most effective next step is to choose a small set of enforceable standards, test them in a non-production subscription, and build a release process around them before expanding. Teams that need structured Microsoft cloud skills can use Readynez Microsoft training as one route to deepen understanding of Azure administration, security, and governance practices without treating certification as a substitute for operational design.
