Azure landing zone for compliance
Microsoft's reference landing zone is built for large enterprises. A 30 person SaaS company needs the same shape with fewer parts: management groups, a policy baseline, Entra ID with PIM, and central logging.
A compliance-ready Azure landing zone for a small company is a management group hierarchy with Platform, Production and Non-production groups; a platform subscription holding a central Log Analytics workspace and security tooling; Azure Policy assigned at the top group with a baseline initiative and a few deny rules; Entra ID with Conditional Access and PIM; and production workloads in their own subscriptions. That shape passes. The enterprise reference architecture adds hub networking and many more subscriptions you may not need yet.
A management group hierarchy that fits
| Management group | Subscriptions | Policy |
|---|---|---|
| Top level (your company) | None directly | Baseline initiative, allowed locations, required diagnostics |
| Platform | Management and logging, connectivity if needed | Restricted access, security team only |
| Production | One per product or environment | Deny public data endpoints, stricter RBAC |
| Non-production | Development, staging | Baseline only, no customer data |
| Sandbox | Optional | Budgets, no peering to production |
Microsoft's landing zone accelerators
Microsoft publishes Azure landing zone reference implementations through the Cloud Adoption Framework, deployable with Bicep or Terraform. They are well built and heavier than most small companies need, particularly the hub and spoke networking and the large policy set. A reasonable approach is to take the management group layout and policy assignments from the reference and skip connectivity components until you have a reason to add them.
Identity
- Conditional Access requiring MFA for all users, blocking legacy authentication.
- PIM for Owner, Contributor and User Access Administrator on production.
- Two break-glass accounts excluded from Conditional Access, protected with FIDO2 keys and monitored.
- Managed identities for workloads; workload identity federation for pipelines.
Logging
Use Azure Policy with DeployIfNotExists to create diagnostic settings on every subscription and on key resource types, sending logs to the central workspace. Set workspace retention to cover your audit period. Add Entra ID diagnostic settings at the tenant level. This makes logging a property of the landing zone rather than something each team remembers.
Do we need hub and spoke networking for SOC 2?
No. SOC 2 needs boundary protection and separation of production, which subscriptions and network security groups provide. Hub and spoke becomes worthwhile with many virtual networks, shared firewalls or on-premises connectivity.
How many subscriptions should a small company have?
Three to five: a platform subscription for logging and security, one or two for production, and one or two for non-production. Add more as products or teams need isolation.
Can we retrofit a landing zone onto existing subscriptions?
Yes. Create the management groups, move existing subscriptions under them, and assign policy in audit mode first to see what would break before switching rules to deny.
Want an Azure landing zone sized for you?
Firms in the network build and document right-sized Azure foundations.
Get matched