# Landing Zone Design: [Organisation or platform name]

> Design document for a cloud landing zone: the governed foundation of
> resource hierarchy, identity, network, security guardrails, logging,
> policy as code, cost management and environments into which every
> workload is deployed. It includes a runbook for vending new accounts,
> subscriptions or projects, the IaC repository layout, a compliance
> mapping to CIS Benchmarks and the operating and change process.
> Provider-neutral, with an equivalents table for AWS, Microsoft Azure
> and Google Cloud. Design areas follow those published by the three
> providers (Azure landing zone design areas, AWS multi-account and
> Control Tower guidance, Google Cloud landing zone design). Replace
> every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one design per landing zone (usually one per provider and
  tenant). Workload designs reference it; they do not repeat it.
- Settle the hierarchy (section 3) and identity (section 4) first. They
  are the hardest to change once workloads are running.
- Every guardrail in section 7 must be expressed as code in section 9
  and tested in a non-production branch of the hierarchy before it
  reaches production.
- Section 13 is a runbook: keep it executable and keep it in step with
  the vending pipeline.
- Related documents: Cloud adoption strategy
  (`architecture/cloud-adoption-strategy`), Infrastructure design
  (`architecture/infrastructure-design`), Multi-tenancy design
  (`architecture/multi-tenancy-design`), Security architecture
  (`security/security-architecture`), Disaster recovery plan
  (`ops/disaster-recovery-plan`), FinOps cost review
  (`ops/finops-cost-review`).
-->

## Document control

<!-- Guidance: Identify the landing zone, its provider and tenant, and who owns it. A change to the hierarchy, identity model or network topology is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [LZD-001] |
| Landing zone name | [Name] |
| Provider and tenant or organisation | [Provider], [Organisation ID / tenant ID] |
| Implementation basis | [Provider reference implementation / Accelerator / Custom IaC] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@platform-lead] |
| Approvers/reviewers | [@security-architect], [@network-lead], [@finops-lead], [@enterprise-architect] |
| Primary regions | [Region 1], [Region 2] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Cloud adoption strategy], [Security architecture], [IaC repositories] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Platform owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Security | [@name] | [Decision] | YYYY-MM-DD |
| Network | [@name] | [Decision] | YYYY-MM-DD |
| Finance and FinOps | [@name] | [Decision] | YYYY-MM-DD |
| Architecture board | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for first workloads; hub network and logging live |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added regulated workloads branch with stricter guardrails |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope and design principles](#1-scope-and-design-principles)
2. [Provider equivalents](#2-provider-equivalents)
3. [Resource hierarchy](#3-resource-hierarchy)
4. [Identity and access](#4-identity-and-access)
5. [Network topology and IP plan](#5-network-topology-and-ip-plan)
6. [Connectivity](#6-connectivity)
7. [Security baseline and guardrails](#7-security-baseline-and-guardrails)
8. [Logging and monitoring](#8-logging-and-monitoring)
9. [Policy as code](#9-policy-as-code)
10. [Cost management and tagging](#10-cost-management-and-tagging)
11. [Environment strategy](#11-environment-strategy)
12. [IaC repositories](#12-iac-repositories)
13. [Account and subscription vending runbook](#13-account-and-subscription-vending-runbook)
14. [Compliance mapping](#14-compliance-mapping)
15. [Operations and change](#15-operations-and-change)
16. [Glossary and references](#16-glossary-and-references)

## 1. Scope and design principles

<!-- Guidance: State what the landing zone covers and the principles that resolve design disputes. Pitfall: principles so generic that they never rule anything out. -->

### 1.1 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Organisation hierarchy, identity federation, hub networking, central logging, guardrails, vending | Individual workload architectures |
| *Example:* Connectivity to two data centres and the corporate WAN | SaaS applications managed by business units |
| [Item] | [Item] |

### 1.2 Design principles

| ID | Principle | Consequence |
|---|---|---|
| LZP-001 *(Example)* | The unit of isolation is the account, subscription or project, not a resource group or folder | Each workload environment gets its own container; blast radius stays small |
| LZP-002 *(Example)* | Guardrails are inherited from the hierarchy, never configured per workload | Policies are attached to hierarchy nodes in section 3 |
| LZP-003 *(Example)* | Everything is deployed from code through a pipeline | No console changes in production; drift is detected and reverted |
| LZP-004 *(Example)* | Workload teams are autonomous inside guardrails | Teams own their resources; the platform owns shared services |
| LZP-005 *(Example)* | Design for the target scale from the start | Hierarchy, IP plan and quotas sized for [number] workloads |
| [LZP-NNN] | [Principle] | [Consequence] |

## 2. Provider equivalents

<!-- Guidance: Use this table so that readers on any provider can map the neutral terms used in this document. Verify product names against current provider documentation. -->

| Neutral term in this document | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Organisation root | AWS Organizations, management account | Microsoft Entra tenant, tenant root management group | Organization resource |
| Hierarchy node | Organizational unit (OU) | Management group | Folder |
| Isolation container | Account | Subscription | Project |
| Preventive guardrail | Service control policy, resource control policy, Control Tower preventive control | Azure Policy with deny effect | Organization Policy constraint |
| Detective guardrail | AWS Config rules, Control Tower detective control | Azure Policy with audit effect, Defender for Cloud recommendations | Security Command Center findings |
| Managed landing zone service | AWS Control Tower, Landing Zone Accelerator on AWS | Azure landing zone reference implementations | Google Cloud setup and Cloud Foundation Fabric or blueprints |
| Vending mechanism | Account Factory, account vending pipeline | Subscription vending modules | Project factory |
| Hub network | Transit gateway with inspection VPC | Hub virtual network or Virtual WAN hub | Shared VPC host project or Network Connectivity Center hub |
| Central log store | Log archive account | Log Analytics workspace in the management subscription | Centralised log bucket via aggregated sinks |
| Federation | IAM Identity Center with external identity provider | Microsoft Entra ID | Cloud Identity or Google Workspace with external identity provider |

## 3. Resource hierarchy

<!-- Guidance: Design the hierarchy around policy inheritance, not the org chart. Questions: which groups of containers need different guardrails? Where do sandboxes, suspended and transitional containers go? Pitfall: one node per department, which forces policy duplication. -->

The hierarchy groups isolation containers by the guardrails they need.
Policies attach at hierarchy nodes and are inherited by every container
below. Keep the depth to four levels or fewer below the root.

```mermaid
flowchart TB
  ROOT[Organisation root] --> SEC[Security]
  ROOT --> INFRA[Infrastructure]
  ROOT --> WL[Workloads]
  ROOT --> SBX[Sandbox]
  ROOT --> SUSP[Suspended]
  SEC --> LOG[Log archive]
  SEC --> AUD[Security tooling and audit]
  INFRA --> NET[Network hub]
  INFRA --> SHR[Shared services]
  WL --> PROD[Production]
  WL --> NONPROD[Non-production]
  WL --> REG[Regulated production]
  PROD --> P1[payments-prod]
  NONPROD --> N1[payments-dev]
  NONPROD --> N2[payments-test]
  REG --> R1[cardholder-prod]
```

| Node | Purpose | Guardrail set | Who may create containers |
|---|---|---|---|
| Security *(Example)* | Log archive and security tooling | GRS-CORE, GRS-SECURITY | Platform team only |
| Infrastructure *(Example)* | Network hub, shared services | GRS-CORE, GRS-NETWORK | Platform team only |
| Workloads / Production *(Example)* | Production workload containers | GRS-CORE, GRS-PROD | Vending pipeline |
| Workloads / Non-production *(Example)* | Development and test containers | GRS-CORE | Vending pipeline |
| Workloads / Regulated production *(Example)* | In-scope regulated workloads | GRS-CORE, GRS-PROD, GRS-REG | Vending pipeline with security approval |
| Sandbox *(Example)* | Experiments, no connectivity to corporate network | GRS-CORE, GRS-SANDBOX (budget cap, no peering) | Self-service |
| Suspended *(Example)* | Containers awaiting closure | Deny all except read and billing | Platform team only |
| [Node] | [Purpose] | [Guardrail set] | [Creator] |

Naming convention for containers: `[workload]-[environment]-[region code]`,
for example `payments-prod-euw`. Names are lower case, 30 characters or
fewer, and never reused after closure.

## 4. Identity and access

<!-- Guidance: Decide how people and machines authenticate and get permissions. Questions: which identity provider is authoritative? How are roles assigned? How do you get in when federation fails? Pitfall: long-lived access keys and local users created for convenience. -->

### 4.1 Human access

| Decision | Choice |
|---|---|
| Authoritative identity provider | *Example:* Corporate identity provider; no local cloud users except break-glass |
| Federation protocol | *Example:* SAML 2.0 or OpenID Connect, with automated user and group provisioning |
| Multi-factor authentication | *Example:* Phishing-resistant MFA required for all privileged roles |
| Permission model | *Example:* Roles assigned to groups, never to individuals; groups named `[scope]-[role]` |
| Privileged access | *Example:* Just-in-time elevation with approval and a maximum duration of 8 hours |
| Access reviews | *Example:* Quarterly for privileged roles, semi-annual for all others |

| Role ID | Role | Scope | Permissions summary | Assigned to |
|---|---|---|---|---|
| ROL-001 *(Example)* | Platform administrator | Organisation | Manage hierarchy, guardrails and shared services | Platform team group, just-in-time |
| ROL-002 *(Example)* | Workload operator | One container | Deploy and operate workload resources, no identity or network changes | Workload team group |
| ROL-003 *(Example)* | Read-only auditor | Organisation | Read configuration and logs | Audit group |
| ROL-004 *(Example)* | Security responder | Organisation | Read everything, isolate resources | Security operations group, just-in-time |
| [ROL-NNN] | [Role] | [Scope] | [Summary] | [Group] |

### 4.2 Machine access

Pipelines and workloads use short-lived credentials obtained through
workload identity federation or provider-managed identities. Record any
exception that needs a long-lived secret, with its owner, storage
location and rotation period.

### 4.3 Break-glass access

| Item | Design |
|---|---|
| Accounts | *Example:* Two break-glass identities per organisation root, not federated |
| Credential storage | *Example:* Hardware security keys in two separate safes; passwords split between two custodians |
| Use conditions | *Example:* Identity provider outage or lockout of all administrators |
| Alerting | *Example:* Any sign-in raises a critical alert to security operations and the platform lead |
| Testing | *Example:* Sign-in test every six months, recorded in the change log |
| Post-use actions | *Example:* Rotate credentials, review all actions taken, write an incident record |

## 5. Network topology and IP plan

<!-- Guidance: Choose the topology and allocate address space for the target scale. Questions: hub and spoke, mesh or provider-managed WAN? Where is traffic inspected? Pitfall: overlapping ranges with on-premises networks that block connectivity later. -->

### 5.1 Topology

```mermaid
flowchart LR
  ONP[On-premises data centres] ---|private links| HUB
  INET[Internet] --- EDGE[Ingress and egress inspection]
  EDGE --- HUB[Hub network<br/>firewall, DNS, shared endpoints]
  HUB --- SP1[Spoke: payments-prod]
  HUB --- SP2[Spoke: orders-prod]
  HUB --- SP3[Spoke: non-production shared]
  SP1 -. no direct peering .- SP2
```

| Decision | Choice | Rationale |
|---|---|---|
| Topology *(Example)* | Hub and spoke per region, hubs connected to each other | Central inspection and shared endpoints |
| Spoke-to-spoke traffic *(Example)* | Routed through the hub firewall, denied by default | East-west inspection and segmentation |
| Internet egress *(Example)* | Central egress through the hub with URL and threat filtering | Single control point |
| Internet ingress *(Example)* | Per-workload load balancer with web application firewall in the spoke | Workload ownership of public endpoints |
| DNS *(Example)* | Central private DNS zones in the hub, conditional forwarding to on-premises | Consistent name resolution |
| Private service access *(Example)* | Private endpoints for managed services; public endpoints denied by policy | Keep data paths private |

### 5.2 IP address plan

| Range | Size | Use | Region |
|---|---|---|---|
| *Example:* 10.100.0.0/14 | 262,144 addresses | All cloud address space, not used on premises | All |
| *Example:* 10.100.0.0/20 | 4,096 | Hub, region 1 | [Region 1] |
| *Example:* 10.101.0.0/16 | 65,536 | Spokes, region 1, allocated in /22 blocks | [Region 1] |
| *Example:* 10.102.0.0/20 | 4,096 | Hub, region 2 | [Region 2] |
| *Example:* 10.103.0.0/16 | 65,536 | Spokes, region 2, allocated in /22 blocks | [Region 2] |
| [Range] | [Size] | [Use] | [Region] |

Allocate spoke ranges through an IP address management tool integrated
with the vending pipeline (section 13). Never reuse a range until the
container that held it has been closed and its routes removed.

## 6. Connectivity

<!-- Guidance: Describe how the landing zone connects to on-premises sites, partners and other clouds. Pitfall: a single private link with no tested failover. -->

| Link ID | From | To | Type | Bandwidth | Redundancy | Owner |
|---|---|---|---|---|---|---|
| CON-001 *(Example)* | Data centre A | Hub region 1 | Dedicated private link | [10 Gbit/s] | Two links on separate devices | @network-lead |
| CON-002 *(Example)* | Data centre B | Hub region 1 | Site-to-site VPN | [1 Gbit/s] | Backup for CON-001 | @network-lead |
| CON-003 *(Example)* | Partner network | Partner spoke | Private connectivity with NAT | [500 Mbit/s] | Single, accepted risk RSK-004 | @integration-lead |
| [CON-NNN] | [From] | [To] | [Type] | [Bandwidth] | [Redundancy] | [@owner] |

State the routing model (static or dynamic, route advertisement limits),
how failover is tested and the expected failover time.

## 7. Security baseline and guardrails

<!-- Guidance: List the controls every container inherits. Separate preventive controls (block an action) from detective controls (find and report a condition). Pitfall: dozens of detective findings nobody triages. -->

### 7.1 Guardrail sets

| ID | Guardrail | Type | Set | Applied at | Response |
|---|---|---|---|---|---|
| GR-001 *(Example)* | Deny resource creation outside approved regions | Preventive | GRS-CORE | Root | Request blocked |
| GR-002 *(Example)* | Deny disabling or deleting central audit logging | Preventive | GRS-CORE | Root | Request blocked |
| GR-003 *(Example)* | Deny creation of long-lived user access keys | Preventive | GRS-CORE | Root | Request blocked |
| GR-004 *(Example)* | Deny public access to object storage unless tagged as approved public content | Preventive | GRS-PROD | Workloads / Production | Request blocked |
| GR-005 *(Example)* | Require encryption at rest with customer-managed keys | Preventive | GRS-REG | Regulated production | Request blocked |
| GR-006 *(Example)* | Detect security groups or firewall rules open to the internet on administrative ports | Detective | GRS-CORE | Root | Ticket to workload owner, fix within 7 days |
| GR-007 *(Example)* | Detect resources missing mandatory tags | Detective | GRS-CORE | Root | Weekly report, auto-tag where possible |
| GR-008 *(Example)* | Detect root or break-glass sign-in | Detective | GRS-CORE | Root | Critical alert to security operations |
| [GR-NNN] | [Guardrail] | [Preventive / Detective / Corrective] | [Set] | [Node] | [Response] |

### 7.2 Baseline services enabled in every container

| Service | Configuration | Owner |
|---|---|---|
| Audit logging of control-plane events *(Example)* | Enabled organisation-wide, delivered to the log archive | Platform team |
| Threat detection *(Example)* | Enabled in all regions, findings aggregated in the security tooling container | Security operations |
| Configuration recording and posture management *(Example)* | Enabled, benchmark checks from section 14 | Security operations |
| Key management *(Example)* | Customer-managed keys for regulated data, rotation yearly | Platform team |
| [Service] | [Configuration] | [Owner] |

## 8. Logging and monitoring

<!-- Guidance: Decide what is collected, where it lives, how long it is kept and who can read it. Pitfall: logs stored in the same container they describe, where an attacker with access can delete them. -->

| Log type | Source | Destination | Retention | Access |
|---|---|---|---|---|
| Control-plane audit *(Example)* | All containers | Log archive, immutable storage | [1 year hot, 7 years archive] | Security and audit read-only |
| Network flow logs *(Example)* | Hub and spokes | Log archive | [90 days] | Network and security |
| Guardrail and posture findings *(Example)* | Posture service | Security tooling container | [1 year] | Security operations |
| Workload application logs *(Example)* | Workload containers | Workload log store, security copy for critical events | [Workload-defined, minimum 30 days] | Workload team, security |
| [Log type] | [Source] | [Destination] | [Retention] | [Access] |

Platform monitoring covers hub network health, private link status,
quota use, guardrail evaluation failures and pipeline failures. Route
platform alerts to the platform on-call rotation and security alerts to
security operations. Record each alert, its threshold and its runbook in
the platform runbook (`dev/runbook`).

## 9. Policy as code

<!-- Guidance: Describe how guardrails are written, tested, approved and deployed. Pitfall: a policy deployed straight to the root that blocks every pipeline in the organisation. -->

| Item | Design |
|---|---|
| Policy language and tooling | *Example:* Provider-native policy definitions managed in IaC, with an open policy engine for pre-deployment checks |
| Repository | *Example:* `platform-policies`, protected main branch, two approvals including security |
| Testing | *Example:* Unit tests for each policy; deployment to the policy staging node before production |
| Rollout | *Example:* Audit mode for 14 days, review of findings, then enforcement |
| Pre-deployment checks | *Example:* Workload pipelines run the same rules against plans before apply |
| Exception handling | *Example:* Exemptions declared in code with expiry date, risk owner and ticket reference |

Every guardrail in section 7 has a policy file, a test and a named
owner. A guardrail with no code is a documented intention, not a control.

## 10. Cost management and tagging

<!-- Guidance: Make cost visible from day one. Questions: which tags are mandatory? Who receives which budget alerts? Pitfall: optional tags that nobody fills in. -->

| Tag key | Required | Allowed values | Purpose |
|---|---|---|---|
| `cost-centre` *(Example)* | Yes | Finance cost centre codes | Allocation |
| `workload` *(Example)* | Yes | Registered workload IDs | Showback, ownership |
| `environment` *(Example)* | Yes | `prod`, `test`, `dev`, `sandbox` | Policy and reporting |
| `owner` *(Example)* | Yes | Team distribution list | Contact for findings |
| `data-classification` *(Example)* | Yes | `public`, `internal`, `confidential`, `restricted` | Security guardrails |
| [Tag] | [Yes / No] | [Values] | [Purpose] |

| Control | Design |
|---|---|
| Budgets *(Example)* | Created by vending for every container; alerts at 80 % and 100 % to the owner and FinOps |
| Anomaly detection *(Example)* | Daily anomaly detection with alerts above [a set percentage] day-on-day change |
| Shared cost allocation *(Example)* | Hub and shared services allocated by consumption share monthly |
| Sandbox limits *(Example)* | Hard budget action that stops resources at 100 % |

Review costs with the FinOps cost review (`ops/finops-cost-review`).

## 11. Environment strategy

<!-- Guidance: Define which environments exist and how they differ. Pitfall: production data copied into test environments with weaker guardrails. -->

| Environment | Purpose | Hierarchy node | Data allowed | Connectivity | Promotion gate |
|---|---|---|---|---|---|
| Sandbox *(Example)* | Learning and experiments | Sandbox | Synthetic only | Internet only | None |
| Development *(Example)* | Feature development | Non-production | Synthetic or masked | Hub, non-production routes | Automated tests |
| Test *(Example)* | Integration and performance tests | Non-production | Masked | Hub, non-production routes | Test sign-off |
| Production *(Example)* | Live service | Production or Regulated production | Real data | Hub, production routes | Change approval |
| [Environment] | [Purpose] | [Node] | [Data] | [Connectivity] | [Gate] |

## 12. IaC repositories

<!-- Guidance: Show where each layer of the landing zone is defined and who can change it. Keep the layout consistent with the Infrastructure design (`architecture/infrastructure-design`). -->

| Repository | Content | Pipeline | Approvers | State location |
|---|---|---|---|---|
| `platform-foundation` *(Example)* | Hierarchy, organisation settings, log archive, security tooling | Plan on pull request, apply on merge | Platform and security | Dedicated state store in the platform container |
| `platform-network` *(Example)* | Hubs, connectivity, DNS, firewall rules | Same, with change window | Network and security | Same |
| `platform-policies` *(Example)* | Guardrail definitions and assignments | Staged rollout, section 9 | Security and platform | Same |
| `platform-vending` *(Example)* | Vending modules and request definitions | Triggered by approved requests | Platform | Same |
| [Repository] | [Content] | [Pipeline] | [Approvers] | [State] |

## 13. Account and subscription vending runbook

<!-- Guidance: Write this as an executable procedure. Each step names the actor, the system and the evidence. Pitfall: manual steps that are skipped under pressure, leaving containers without budgets or logging. -->

### 13.1 Request intake

The workload team submits a request through [service portal]. The
request must contain the fields below; the pipeline rejects incomplete
requests.

| Field | Example | Used for |
|---|---|---|
| Workload ID | *Example:* WL-0142 payments | Naming, tags |
| Environments | *Example:* dev, test, prod | Number of containers |
| Business criticality and data classification | *Example:* Tier 1, confidential | Hierarchy placement, guardrails |
| Network needs | *Example:* Private connectivity to on-premises, /22 per environment | IP allocation, peering |
| Owner and cost centre | *Example:* @payments-lead, CC-4410 | Tags, budget alerts |
| Monthly budget | *Example:* [Value] per environment | Budget creation |
| Pipeline identity | *Example:* Repository `payments-service` | Federated deployment role |

### 13.2 Procedure

| Step | Actor | Action | Evidence |
|---|---|---|---|
| VND-01 | Workload team | Submit request with all fields | Request ticket |
| VND-02 | Pipeline | Validate fields, check naming and duplicates | Validation log |
| VND-03 | Approver per section 13.3 | Approve or reject | Approval record |
| VND-04 | Pipeline | Create container and place it in the hierarchy node for its classification | Container ID |
| VND-05 | Pipeline | Apply baseline: logging, threat detection, posture, key policy | Baseline run log |
| VND-06 | Pipeline | Allocate IP range from IPAM, create spoke, connect to hub | IPAM record, route table |
| VND-07 | Pipeline | Create groups and role assignments, federated pipeline identity | Role assignment list |
| VND-08 | Pipeline | Apply tags and create budget with alerts | Budget ID |
| VND-09 | Pipeline | Run post-provision checks (guardrails active, logs arriving, no public exposure) | Check report |
| VND-10 | Platform team | Hand over to the workload team with the onboarding guide | Handover message |

```mermaid
sequenceDiagram
  participant WT as Workload team
  participant P as Vending pipeline
  participant A as Approver
  participant IP as IPAM
  WT->>P: Submit request (VND-01)
  P->>P: Validate (VND-02)
  P->>A: Request approval (VND-03)
  A-->>P: Approved
  P->>P: Create container, apply baseline (VND-04, VND-05)
  P->>IP: Allocate range (VND-06)
  IP-->>P: Range assigned
  P->>P: Roles, tags, budget, checks (VND-07 to VND-09)
  P-->>WT: Handover (VND-10)
```

### 13.3 Approval rules and service level

| Request type | Approver | Target time from request to handover |
|---|---|---|
| Sandbox *(Example)* | Automatic | 1 hour |
| Non-production *(Example)* | Platform team | 1 working day |
| Production *(Example)* | Platform team and workload architect | 2 working days |
| Regulated production *(Example)* | Platform team and security | 5 working days |

### 13.4 Closure

To close a container: confirm with the owner, export required data, move
it to the Suspended node, remove network routes and release the IP range
after [30 days], then close it through the provider process. Keep the
audit logs for the full retention period.

## 14. Compliance mapping

<!-- Guidance: Show which external baselines the landing zone is measured against and how. Use the benchmark version current at the time of review. Pitfall: claiming compliance from a one-off scan. -->

The Center for Internet Security publishes CIS Benchmarks, consensus
configuration guides for each major provider (for example the AWS
Foundations, Microsoft Azure Foundations and Google Cloud Platform
Foundation benchmarks). Record the benchmark and version in use, map
each recommendation group to a guardrail and report the pass rate.

| Benchmark section *(by topic)* | Guardrails | Check method | Pass rate | Exceptions |
|---|---|---|---|---|
| Identity and access management *(Example)* | GR-003, ROL-001 to ROL-004 | Posture service, quarterly access review | [Value] | [EXC-NNN] |
| Logging *(Example)* | GR-002, section 8 | Posture service | [Value] | [EXC-NNN] |
| Monitoring and alerting *(Example)* | GR-008 | Alert test | [Value] | [EXC-NNN] |
| Networking *(Example)* | GR-006, section 5 | Posture service | [Value] | [EXC-NNN] |
| Storage and data protection *(Example)* | GR-004, GR-005 | Posture service | [Value] | [EXC-NNN] |
| [Topic] | [Guardrails] | [Method] | [Value] | [Exceptions] |

| Benchmark in use | Version | Profile level | Last assessed |
|---|---|---|---|
| [CIS benchmark for provider] | [Version] | [Level 1 / Level 2] | YYYY-MM-DD |

Map further obligations (data protection law, sector regulation,
customer contracts) in the Security architecture
(`security/security-architecture`).

## 15. Operations and change

<!-- Guidance: Describe how the landing zone itself is run and changed. Pitfall: treating the platform as a project that ends at go-live. -->

| Activity | Cadence | Owner | Output |
|---|---|---|---|
| Guardrail findings triage *(Example)* | Daily | Security operations | Tickets to owners |
| Platform change advisory *(Example)* | Weekly | Platform lead | Approved change list |
| Quota and capacity review *(Example)* | Monthly | Platform team | Quota increase requests |
| Provider release review *(Example)* | Monthly | Platform architect | Backlog items for new features or deprecations |
| Break-glass test *(Example)* | Every six months | Security | Test record |
| Disaster recovery test of shared services *(Example)* | Yearly | Platform team | Test report |
| Design review of this document *(Example)* | Yearly or after major change | Architecture board | New version |

Changes to the hierarchy, identity federation, hub network or root-level
guardrails are major changes: they need an approved change request
(`ops/change-request`), a tested rollback and a communication to all
workload owners at least [5 working days] in advance.

### 15.1 Risks

| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | A root-level guardrail blocks production deployments | Medium | High | Staged rollout, audit mode first | @platform-lead |
| RSK-002 *(Example)* | Identity provider outage locks out administrators | Low | High | Break-glass process, section 4.3 | @security-architect |
| RSK-003 *(Example)* | IP space exhausted in region 1 | Low | Medium | Unallocated part of the /14 held for growth, IPAM alerts at 70 % | @network-lead |
| RSK-004 *(Example)* | Partner link has no redundancy | Medium | Medium | Accepted until YYYY-MM-DD | @integration-lead |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |

## 16. Glossary and references

<!-- Guidance: Define the neutral terms used here and list the provider sources consulted, with the date you checked them. -->

### 16.1 Glossary

| Term | Meaning |
|---|---|
| Landing zone | Governed, pre-configured cloud foundation into which workloads are deployed |
| Isolation container | AWS account, Azure subscription or Google Cloud project |
| Hierarchy node | Organisational unit, management group or folder that carries inherited policy |
| Guardrail | Preventive or detective control applied across many containers |
| Vending | Automated provisioning of a governed container on request |
| Break-glass | Emergency access path used only when normal access fails |
| IPAM | IP address management tool that tracks allocations |

### 16.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Microsoft Cloud Adoption Framework, Azure landing zone design areas, learn.microsoft.com | Page dated September 2025, checked YYYY-MM-DD | Design area coverage |
| Microsoft Cloud Adoption Framework, Subscription vending, learn.microsoft.com | Page dated December 2025, checked YYYY-MM-DD | Section 13 |
| AWS Control Tower User Guide, multi-account strategy for your landing zone, docs.aws.amazon.com | Current web edition | Hierarchy and OU pattern |
| Google Cloud Architecture Center, Landing zone design in Google Cloud, docs.cloud.google.com | Page updated January 2026 | Identity, hierarchy, network, security decisions |
| CIS Benchmarks, Center for Internet Security, cisecurity.org | Version per section 14 | Compliance mapping |
| [Internal standard] | [Version] | [Use] |

## Standard and licence note

Structure aligned with the landing zone design areas published by
Microsoft (Cloud Adoption Framework for Azure), Amazon Web Services
(AWS Control Tower and Prescriptive Guidance multi-account guidance) and
Google Cloud (landing zone design in Google Cloud), and with the topics
covered by CIS Benchmarks. Product and framework names belong to their
publishers and are used for mapping only; CIS Benchmarks are referenced
by name and topic and no recommendation text is reproduced. This
template is original text written for this collection. Check the
current official documentation and benchmark versions before use.
Template licence: MIT.