Reviewing an Azure Landing Zone for Compliance: What a Defensible Foundation Looks Like
What I actually check when I review an Azure landing zone for compliance: policy scope and effect at the management group, the real NSG rules, the firewall mode, the identity baseline.
Marc Dekeyser |
Reviewing an Azure Landing Zone for Compliance: What a Defensible Foundation Looks Like
TL;DR: a landing zone is compliant when its controls are enforced at the management group and every subscription inherits them by construction.
Two Azure landing zones can look identical in the architecture document and only one of them survives an audit. The diagram doesn’t show the difference. It can’t.
I assess Azure estates for a living, and that gap is most of my job. A landing zone is compliant when its controls are enforced at the management group level, so every subscription inherits them by construction. It’s documented as compliant when those same controls live on a diagram and nowhere else. The review that matters checks the second against the first.
A diagram is a memory of an intention. The control plane is the fact.
So the drawing shows hub-and-spoke networking, policy enforcement, segmented identity, a clean subscription hierarchy. The running configuration shows what got deployed and what drifted afterward. Findings live in the gap. I measure that gap instead of trusting the picture that hides it.
The management group hierarchy
Get this wrong and every control underneath it is optional.
The hierarchy is the skeleton the whole landing zone hangs on. Its shape decides one thing: whether a new subscription is governed the moment it’s created, or the moment somebody remembers to configure it.
The Cloud Adoption Framework describes the defensible shape. A top-level management group under the tenant root. Below it, a layer that separates platform subscriptions (identity, management, connectivity) from landing zone subscriptions (the workloads), plus a dedicated group for sandbox and decommissioned subscriptions. The point of all that structure is altitude: apply a control broadly where it’s universal, narrowly where it’s workload-specific.
What I find most often is a flat hierarchy. Subscriptions hanging straight off the tenant root, or one management group holding everything. Flatten it and there’s no altitude left to apply an inherited control from, so controls get applied per subscription instead.
Which is the next finding.
Scope beats the policy
The single most consequential thing in one of these reviews isn’t which policies got assigned. It’s where.
Azure Policy assigned at the management group is inherited. Every subscription beneath it receives the control automatically, including the ones that don’t exist yet. Assign the same policy per subscription and you’ve built a control that depends on a human repeating a step for every new subscription, forever.
That step gets missed. You already know which subscription I mean.
“Hold on. We assigned the whole regulatory compliance initiative. Isn’t that the job done?”
Not on its own. The policies might be right. The initiative might be right too, because Azure Policy groups related policies into initiatives and the regulatory-compliance ones map to recognised baselines. None of that helps if it’s assigned at subscription scope. The control then protects only the subscriptions that existed the day someone assigned it. Spin up a new one and it starts life ungoverned.
Effect matters as much as scope. A policy in Audit reports violations. It doesn’t stop them. A policy in Deny stops the non-compliant resource from being created at all. A defensible landing zone uses Deny for the controls that have to hold (no public IP on a database, no storage account without secure transfer, no resource without mandatory tags), assigned at the management group, inherited everywhere. What I usually find instead is the right policies sitting in Audit, generating a stream of violations nobody actions, at the wrong scope.
I have argued with an architecture diagram for longer than I want to admit before it occurred to me to go and read the actual assignment. The assignment won.
| Control plane property | Defensible configuration | Common finding |
|---|---|---|
| Management group hierarchy | CAF-aligned, platform/workload separation | Flat, subscriptions on tenant root |
| Policy scope | Assigned at management group, inherited | Assigned per subscription, not inherited |
| Policy effect | Deny for must-hold controls |
Audit only, reports, prevents nothing |
| New subscription governance | Inherited automatically | Ungoverned until manually configured |
Where the diagram stops matching the network
The diagram diverges from reality at the two points it was never able to show: the actual NSG rules and the actual firewall mode.
Hub-and-spoke on the diagram means a central hub virtual network with shared services, spokes peered to it, traffic inspected at the boundary. The topology is usually real. The enforcement inside it often isn’t. Two findings recur, and neither one is visible on any architecture diagram ever drawn.
Start with the NSG rules. The diagram implies segmentation between spokes and tiers. Then I open the network security groups meant to enforce it and find rules permitting traffic from Any source, or broad CIDR ranges, across broad port ranges. Segmentation exists as a drawing and as virtual network peering. The NSG, the thing that actually filters packets, is wide open.
Spokes drawn as isolated, configured as connected. Same class of finding the WAF security pillar surfaces, seen at landing-zone scale.
Then the firewall. The hub has an Azure Firewall, exactly where the diagram puts it. Its threat intelligence and IDPS are set to Alert instead of Deny. In Alert mode the firewall logs malicious traffic and waves it through. Deployed, visible, inspecting nothing it can stop. Alert mode is a legitimate first phase while you tune, and I’ll defend it for that. Left permanent, it’s a firewall in name only. The one I keep meeting has been in Alert since the day it deployed, because nobody ever scheduled the move to Deny.
Same theme as the rest of the review. The diagram is a memory of what the network was meant to be. The NSG rules and the firewall mode are what it is, and the gap is exactly what a documentation-only review misses.
The identity baseline
Identity is the real perimeter, so I spend as much time here as I do on the network.
The baseline is enforced configuration, not assumed practice. Conditional Access enforcing MFA across all users, with no exclusion group that quietly filled up with actual humans. Legacy authentication blocked. Device and risk conditions applied. Privileged Identity Management switched on, so elevated roles (Global Administrator, subscription Owner) are held just-in-time instead of standing. Administrative accounts kept separate from daily-use ones. Break-glass accounts that exist, are excluded from Conditional Access on purpose, and get alerting the moment they’re used.
Identity is almost never unconfigured. That’s not the finding.
The finding is that the baseline has holes the diagram can’t express, because the diagram shows “Entra ID” as one confident box. PIM never activated, so privileged access is standing. A Conditional Access exclusion that began as a service account and slowly accumulated human members. Those are the gaps that decide whether the identity layer is a control or a label.
Doing all of this by hand, tenant after tenant, is what pushed me into building Platform Architecture Authority. I got tired of rebuilding the same picture from the same portal blades every time, and tired of handing back a finding I’d have to re-derive from scratch three months later when someone asked whether it was still true. So it reads the control plane through Azure Resource Graph and tells me what’s actually running. Read-only. It reports the gap, it doesn’t close it, and the judgment calls stay mine.
Evidence by construction
This is the whole argument for getting the landing zone right. Build it correctly and compliance stops being a document you write and becomes a state you can query.
The mapping is direct. NIS2 Article 21 wants risk-management measures: access control, network security, business continuity. A landing zone that enforces them through management-group policy produces the evidence as policy compliance state in Azure Resource Graph. DORA’s ICT risk-management requirements want demonstrable control over the digital operational estate. The hierarchy, the inherited policy, the Entra ID baseline, the firewall in Deny mode are that demonstration. When the auditor asks “show me this control is enforced,” the answer is a query against the control plane.
That’s the line. One landing zone hands the auditor a diagram. The other hands them a control plane that proves the diagram, resource by resource. It’s the same foundation the governance checklist builds on. Governance is the landing zone’s control plane, enforced.
If you take one thing from this and go look at your own tenant tonight, make it the scope of your policy assignments. It’s a five-minute check and it decides everything downstream.
What the review comes down to
- Azure Policy at the management group is the property that defines a defensible landing zone. New subscriptions inherit the controls, with no manual step left to forget.
- Policy assigned per subscription is the most common structural finding. Every new subscription starts uncontrolled until someone remembers to fix it.
- The networking diagram says hub-and-spoke with segmentation. The running config often shows allow-all NSG rules and Azure Firewall in Alert mode, inspecting nothing.
- A Microsoft Entra ID baseline (Conditional Access, PIM, named administrative tiers) is what makes the identity layer real rather than assumed.
- A correctly built landing zone produces NIS2 and DORA evidence by construction, because the controls run in the control plane and show up in Azure Resource Graph.
A landing zone is the management group hierarchy, the inherited policy, the real NSG rules, and the firewall mode as they run right now. The document is a memory of it. A compliance review is the discipline of reading the fact instead of the memory.
FAQ
Why does policy scope matter more than which policies you assign? Scope decides inheritance. The right policies assigned per subscription protect only the subscriptions that already exist, and depend on someone repeating the assignment for every new one. The same policies at the management group are inherited automatically by every current and future subscription. Correct policies at the wrong scope still leave new subscriptions ungoverned.
What’s the risk of leaving Azure Firewall in Alert mode? In Alert mode the firewall logs threats its threat intelligence and IDPS detect, then lets the traffic through. The control looks deployed and stops nothing. Alert is appropriate during initial tuning, to avoid blocking legitimate traffic. Left permanent, it’s a logged record of attacks you chose not to prevent.
Which single finding most often undermines landing zone compliance? Azure Policy assigned at subscription scope instead of the management group. Controls aren’t inherited, so every new subscription starts ungoverned until someone configures it by hand, and that manual step is the one most reliably forgotten. It’s the difference between compliance by construction and compliance by remembering.
