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
An Azure landing zone is compliant when its controls are enforced at the management group level so every subscription inherits them by construction — and it is merely documented as compliant when those controls exist on a diagram. The review that matters checks the second against the first. A diagram is a memory of an intention. The control plane is the fact.
This is the distinction that decides whether a regulatory audit goes well. The diagram shows hub-and-spoke networking, policy enforcement, segmented identity, and a clean subscription hierarchy. The running configuration shows what was actually deployed and what drifted afterward. The gap between them is where the findings live, and a compliance review is the act of measuring that gap rather than trusting the diagram that hides it.
Key takeaways
- Azure Policy assigned at the management group level is the defining property of a defensible landing zone: new subscriptions inherit the controls automatically, with no manual step to forget.
- Policy assigned per subscription instead of at the management group is the most common structural finding — it means every new subscription starts uncontrolled until someone remembers to fix it.
- The networking diagram says hub-and-spoke with segmentation. The running configuration frequently shows allow-all NSG rules and Azure Firewall in Alert mode, inspecting nothing.
- A Microsoft Entra ID baseline — Conditional Access, Privileged Identity Management, named administrative tiers — is what makes the identity layer of the landing zone real rather than assumed.
- A correctly built landing zone produces NIS2 and DORA evidence by construction, because the controls are enforced in the control plane and visible in Azure Resource Graph.
What makes a management group hierarchy defensible?
A management group hierarchy is defensible when it is structured so that controls applied near the top flow down to every subscription beneath, which means a new subscription is governed the moment it is created rather than the moment someone configures it. The hierarchy is the skeleton the entire landing zone hangs on, and its shape determines whether compliance is inherited or improvised.
The defensible structure follows the Microsoft Cloud Adoption Framework: a top-level management group under the tenant root, then a layer separating platform subscriptions (identity, management, connectivity) from landing zone subscriptions (the workloads), with a dedicated group for sandbox and decommissioned subscriptions. The structure exists so policy and access can be applied at the right altitude — broadly where the control is universal, narrowly where it is workload-specific.
The common finding is a flat hierarchy: subscriptions hanging directly off the tenant root, or a single management group holding everything. When the hierarchy is flat, there is no altitude at which to apply inherited controls, so controls get applied per subscription — and that is the next finding.
Why must Azure Policy be assigned at the management group, not per subscription?
Azure Policy must be assigned at the management group level because that is what makes a control inherited rather than remembered — every subscription beneath the assignment receives it automatically, including subscriptions that do not exist yet. Assign the same policy per subscription and you have built a control that depends on a human performing a step for every new subscription, forever. That step gets missed.
This is the single most consequential finding in a landing zone compliance review. The policies might be correct. The initiative — 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 — might be the right one. But if it is assigned at the subscription scope, the control protects only the subscriptions that existed when someone assigned it. Spin up a new subscription and it starts life ungoverned.
The mechanism matters as much as the assignment. A policy in Audit effect reports violations; it does not prevent them. A policy in Deny effect prevents the non-compliant resource from being created at all. The defensible landing zone uses Deny for the controls that must 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 in Audit, reporting 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 does the networking diagram diverge from the running configuration?
The networking diagram diverges from the running configuration at exactly the points the diagram cannot show: the actual NSG rules and the actual firewall mode. The diagram shows hub-and-spoke — 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 frequently is not.
Two findings recur, and both are invisible on any architecture diagram.
Allow-all NSG rules. The diagram implies segmentation between spokes and tiers. The network security groups that should enforce it contain rules permitting traffic from Any source, or broad CIDR ranges, on broad port ranges. The segmentation exists as a drawing and as virtual network peering, but the NSG — the thing that actually filters packets — is wide open. The spokes are drawn as isolated and configured as connected. This is the same class of finding the WAF security pillar surfaces, viewed at the landing zone scale.
Azure Firewall in Alert mode. The hub has an Azure Firewall, exactly as the diagram shows. Its threat intelligence and IDPS are set to Alert rather than Deny. In Alert mode the firewall logs malicious traffic and lets it through — present, deployed, visible on the diagram, and inspecting nothing it can stop. Alert mode is a legitimate first phase during tuning. Left permanent, it is a firewall in name. The finding is the firewall that has been in Alert mode since deployment because nobody scheduled the move to Deny.
The lesson is the theme of the whole review. The diagram is a memory of what the network was meant to be. The NSG rules and the firewall mode are the fact of what it is — and the gap is exactly what a documentation-only review misses.
What does a Microsoft Entra ID baseline require?
A Microsoft Entra ID baseline requires that identity controls are enforced as configuration rather than assumed as practice — Conditional Access policies, Privileged Identity Management for elevated roles, and a clear separation between everyday and administrative identities. Identity is the real perimeter of the landing zone, and its baseline is where the compliance review spends as much attention as the network.
The baseline the review checks for: Conditional Access enforcing multi-factor authentication across all users with no exclusion groups that quietly contain humans, blocking legacy authentication, and applying device and risk conditions. Privileged Identity Management activated so elevated roles — Global Administrator, subscription Owner — are held just-in-time rather than standing. Administrative accounts separated from daily-use accounts. Break-glass accounts that exist, are excluded from Conditional Access deliberately, and are monitored with alerting on their use.
The common finding is rarely that identity is unconfigured. It is that the baseline has gaps that the diagram, which shows “Entra ID” as a single confident box, cannot express. PIM not activated, so privileged access is standing. A Conditional Access exclusion that started as a service account and accumulated human members. These are the findings that decide whether the identity layer is a control or a label.
How does a compliant landing zone produce NIS2 and DORA evidence by construction?
A compliant landing zone produces NIS2 and DORA evidence by construction because the controls those regulations require are enforced in the control plane, which means the evidence is the running configuration itself — queryable, dated, and not assembled after the fact. This is the entire argument for getting the landing zone right: compliance stops being a document you write and becomes a state you can query.
The mapping is direct. NIS2 Article 21 requires risk-management measures — access control, network security, business continuity. A landing zone enforcing them through management-group policy produces the evidence as policy compliance state in Azure Resource Graph. DORA’s ICT risk-management requirements demand demonstrable controls over the digital operational estate — the management group hierarchy, the inherited policy, the Entra ID baseline, the firewall in Deny mode are that demonstration. The auditor’s question — “show me that this control is enforced” — is answered by a query against the control plane.
That is the difference between a landing zone documented as compliant and one that is compliant. The first hands the auditor a diagram. The second hands them a control plane that proves the diagram, resource by resource. This is also the 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 — and maps each finding to the NIS2 and DORA article it touches. It generates the remediation as infrastructure-as-code and policy definitions you review and apply. It is read-only; it reports the gap between the diagram and the fact without changing either. A cloud architect still brings the judgment about which controls belong at which scope and when a firewall is ready to move from Alert to Deny; the platform makes the running configuration legible so that judgment is exercised against reality.
FAQ
Why does policy scope matter more than which policies are assigned? Because scope determines inheritance. The right policies assigned per subscription protect only existing subscriptions and depend on someone repeating the assignment for every new one. The same policies assigned at the management group are inherited automatically by every current and future subscription. Correct policies at the wrong scope leave new subscriptions ungoverned.
What is the risk of leaving Azure Firewall in Alert mode? In Alert mode, Azure Firewall logs threats detected by its threat intelligence and IDPS but allows the traffic through. The control appears deployed and inspects nothing it can stop. Alert mode is appropriate during initial tuning to avoid blocking legitimate traffic; left permanent, it is a logged record of attacks you chose not to prevent.
What single finding most often undermines landing zone compliance? Azure Policy assigned at the subscription scope instead of the management group. It means controls are not inherited, so every new subscription starts ungoverned until someone manually configures it — and that manual step is the one most reliably forgotten. It is the difference between compliance by construction and compliance by remembering.
A landing zone is not the diagram in the architecture document. It is the management group hierarchy, the inherited policy, the actual NSG rules, and the firewall mode as they run right now — and a compliance review is the discipline of reading the fact instead of the memory.
