The cost of an exception
A landing zone is designed once and then extended in production, and that's where its real story begins. The first project with a hard deadline gets its subscription outside the hierarchy because the policy review would have taken longer than the sprint. The vendor who couldn't make progress with Contributor rights on a Friday afternoon gets Owner on the management group and keeps it, because nobody thinks about it again after go-live. And when the firewall in the hub throttles a spoke's throughput, the spoke gets its peering directly, bypassing the hub. Every one of those decisions made sense at the time, and every one is still in effect today.
The consequences are concrete. A subscription outside the hierarchy inherits no policy, so the policy doesn't protect it either. An Owner at management group level propagates silently to every subscription beneath it, including ones that didn't exist yet. A peering with no route to the firewall is a network path your SOC can't see. The Azure Landing Zone Review overlays the original design with the current state, across the eight design areas of the Cloud Adoption Framework, and ranks the gaps by their consequences, not by how old they are.
The eight Cloud Adoption Framework design areas
Microsoft organized landing zone decisions into eight design areas because most problems otherwise hide in the gaps between teams: the network team builds the hub, the identity team assigns the roles, and whoever approved the policy exception doesn't appear in either team's records. We work through all eight, asking the same question for each: what was intended, what was built, and what follows from the difference.
Azure Billing and Entra Tenant
Enrollment, billing hierarchy, and the tenant everything runs on. A second tenant from an acquisition is rarely a problem until someone has to consolidate licenses, identities, and invoices.
Identity and Access Management
Platform-level roles, service principals, and PIM. An Owner on the root management group propagates silently to every subscription created afterward.
Resource Organization
Management group hierarchy, subscription design, naming, and tags. Workloads in the wrong management group inherit the wrong policies, and nobody notices until an audit asks.
Network Topology and Connectivity
Hub-and-spoke or Virtual WAN, hybrid connectivity, DNS, firewall, private endpoints. A peering that bypasses the hub is technically clean and invisible to the SOC.
Security
Defender for Cloud, encryption, key vaults, and everything that lives at the platform layer rather than in the workload. A Defender plan active on a subset of subscriptions protects exactly that subset.
Management
Monitoring, logging, backup, and recovery. Missing diagnostic settings don't surface during normal operations — they surface during an incident, when the logs that were never written turn out to be needed.
Governance
Azure Policy, initiatives, exemptions, and cost control. An exemption has an expiry date if someone set one. Most don't.
Platform Automation and DevOps
Infrastructure as Code, pipelines, Azure Verified Modules. A platform changed through the portal has two sources of truth: the repository and Azure. Azure wins.
How it works
- Interview the teamInterview the teamWe start with the people who operate the platform, not the tooling: architecture, tools, operational processes, strategy. Most findings a scan produces later have a backstory, and understanding it is what makes the assessment accurate. A deliberate decision is a different thing from a forgotten workaround.
- Read the environmentRead the environmentThen we pull data from the environment using tooling: management groups, policies and exemptions, role assignments, network paths, diagnostic settings, costs. Automated and measured against the current Cloud Adoption Framework, not the version from three years ago.
- Prioritize findingsPrioritize findingsThe tool identifies the deviation, the interview explains it, and only together do they produce a priority. At the top: findings that propagate permissions or suppress logs. At the bottom: naming convention violations. A finding with no consequence is a note, not an action item.
- Walk through the reportWalk through the reportYou receive the report with a maturity rating per design area, findings, and recommendations, and we go through it together. Not so you know a hundred findings, but so you know on Monday which one to start with.
A report with a priority order
You receive a report that maps your landing zone across the eight design areas: maturity per area, prioritized findings, and recommendations a platform team can act on without coming back to us. It also includes the distinction no scanner makes: which deviation from the framework was a deliberate decision and which was an oversight. The report is intended for platform teams and IT leadership who have been running a landing zone for a few years and want to know what has shifted since then, in the environment and in the framework. If you're heading into a migration, it's worth checking the foundation before you move. If you've taken over a platform from a vendor, you need a second set of eyes that didn't build what it's evaluating. Remediation is not included. It runs as a separate project, with us, with a partner, or with your own team.
What comes next
Questions we get upfront
The questions that come up in early conversations, answered the way we answer them there.
Do we need a landing zone from glueckkanja for this?
No. We assess any landing zone, whether it was built from the Enterprise Scale template, delivered by another vendor, or grown organically through the portal. The benchmark is the Cloud Adoption Framework, not our Azure Foundation. We'll recommend it if the report points that way, but it's never a condition.
How is the review different from the Modul Azure der Preventive Services?
It's a different question. The Modul Azure asks how an attacker moves from a subscription to the control plane, and it ends in a hardening roadmap. The Landing Zone Review asks whether the platform holds up as a whole: organization, networking, governance, operations, automation, costs. Security is one of eight design areas. If you want both, start with the review, because it provides the map the module draws its paths on.
What access do you need?
Read-only. A Reader role on the top-level management group, plus read access to Cost Management, is enough for the analysis. We make no changes, and access is removed once the review is complete. The fact that the review can be done with Reader rights is itself a finding: a landing zone where that's not possible has just identified its first issue.
Do you look at costs too?
Yes, because in a landing zone, cost issues tend to have the same root causes as governance findings. Without tags, invoices can't be attributed to a team. Without budget alerts, a forgotten VM only surfaces at month end. And a reservation nobody maintains is paying for capacity nobody uses. Anything that stands out goes into the report, with numbers.
How long does the review take?
The interview and analysis take a few days. On your side, it requires one interview session, granting read access, and a session to walk through the report together. The more time-consuming part is what you do with the list afterward, and that part belongs to you.
Is remediation included?
No, and that's deliberate. A review that prioritizes its own follow-on work isn't really a review. You get the priority order and the recommendations; remediation runs as a separate project, with us, with a partner, or with your own team. If you want to rebuild the landing zone from scratch afterward, the Azure Foundation is the path there.
