Cloud Account Request and Guardrails Checklist

Every new cloud account, subscription or project is a fresh security boundary, and whatever is missing on the day it is handed to a workload team tends to stay missing. Organisation-level guardrails do a lot, but they cannot assign an owner, set a budget alert, attach the right network or remove a creator's leftover admin rights. This template gives [Organisation] a request form and a pre-handover checklist for new cloud environments: what the requester must provide, what the platform team must configure and verify, and who signs off before the keys change hands. It is for cloud platform teams, cloud centres of excellence and security architects running account or subscription vending. The organisation-wide design sits in the Cloud Landing Zone Security Guide; this page covers what happens for each new environment.

How to use this template

Use it for every new environment: AWS accounts, Azure subscriptions and Google Cloud projects. Providers are listed alphabetically throughout; the term "account" below means any of the three unless a provider is named.
Put the request form in your service management tool and drive provisioning from it, so the approved request is the input to your vending pipeline rather than a document someone retypes.
Automate the checklist as tests. Most items in section 5 can be checked by the pipeline after provisioning. Keep the manual sign-off for the items that cannot.
Replace the bracketed values with your own: [Organisation], approvers, budget thresholds, tag keys and IP address ranges. Thresholds and timings shown are NHI Mgmt Group recommendations.

1. Purpose and scope

1.1 This procedure ensures every cloud environment created for [Organisation] is requested by an accountable owner, placed under the correct guardrails, and verified against a security baseline before it is handed to the workload team.

1.2 It applies to new environments created by any route, including automated vending, manual creation by the platform team and environments transferred in from acquisitions or suppliers. Sandbox environments follow the same steps with the sandbox profile in section 4.

1.3 Microsoft's Cloud Adoption Framework describes this pattern as subscription vending: a platform mechanism that standardises the request, deployment and handoff of subscriptions. The same model applies to AWS accounts and Google Cloud projects.

2. Roles

Role	Responsibility
Requester	Completes the request form; usually the workload's technical lead
Environment owner	Named, accountable employee for the environment's cost, data and access for its whole life; becomes the recipient at handover
Cost centre approver	Approves the budget and charging code
Platform team	Provisions the environment through the vending pipeline, configures the baseline and runs the checklist
Security reviewer	Approves requests classed as production with confidential or regulated data, and any exception to the baseline

3. Request form

#	Field	Why it is needed
1	Workload name and short description	Naming and inventory
2	Environment type: sandbox, development, test, production	Selects the organisational unit, management group or folder and the guardrail profile
3	Data classification and any regulated data (personal data, payment card data, health data)	Selects stricter guardrails and triggers security review
4	Business criticality and recovery objectives	Backup and resilience requirements
5	Environment owner and deputy (employees, not guests or suppliers)	Accountability; Azure subscription owners must be users or service principals in the tenant, and guest users are not allowed
6	Cost centre, monthly budget estimate and approver	Budget and alerts
7	Regions required	Region restriction guardrail; data residency
8	Network needs: connectivity to the hub or shared network, address space size, internet exposure required (yes or no, with reason)	Address allocation without overlap; ingress design
9	Access groups needed and their members' roles	Federated access through the workforce identity provider
10	Deployment and workload identities needed (pipelines, applications)	Federated or managed identities instead of long-lived keys
11	Planned end date or review date	Lifecycle; sandboxes always have an end date
12	Known exceptions to the baseline requested	Routed to the security reviewer before provisioning

4. Guardrail profiles

4.1 The environment type and data classification select one profile. Placement in the hierarchy applies the profile's preventive guardrails automatically.

Profile	Placement	Key differences (our recommendation)
Sandbox	Sandbox organisational unit, management group or folder	No connection to the corporate network; low budget with alert at [50]% and automatic action at [100]%; end date no more than [90] days; no production or real customer data
Non-production	Non-production branch of the hierarchy	Connected to non-production network only; synthetic or masked data; standard guardrails
Production	Production branch	Full guardrail set; change through pipeline only; backups to a separate environment; security review for confidential data
Regulated production	Dedicated regulated branch	Production plus region lock to approved jurisdictions, customer-managed encryption keys, extended log retention and named access reviews [quarterly]

5. Pre-handover baseline checklist

5.1 The platform team completes and evidences every item before handover. Pipeline tests should cover items marked (auto).

Ownership and inventory

[ ] Environment registered in the cloud inventory with owner, deputy, cost centre, classification and end date. (auto)
[ ] Required tags or labels applied at creation: [owner, cost-centre, environment, data-classification, workload]. (auto)
[ ] Security and billing contacts point to monitored team mailboxes, not an individual. On AWS, set the account's alternate contacts for security, billing and operations.
[ ] Name and identifier contain no sensitive information. Google Cloud project IDs are permanent and appear in other resource names, so Google advises keeping personal or security data out of them.

Placement and guardrails

[ ] Environment placed in the organisational unit, management group or folder for its profile. (auto)
[ ] Organisation-level guardrails confirmed as inherited: allowed regions, protection of logging and security tooling, block on public sharing of storage, restrictions on long-lived keys. (auto) See the Preventive Cloud Guardrails Guide.
[ ] Default networks or other defaults the landing zone does not use are removed or blocked by policy.

Identity and access

[ ] Human access only through federated groups from the workforce identity provider; no local users created. (auto)
[ ] Privileged roles granted through just-in-time elevation where the platform supports it; standing owner or administrator assignments limited to [2] break-glass or platform identities.
[ ] Creator access removed: the person or pipeline that created the environment no longer holds owner rights unless they are the named owner.
[ ] Workload and deployment identities use federation or managed identities rather than stored keys, and each has an owner recorded in the NHI inventory. See the Workload Identity Federation Guide.
[ ] AWS: member account root user credentials removed through centralised root access management, which AWS Organizations provides for member accounts; privileged root tasks run from the management account or delegated administrator only.
[ ] Azure: subscription owner count kept to the minimum, access via Microsoft Entra groups, and Privileged Identity Management for groups used for elevated access, as the subscription vending guidance recommends.
[ ] Google Cloud: project-level IAM granted to groups, not individuals; confirm the Project Creator role (granted by default to the whole domain when a new organisation is created) has been restricted at organisation level so projects are created only through the vending route.

Logging, detection and posture

[ ] Control plane audit logs flowing to the central logging environment; a test event confirmed as received. (auto)
[ ] Threat detection and posture services enabled and reporting to the central security environment. (auto) See the Cloud Security Posture Management (CSPM) Guide.
[ ] Posture scan run after provisioning with zero high-severity findings outstanding at handover.

Network

[ ] Address space allocated from the IP address management system with no overlap in the routing domain. (auto)
[ ] Connected to the hub or shared network only if the request and profile allow it; no public ingress unless approved in the request.

Cost and data protection

[ ] Budget created from the request with alerts to the owner and cost centre approver at [50]%, [80]% and [100]%. Microsoft notes that budgets are not hard limits, so treat alerts as a detection control rather than a spending cap. See Cloud Cost Anomalies as Security Signals.
[ ] Encryption key approach applied for the classification (provider-managed or customer-managed keys).
[ ] Backup policy assigned where the profile requires it, with backups held in a separate environment.

6. Handover

6.1 Handover happens only when every section 5 item is complete or covered by an approved exception with an expiry date.

6.2 The platform team sends the owner a handover record: environment identifier, profile, access groups and how to request membership, network details, budget and alert recipients, inherited guardrails and how to request an exception, and the end or review date.

6.3 The owner confirms in the ticket that they accept responsibility for the environment's cost, data, access reviews and decommissioning.

7. After handover

7.1 Owners review access group membership [quarterly] for production and [half-yearly] for non-production.

7.2 Changes to placement, profile or classification go through the request form again.

7.3 At the end date, or when the owner leaves without a named successor, the environment enters the decommissioning process. See Cloud Account and Resource Decommissioning.

Implementation guidance

Start from the vending pipeline you already have. On AWS this is commonly Control Tower Account Factory, where accounts are provisioned into an organisational unit with the AWSControlTowerBaseline enabled; on Azure, Microsoft publishes subscription vending Bicep and Terraform modules; on Google Cloud, the enterprise foundations blueprint creates projects through a per-business-unit infrastructure pipeline whose service account can deploy only to that unit's projects. See the AWS Control Tower Guide, the Azure Landing Zones Security Guide and the Google Cloud Organization Policy Guide.
Turn checklist items into tests that run after provisioning and fail the pipeline, then into scheduled checks so drift after handover is caught.
Pilot on sandboxes, where a failed check costs little, then non-production, then production.
Roll back by quarantine, not deletion. If an environment fails a check after handover, move it to a restricted placement with deny-by-default guardrails while the owner fixes it; do not delete workloads without the owner.
Backfill existing environments. Run the section 5 checks across every existing account, record owners and file exceptions for gaps.
Measure: share of environments created through the vending route; median time from approved request to handover; environments with a named, current owner; checklist failures at first run; environments past their end date; and environments with standing owner assignments above the limit.
Map for audit: NIST SP 800-53 Rev. 5 CM-2 Baseline Configuration and AC-2 Account Management; NIST CSF 2.0 PR.AA-03 for federated authentication of users and services.

Common failure patterns to avoid: environments created by hand outside the vending route; owners who are contractors or leave with no successor; creator admin rights left in place; sandboxes with no end date that quietly host production data; and budget alerts sent to an unmonitored mailbox.

Cloud Account Request and Guardrails Checklist: Baseline Before Handover