Azure Landing Zone Checklist

What to check: Check hub-spoke structure, private DNS, controlled outbound, firewall policy, DDoS, and central inspection.

Why it matters: Networking controls reduce exposure and simplify operations.

Common failure pattern: Workloads use direct public egress without a defined pattern.

Example finding: Workloads use direct public egress without a defined pattern.

Suggested remediation direction: Adopt approved outbound paths and document exceptions.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Check initiatives, deny controls, remediation tasks, exemptions, tagging, and budget coverage.

Why it matters: Governance must be inherited and remediated to be effective.

Common failure pattern: Policies audit but do not enforce required controls.

Example finding: Policies audit but do not enforce required controls.

Suggested remediation direction: Use policy effects deliberately and remediate existing resources.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Check Log Analytics, diagnostic settings, action groups, activity logs, and alert rules.

Why it matters: Landing zones must support detection and response from day one.

Common failure pattern: Diagnostics are enabled only on a few services.

Example finding: Diagnostics are enabled only on a few services.

Suggested remediation direction: Deploy diagnostic baselines and central alert routing.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Check Defender plans, Key Vault access, public storage exposure, and security contacts.

Why it matters: Security baselines prevent avoidable platform-level risk.

Common failure pattern: Key Vaults allow broad network access.

Example finding: Key Vaults allow broad network access.

Suggested remediation direction: Restrict access and apply private connectivity where needed.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Look for flat hierarchy, shared services in workload subscriptions, policy assigned too low, unmanaged exceptions, and missing owner tags.

Why it matters: Anti-patterns signal that the platform will be difficult to scale.

Common failure pattern: Every team creates its own platform pattern.

Example finding: Every team creates its own platform pattern.

Suggested remediation direction: Standardise the landing zone model and govern exceptions.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.