Azure Policy has two assignment units: individual policy definitions, and policy set definitions (called initiatives). Both can be assigned at management group, subscription, or resource group scope. The choice between them is not purely organizational preference — it has real implications for compliance reporting, parameter management, and the operational cost of maintaining your policy posture over time.
Teams that default to assigning individual policies for everything end up with dozens of separate assignments in the Policy blade, compliance scores that aggregate confusingly, and parameter updates that require touching each assignment independently. Teams that default to initiatives for everything end up with complex initiative definitions that are hard to update without disrupting existing compliance baselines.
The right answer is context-dependent, but there's a coherent decision framework.
The Mechanics: What Actually Differs at Evaluation Time
Before the decision framework, a clarification on what's different at the policy engine level between an individual policy assignment and a policy bundled in an initiative.
At evaluation time, there is no functional difference. A policy rule in an initiative is evaluated identically to the same policy rule assigned directly. The deny, audit, modify, and deployIfNotExists effects work the same way. The compliance state calculation uses the same logic.
The differences are administrative:
- Compliance reporting scope: individual policy assignments show as separate line items in compliance reports. Initiative assignments roll up into a single initiative compliance state, with per-policy breakdown available inside the initiative view.
- Parameter inheritance: individual policy assignments have their own parameter set. Initiatives allow parameter definition at the initiative level with pass-through to member policies, or per-policy parameter override within the initiative.
- Assignment propagation: one initiative assignment covers all member policies at the assigned scope. Multiple individual policy assignments must each be propagated separately if you're assigning at management group scope and want them applied to all child subscriptions.
- Exemptions: exemptions can target an individual policy assignment (exempt this resource from this specific policy) or an entire initiative assignment (exempt this resource from all policies in this initiative). Exemption at initiative scope is coarser than you usually want.
When Individual Policy Assignments Make Sense
Individual policy assignments are the right choice when the policy is a standalone enforcement decision that doesn't logically group with others.
Example: you want to enforce that all Azure Key Vaults have soft delete enabled. This is a single, specific control. It doesn't logically belong in a broader "data protection" initiative if there's no other data protection policy you're enforcing at the same scope. Wrapping it in a one-policy initiative adds overhead without benefit.
Individual assignments also make sense when you need fine-grained exemption control. If you have a policy that will need frequent per-resource exemptions — for example, a policy requiring diagnostic settings on VMs, but specific VMs legitimately don't need them — a standalone assignment makes exemption management cleaner than exempting from a broader initiative.
Finally, when you're experimenting. Rolling out a new policy in audit mode before switching to deny is easier to track when the policy is assigned individually. You can see exactly which resources it flags before committing it to an initiative where its compliance score would be aggregated with others.
When Initiatives Are the Right Structure
Initiatives are the right structure when you're enforcing a coherent security or compliance baseline that spans multiple related policy definitions.
The most common correct use case: mapping to an external compliance standard. If you're enforcing CIS Azure Foundations Benchmark or NIST SP 800-53, the standard has dozens to hundreds of controls. Managing these as individual policy assignments is operationally untenable. Azure Policy includes built-in initiative definitions for major standards — the CIS Microsoft Azure Foundations Benchmark initiative bundles over 180 policy definitions. Assigning the initiative once at the management group level gives you a coherent compliance view for the whole standard.
Another valid use case: a team-specific baseline. If you have a DevOps team managing a set of subscriptions with a common governance requirement (e.g., all workloads must use managed identities, must have diagnostic settings pointing to a central log analytics workspace, must have resource locks on production resource groups), bundling those into a "DevOps Team Baseline" initiative and assigning at management group scope is more maintainable than three separate assignments.
A custom initiative definition in Bicep looks like this:
resource devopsBaseline 'Microsoft.Authorization/policySetDefinitions@2021-06-01' = {
name: 'devops-team-baseline'
properties: {
displayName: 'DevOps Team Security Baseline'
description: 'Core security controls for DevOps team subscriptions'
policyType: 'Custom'
parameters: {
logAnalyticsWorkspaceId: {
type: 'String'
metadata: {
displayName: 'Log Analytics Workspace ID'
description: 'Resource ID of the central Log Analytics workspace'
}
}
}
policyDefinitions: [
{
policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/a6fb4358-5bf4-4ad7-ba82-2cd2f41ce5e9'
policyDefinitionReferenceId: 'requireManagedIdentity'
parameters: {}
}
{
policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/a70ca396-0a34-413a-88e1-b956c1e683be'
policyDefinitionReferenceId: 'requireDiagnosticSettings'
parameters: {
logAnalyticsWorkspaceId: {
value: '[parameters(\'logAnalyticsWorkspaceId\')]'
}
}
}
]
}
}The initiative takes a single logAnalyticsWorkspaceId parameter and passes it to the diagnostic settings policy. When you assign the initiative at management group scope, you supply the workspace ID once rather than configuring it per-policy per-assignment.
The Assignment Model at Management Group Scope
Assigning at management group scope is where the inheritance model matters most. An assignment at a management group applies to all subscriptions under that management group — current and future. When a new subscription gets moved into the management group, the policy assignments take effect automatically.
This inheritance behavior is one of the primary reasons to structure your management group hierarchy deliberately. If you have subscriptions with different compliance requirements, they should sit under different management group nodes so you can assign different policy sets at each level.
A common hierarchy pattern:
Tenant Root Group
├── Platform Management Group
│ ├── Identity Subscription
│ ├── Connectivity Subscription
│ └── Management Subscription
└── Workloads Management Group
├── Production Management Group
│ └── [Production Subscriptions]
└── Non-Production Management Group
└── [Dev/Test Subscriptions]In this structure, you assign an org-wide baseline initiative at the Tenant Root Group level — controls that apply everywhere. You assign a stricter production controls initiative at the Production Management Group level. The Platform Management Group gets its own initiative for platform-specific controls that don't apply to workloads.
Each subscription inherits assignments from all parent management groups. The compliance view shows aggregate compliance for the subscription against all applicable policy assignments, which is where the rollup semantics of initiatives become valuable: you can see "Production Compliance Baseline: 94% compliant" as a single metric rather than scanning through forty individual policy assignments.
Parameters: The Initiative Advantage at Scale
Policy parameters are where initiative structure pays off operationally most clearly. Consider a policy that requires a specific allowed set of VM SKUs across all subscriptions, but the allowed SKU list differs between production and non-production environments.
Without initiatives: you have one assignment per subscription (or per management group if the scope is correct), each with its own parameter configuration for allowed SKUs. Updating the allowed SKU list requires updating each assignment independently.
With an initiative: the allowed SKU list is a parameter on the initiative assignment. You have one assignment per management group scope. Updating the parameter requires updating two assignment objects — one for production, one for non-production — regardless of how many subscriptions are in each group.
The parameter inheritance model inside an initiative also allows you to define parameters that apply to multiple policies within the initiative. If five policies in your initiative all reference the same Log Analytics workspace, define that as a single initiative-level parameter rather than five separate policy-level parameters.
The Exemption Granularity Problem
One place where initiatives create friction is exemption management. When you exempt a resource from an initiative assignment, you can either exempt it from the entire initiative (all member policies) or from specific policy definitions within the initiative by specifying policyDefinitionReferenceIds.
resource exemption 'Microsoft.Authorization/policyExemptions@2022-07-01-preview' = {
name: 'legacy-vm-exemption'
scope: resourceGroup('production-rg')
properties: {
policyAssignmentId: initiativeAssignmentId
exemptionCategory: 'Waiver'
expiresOn: '2025-12-31T00:00:00Z'
policyDefinitionReferenceIds: [
'requireManagedIdentity'
]
description: 'Legacy VM cannot use managed identity - migration scheduled Q4 2025'
}
}This correctly exempts the resource only from the managed identity policy within the initiative, not from the entire initiative. But it requires knowing the policyDefinitionReferenceId values from the initiative definition, which means your exemption management process needs visibility into the initiative structure.
For organizations with a large volume of exemptions — legacy workloads being migrated gradually, dev environments with deliberate configuration variations — the initiative exemption model can become operationally complex. If you're expecting more than a handful of exemptions per policy, that's a signal to consider whether the policies in question should be individual assignments rather than bundled in an initiative.
A Decision Rule That Holds in Practice
Group policies into an initiative when: they share a common compliance narrative (map to the same standard, represent a coherent baseline), they share parameters, and they'll be assigned at the same scope with the same lifecycle. Assign individually when: the policy is standalone, you anticipate frequent exemptions, or you need independent lifecycle control (rolling out in audit mode, disabling independently).
The built-in initiatives for compliance standards — CIS, NIST, PCI-DSS — are almost always worth assigning as initiatives rather than picking individual policies from them. The compliance reporting rollup alone justifies the initiative structure when you're mapping to an external standard. For your own custom governance controls, structure by team ownership and lifecycle rather than by technical similarity.