Azure landing zones for public-sector tenants

Public-sector cloud adoption rarely stalls on technology. It stalls on evidence: proving where data sits, who can reach it, and what prevents a well-meaning administrator from changing that on a Thursday afternoon.

01Start with the boundary, not the workload

Design the management group hierarchy and subscription boundaries before the first workload moves. Retrofitting a boundary means moving resources, re-pointing identity and re-testing every integration.

A workable default

• Platform subscriptions: identity, connectivity, management
• Landing zone subscriptions, one per data classification
• A sandbox with no route to production data, and a spend cap

{
  "policy": "deny-public-blob",
  "scope": "landing-zones/regulated",
  "effect": "Deny",
  "note": "exceptions require change record + owner sign-off"
}

02Guardrails beat review boards

A policy that denies public storage endpoints is enforced every second of every day. An architecture review board meets on Tuesdays. Encode as much of the standard as policy as you can, and reserve the board for the genuinely novel.

If a control exists only in a document, assume it is not in effect.

03Make the audit a report

Compliance state, policy exemptions and cost by classification should be a dashboard the sponsor can open, not a quarterly excavation. Everything on it is data the platform already emits.