A cloud landing zone is a pre-configured cloud environment used to deploy resources with security, networking, and governance controls already in place. It gives teams a standard operating base for cloud use, but in recovery scenarios it can become stale, expensive to maintain, and vulnerable to configuration drift.
What a cloud landing zone actually does
A cloud landing zone is the starting environment for cloud adoption, so its job is bigger than simply provisioning accounts or subscriptions. It establishes the guardrails that make later workloads safer and more repeatable, including network segmentation, logging, identity boundaries, policy enforcement, and baseline governance.
The value of the pattern is consistency. Instead of each team building its own cloud foundation from scratch, the landing zone gives them a controlled operating base that reduces early design mistakes and makes new deployments easier to govern at scale. That makes it a foundation pattern, not a one-time configuration task.
Why landing zones matter in cloud governance
Landing zones sit at the point where architecture decisions become operational reality. Choices made here determine whether cloud accounts, networks, and permissions are centrally governed or drift toward one-off exceptions. In that sense, the landing zone is where cloud policy becomes enforceable infrastructure.
A well-built landing zone usually reflects the organization’s standard requirements for segmentation, change control, auditability, and workload separation. The CSA Cloud Controls Matrix is a useful external reference because it maps cloud governance across areas such as IAM, infrastructure, audit, and supply chain. For broader control baselines, NIST Cybersecurity Framework 2.0 helps teams align landing zone design with governance, protection, detection, response, and recovery outcomes.
What belongs in the baseline
The practical content of a landing zone is usually a mix of network design, identity boundaries, logging, policy, and service guardrails. It may include centrally managed accounts or subscriptions, standardized routing, centralized monitoring, and constraints on what teams can deploy by default. Those controls matter because a landing zone is meant to shape behavior before the first workload lands.
Landing zone design also benefits from cloud-specific control mapping. ISO/IEC 27001:2022 Information Security Management is relevant because it ties cloud security to access control, privileged access, authentication, and cloud-specific control discipline. For implementation-heavy environments, the CIS Benchmarks provide a hardening-oriented lens that complements the landing zone idea when teams need concrete configuration baselines.
The baseline should also support secret handling, because cloud foundations often fail when credentials, tokens, or keys are embedded in automation and configuration. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and that statistic is directly relevant here because landing zones often define the secure default paths for those materials.
How landing zones fail over time
Landing zones are designed to be stable, but they can become stale if the platform evolves faster than the controls. In recovery scenarios, teams sometimes rebuild from old templates, keep obsolete network paths alive, or inherit settings that no longer match the current security model. The result is configuration drift, where the environment still exists but no longer reflects the intended baseline.
That drift is often paired with cost growth and hidden risk. Old guardrails may fail to cover newer services, logging may be incomplete, and permission patterns may expand without a corresponding review cycle. When that happens, the landing zone becomes a foundation with gaps rather than a control plane with consistency.
Risk and Threat Considerations
A cloud landing zone concentrates trust, so misconfiguration at this layer can expose many workloads at once. The main risk is not the concept itself, but the scale of the blast radius when shared defaults, permissions, or network paths are wrong.
Failure mechanism: A weak or outdated landing zone can allow configuration drift, overbroad access, secret exposure, or incomplete logging to spread across every workload built on top of it.
Impact: Attackers or internal errors can then reach more systems, compromise more identities or credentials, and make detection and recovery significantly harder.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV — Govern | Cloud landing zones operationalize cloud governance and guardrails across environments. |
| PR.AC — Access Control | Landing zones enforce access boundaries and permission defaults for cloud workloads. | |
| PR.PT — Protective Technology | Landing zones rely on security tooling, segmentation, and logging to harden the cloud base. | |
| Recommendation — Define landing zone ownership, policy exceptions, and review cycles under Govern. Apply access controls to constrain default permissions and administrative paths in the landing zone. Use protective technology to enforce segmentation, logging, and baseline cloud guardrails. | ||
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Landing zones are standardized secure baselines for cloud account and service configuration. |
| 6 — Access Control Management | Landing zones set who can access and administer shared cloud foundations. | |
| 8 — Audit Log Management | Landing zones depend on central logging to detect drift and abuse across cloud foundations. | |
| Recommendation — Standardize and continuously verify secure cloud baseline configurations. Restrict administrative and default access paths in the landing zone. Enable centralized audit logging for landing zone activity and baseline changes. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Cloud landing zones depend on identity proofing, federation, and assurance at the cloud foundation layer. |
| Recommendation — Use strong identity assurance and federation controls for access into the landing zone. | ||
| NIST Zero Trust (SP 800-207) | AC-4 — Information Flow Enforcement | Landing zones commonly enforce cloud segmentation and traffic boundaries aligned with Zero Trust. |
| Recommendation — Enforce cloud traffic segmentation and information-flow policy at the landing zone boundary. | ||
Practitioner Guidance
What to watch for: Treat landing zones as living platform controls, not static setup artifacts. If the operating model changes but the base templates, guardrails, or account structure do not, the landing zone is no longer representing the real cloud environment.
Governance implication: Ownership needs to be explicit, because landing zone drift is usually a platform governance failure before it becomes an individual workload failure. The team responsible for the landing zone should be able to explain who approves changes, who reviews exceptions, and how the baseline is refreshed after recovery or replatforming events.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
