Upon further reflection of this project, I wanted to shift the mindset from a sterile lab where everything goes right, to a real world simulation of what an engineer should be doing: drinking a lot of coffee and crying at the constant errors. So I took a few steps back and made some changes that reflects more closely, a real world scenario.
Phase 3.5: Lifting Governance to the Management Group
Up to this point, my Security baseline initiative was assigned at the resource group level. That worked for a demo, but it's not how governance actually scales, you don't assign policies one RG at a time across an enterprise. You assign them once, high up, and let inheritance do the work.
This phase was a small change with an outsized impact: moving the same initiative up the hierarchy.
The Hierarchy
I created two Management Groups:
mg-governance-lab— the root, representing the tenantmg-governance-lab-prod— a child, where production subscriptions live
My subscription got moved under mg-governance-lab-prod. Nothing inside the subscription changed — same RG, same resources, same policies — but the scope of governance shifted from "this one RG I'm playing in" to "anything that ever lands in this part of the tenant."
Re-Assigning the Initiative
I re-assigned governance-lab-security-baseline at mg-governance-lab-prod and gave the assignment a system-assigned managed identity. Nothing in the initiative needs that identity yet — but Phase 4 will bring DeployIfNotExists policies for diagnostic settings, and those require an identity with permissions to deploy. Setting it up now means I won't have to re-assign later.
Then I deleted the old RG-scope assignment, but only after confirming the MG-level one was evaluating and reporting compliance correctly. Order matters: never remove the old guardrail before the new one is live.
Why This Matters
The mechanics are trivial. The mindset shift is the whole point.
At an RG scope, policy is a personal tool — I am protecting my sandbox. At an MG scope, policy is organizational infrastructure — every future subscription, every team, every workload that lands beneath this node inherits the baseline automatically. New subscription spun up next quarter? It's already governed on day one. No ticket, no checklist, no hoping someone remembered.
This is the difference between governance as a habit and governance as a system.
The New Baseline
With the assignment lifted, I captured a fresh compliance snapshot at the MG level. This becomes the "before" reading for everything that follows — remediation in Phase 4, Policy-as-Code in Phase 5, and the Audit-then-Deny rollout in Phase 6.
In the background, I've also flipped my blob public-access policy from Deny to Audit for a few days. It'll quietly collect real-world non-compliance data while I work on the next phase, so when I switch it back to Deny, I'll know exactly what I'm about to break — and have an exemption story ready for anything that legitimately needs a waiver.
Scope is a design decision, not a deployment detail. Picking the right one is what turns a policy into a control.