A landing zone is the set of decisions every future workload inherits: how subscriptions are organised, what policy applies, how networks connect and who can change any of it. Getting those decisions reviewed before the first production system arrives costs a few days. Correcting them afterwards means touching everything built on top, which is why this is one of the few security exercises with an obvious best moment.
Structure and separation
Start with the management group hierarchy, because it determines where policy and access apply. Production and non-production should sit in separate branches so a policy or role assignment intended for development cannot reach live systems. Check how new subscriptions are created and by whom, since a landing zone with a controlled vending process behaves very differently from one where any team lead can create a subscription and inherit nothing. Confirm that the identity used to deploy the platform is not the same one used to run workloads within it.
The policy baseline
Review which policies are assigned, at what scope, and in which mode. Denial of public network exposure, enforcement of encryption, restriction of permitted regions and requirements for diagnostic logging are the usual foundation, and each is worth confirming in enforcement rather than audit. The NCSC’s cloud security guidance is a reasonable checklist to review the baseline against, particularly around identity, separation and audit. Note any exemptions created during the build, because those are the exceptions that become permanent once workloads depend on them.
“The two findings I see most in landing zone reviews are policies left in audit mode and a network design where every spoke can reach every other spoke through the hub. Both are decisions somebody made in week two to keep the build moving, and both are much harder to change once forty workloads are running.”
William Fieldhouse, Director, Aardwolf Security Ltd
Network design and the routes nobody meant to allow
Hub and spoke designs are common and the rules between spokes are what matter. Confirm that traffic between workloads is inspected or denied by default rather than permitted because peering was simpler that way. Check the private DNS design, since it determines whether private endpoints actually work and whether a workload can resolve services it should not reach. Look at the connection back to your on-premises network as well, because a flat route between the corporate network and a cloud environment removes most of the separation the design was meant to provide.
Identity, break-glass and logging
Confirm that privileged roles are eligible rather than permanent, that two break-glass accounts exist with hardware authentication and monitoring, and that Conditional Access has a documented baseline covering administrators. Check that diagnostic logs from every subscription land in a central workspace held in a subscription with restricted access. Then have the design tested rather than reviewed on paper: an Azure cloud penetration testagainst the platform before workloads arrive finds the gaps while they are still cheap, and an experienced cloud testing provider will look at the deployment pipeline as well, since whoever controls that controls the platform.
Frequently asked questions about landing zone reviews
These questions come up when a cloud programme reaches its first production workload.
Is a review worthwhile if you used a published reference architecture?
Yes. Reference architectures are a good starting point and every implementation makes local changes, usually to accommodate an existing network or an identity constraint. The changes are where the findings are.
How often should the platform be reassessed?
Annually, and after any significant change to the hierarchy, the network or the identity model. Platform drift is slower than workload drift and it matters more when it happens.
