Reviewing an Azure Landing Zone for Compliance: What a Defensible Foundation Looks Like
An Azure landing zone compliance review checks the control plane against the diagram: policy at the management group, the real NSG rules, firewall mode. For cloud architects.
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. Everything else is a drawing.
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.
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.
The diagram 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. A compliance review measures that gap instead of trusting the drawing 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 lays out 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 the structure is altitude: apply a control broadly where it’s universal, narrowly where it’s workload-specific.
The finding I see most 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.
The policies might be right. The initiative might be right too — Azure Policy groups related policies into initiatives, and the regulatory-compliance initiatives map to ISO 27001, NIS2-relevant baselines, and the Microsoft cloud security benchmark. 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. The common finding is the right policies sitting in Audit, generating a stream of violations nobody actions, at the wrong scope.
| 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. The network security groups meant to enforce it turn out to hold rules that permit 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. Left permanent, it’s a firewall in name only. The finding is the one that’s 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 the review spends as much time here as it does 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.
The finding is rarely that identity is unconfigured. It’s 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.
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 between a landing zone documented as compliant and one that is. The first hands the auditor a diagram. The second 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.
Platform Architecture Authority reads the landing zone through Azure Resource Graph and compares the running control plane against what a defensible configuration requires: policy scope and effect, the real NSG rules, the firewall mode, the Entra ID baseline. Each finding maps to the NIS2 or DORA article it touches. It generates the remediation as infrastructure-as-code and policy definitions for you to review and apply. It’s read-only. It reports the gap between the diagram and the fact without changing either. A cloud architect still owns the judgment — which controls belong at which scope, when a firewall is actually ready to move from Alert to Deny. The platform’s job is to make the running configuration legible, so that judgment gets exercised against reality instead of a drawing.
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.
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.
A landing zone isn’t the diagram in the architecture document. It’s the management group hierarchy, the inherited policy, the real NSG rules, and the firewall mode as they run right now. A compliance review is the discipline of reading the fact instead of the memory.
