Most Azure landing zone reviews drift into architecture theatre. People inspect a diagram, admire the management group hierarchy, confirm there is a hub subscription somewhere, and walk away assuming the platform is sound. That is not how I would review it. In How I Would Review an Azure Landing Zone Using the Microsoft Cloud Security Benchmark, I would use Microsoft Cloud Security Benchmark as the control spine and test whether the landing zone actually enforces the security and operating model it claims to enforce.

An Azure landing zone is supposed to be the repeatable foundation for identity, connectivity, management, governance, and workload deployment at scale. Microsoft Cloud Security Benchmark gives me a better way to assess that foundation because it turns vague questions like “is this secure?” into concrete control areas such as identity management, privileged access, network security, data protection, logging, posture management, and incident response.

The reason I like this approach is simple. A landing zone is only useful if it produces consistent security outcomes across subscriptions. MCSB gives me a structured way to test whether those outcomes are real, whether they are enforced through policy and platform controls, and where the operating model will start to crack under pressure.

I Start With the Platform Story, Not the Workload Story

The first thing I want to know is whether the landing zone is actually a landing zone or just a loose collection of subscriptions with some shared networking.

I look at the basics first:

• Management group hierarchy and whether it reflects a deliberate operating model
• Separation between platform subscriptions and application landing zones
• Subscription vending process and whether new subscriptions inherit policy by default
• Identity, connectivity, and management services placed in the right scopes
• Infrastructure-as-code usage for the platform baseline rather than portal-only drift

Microsoft’s landing zone guidance is opinionated for a reason. If management groups are inconsistent, if subscriptions are being created outside the intended hierarchy, or if the platform team still builds everything manually, the rest of the review becomes less about architecture quality and more about exception handling.

When I see deviation here, I do not treat it as a documentation issue. I treat it as a control failure. Most major Azure posture problems I find later were made possible because the platform foundation never became the default path for delivery teams.

Then I Map the Review to MCSB Domains

This is where Microsoft Cloud Security Benchmark becomes useful. It keeps the review anchored in control intent instead of vendor marketing language.

I do not try to score every single benchmark line item in one sitting. I use the domains to drive the review of the landing zone design areas that matter most.

The core domains I care about first are:

• Identity Management and Privileged Access
• Network Security
• Data Protection
• Logging and Threat Detection
• Posture and Vulnerability Management
• Asset Management
• Incident Response
• DevOps Security when the landing zone is managed through pipelines, which it should be

If the client is already leaning into Azure AI services, I also look at the newer AI security guidance because Microsoft has started treating AI as a first-class control domain. That matters more than many teams realise because AI services are usually deployed into the same landing zone patterns as everything else.

Identity Tells Me How Serious the Landing Zone Really Is

Landing zones often get reviewed as network and policy constructs, but identity is usually where the truth lives.

I want to know whether privileged access is tightly controlled at tenant and subscription level, or whether the platform has quietly accumulated permanent standing access over time. I check role assignment patterns, the use of Privileged Identity Management, break-glass accounts, Conditional Access coverage, managed identity usage, and whether workload teams are being forced into bad patterns because platform automation is weak.

MCSB is useful here because it makes it obvious that identity is not a side topic. It is a primary control domain. A landing zone with elegant subscription structure and weak privileged access is not mature. It is cosmetically tidy and operationally risky.

The specific question I keep asking is this: if a privileged identity is compromised today, how far can an attacker move before a guardrail stops them?

Policy Driven Governance Is the Real Test

Microsoft’s landing zone design principles put policy-driven governance at the centre. I agree with that completely.

If I am reviewing a landing zone against MCSB, Azure Policy is where theory meets reality. I want to see which controls are enforced, which are merely audited, which have been exempted, and how exemptions are governed. I care less about the number of policies than about whether the right controls are attached at the right level and inherited consistently.

I usually check for guardrails such as:

• Deny or tightly control public IP exposure where it is not explicitly required
• Restrict creation of risky SKUs or regions unless approved
• Enforce diagnostic settings, tagging, encryption, and Defender plans
• Require private access patterns for data services where appropriate
• Prevent unmanaged drift in production subscriptions

This is also where Defender for Cloud becomes valuable. MCSB gives the control structure. Defender for Cloud gives operational visibility into how much of that structure is actually present and where the benchmark is being missed in live subscriptions.

If everything important is in audit mode because teams are afraid to break deployments, I treat that as a sign that the landing zone has not reached production discipline yet.

Networking Should Reduce Blast Radius, Not Just Look Enterprise

A lot of Azure environments still confuse complexity with security. A complicated hub-and-spoke diagram is not a security outcome.

From an MCSB perspective, I am checking whether the network design materially reduces exposure. That means reviewing ingress paths, private endpoints, egress control, DNS design, segmentation, firewall placement, DDoS strategy where relevant, and whether shared connectivity decisions are creating hidden coupling between workloads.

I also look for the usual friction points:

• Application teams bypassing private connectivity because the approved pattern is too slow
• NSGs and route tables that exist but are not governed consistently
• Shared services placed in connectivity subscriptions without clear ownership boundaries
• Hybrid connectivity that expands trust without equivalent monitoring or policy control

The benchmark helps here because it forces the discussion back to concrete risks. Can untrusted traffic reach services it should not reach. Can workloads exfiltrate data without inspection. Can platform teams explain the intended boundary model in one page.

If they cannot, the design is probably more accidental than deliberate.

Logging, Detection, and Recovery Usually Lag Behind the Diagram

Landing zone reviews often stop at provisioning and governance. I think that is a mistake.

If the landing zone does not consistently enable logging, centralise security telemetry, preserve retention, and support incident response, it is incomplete. MCSB is strong here because it treats logging, threat detection, incident response, and backup as core control areas rather than afterthoughts.

I review whether:

• Diagnostic settings are deployed by default through policy or automation
• Activity logs, platform logs, and security signals land somewhere useful
• Microsoft Defender for Cloud, Sentinel, or equivalent workflows are integrated into operations
• Backup and recovery expectations exist for both platform and workload services
• Teams can prove they would detect and contain misuse of privileged access or exposed services

This is one of the fastest ways to separate mature Azure platforms from aspirational ones. Mature platforms assume incidents will happen and design for evidence, containment, and recovery from day one.

I Always Look for the Exception Path

The strongest landing zones are not the ones with the prettiest reference architecture. They are the ones with the least dangerous exception process.

Every enterprise has edge cases. Regulated workloads, legacy dependencies, regional constraints, third-party tooling, mergers, acquisitions, shadow platforms. The question is not whether exceptions exist. The question is whether exceptions are explicit, temporary, risk-owned, and observable.

When I use MCSB to review a landing zone, I am really looking for three things:

• Which controls are enforced by default
• Which controls rely on manual behaviour
• Which controls are being bypassed in the name of delivery speed

That third category is where the future incident usually starts.

What Good Looks Like at the End of the Review

I do not want a review to end with a generic maturity score and a pile of screenshots. I want a landing zone owner to walk away knowing exactly what to fix structurally.

My output is usually simple:

• The control areas where the landing zone aligns well with MCSB
• The structural gaps that will keep recreating risk across subscriptions
• The high-risk exceptions that need either remediation or formal acceptance
• The controls that should move from audit to deny
• The platform automations that need to be built so teams stop working around the guardrails

That is the practical value of Microsoft Cloud Security Benchmark in this context. It is not just a compliance mapping exercise. It is a way to review whether the Azure platform can scale safely without relying on heroics from individual engineers.

Final Thought

If I were reviewing an Azure landing zone tomorrow, I would not start with a Visio diagram. I would start with Microsoft Cloud Security Benchmark, trace it through identity, policy, networking, logging, and operational exceptions, and ask whether the platform produces secure behaviour by default.

That is the bar that matters. Not whether the landing zone looks like the reference architecture, but whether it keeps producing the right security outcomes when the tenant grows, the org changes, and delivery teams start pushing hard against the edges.