Cloud Security Maturity Model: 5 Levels, 10 Dimensions

Most organisations can show a cloud security tool and a posture score, but few can show that every account sits under guardrails, that no workload holds a long-lived key, and that they would see an attacker switch off logging. Maturity is how much of the estate is governed by default, how narrow each identity's permissions are, and how fast drift and misuse are caught. This five-level model, using the same Ad hoc to Optimised scale as the NHI Mgmt Group Identity Security Maturity Model, scores cloud security across ten dimensions for AWS, Azure and Google Cloud, and maps them to the CSA Cloud Controls Matrix v4.1, NIST CSF 2.0 and CIS Controls v8.1. It is for cloud security leads, platform engineering managers and CISOs who need an honest baseline and a roadmap.

Key takeaways

Score ten dimensions separately, from governance and guardrails through human and workload identity to logging and recovery, using evidence from the live estate.
Your level is set by the weakest dimension an attacker would use. A strong posture score is worth little if access keys older than a year are still active.
Level 3 (Defined) is the right first target for most organisations: every account created through a landing zone, preventive guardrails at the top of the hierarchy, federated human access with phishing-resistant MFA, and organisation-wide audit logs in a separate account.
Identity separates Level 3 from Level 4. Inadequate identity and access management is first in the CSA Top Threats to Cloud Computing 2026; removing static keys and right-sizing roles from usage data is the core of moving up.
Measure coverage and speed, not tool count: accounts under guardrails, long-lived keys remaining, unused permissions, critical findings fixed within target and time to detect a disabled log.

The five levels

Level	Name	Description
1	Ad hoc	Accounts, subscriptions and projects created by individual teams with no common structure. Administrators share broad roles, workloads use access keys, logging is the provider default, and nobody can list every cloud account the organisation owns.
2	Developing	A cloud security owner exists and the provider's posture tool is turned on, but findings pile up unowned. Some accounts use single sign-on and MFA; others still have local users. A baseline such as the CIS Foundations Benchmark is known but not enforced.
3	Defined	A landing zone with an account hierarchy, preventive guardrails and account vending. Human access is federated with phishing-resistant MFA and no standing administrator roles. Organisation-wide audit logs go to a separate log archive account. Posture findings have owners and due dates, and a cloud incident playbook exists.
4	Managed	Everything is deployed through infrastructure as code with policy checks in the pipeline. Long-lived keys are blocked by policy, workloads use roles, managed identities and federation, and permissions are right-sized from usage data. Data-plane logs for sensitive stores feed detection, and recovery is tested.
5	Optimised	Data perimeters restrict access to trusted identities, networks and resources. High-confidence findings are fixed automatically, detections are tested by red team and attack simulation, and lessons from incidents and exercises update guardrails and code.

The ten dimensions

Levels 2 and 4 sit between the descriptions shown; the roadmap below lists what moves you from each level to the next.

Dimension	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Governance and shared responsibility	No cloud policy; teams assume the provider secures everything	Cloud security policy and standards per provider; shared responsibility written down per service model (IaaS, PaaS, SaaS); risk exceptions recorded with expiry	Guardrails, standards and exceptions managed as code; trends reported to the board
Landing zone and guardrails	Accounts created on a credit card; no hierarchy	Account vending into a hierarchy (AWS Organizations OUs, Azure management groups, Google Cloud folders); preventive guardrails such as AWS SCPs and RCPs, Azure Policy deny effects and Google Cloud organisation policies; unused Regions denied	Guardrails tested in a sandbox OU before rollout; data perimeters restrict access to trusted identities, networks and resources
Human identity and privileged access	Local IAM users, shared root or Global Administrator logins	All humans federated through one identity provider with phishing-resistant MFA; root and break-glass accounts vaulted and monitored; no standing administrator roles	Just-in-time elevation with approval for all privileged roles; entitlements reviewed from usage data
Workload and machine identity	Access keys and service account key files in code and CI variables	Inventory of every key, service principal and service account with an owner; IMDSv2 enforced; key age limits alerted	Long-lived keys blocked by policy; roles, managed identities and workload identity federation everywhere; permissions right-sized from access logs
Posture and configuration management	Settings checked by hand, if at all	CSPM across all accounts against a CIS Foundations or provider baseline; each finding has an owner and due date	Policy-as-code checks in the pipeline block misconfiguration before deployment; drift auto-remediated for high-confidence controls
Data protection and key management	No idea where sensitive data lives; public buckets possible	Organisation-level public access blocks; encryption at rest by default; sensitive stores identified; key administrators separated from key users	Data security posture management finds and classifies data continuously; customer-managed keys where policy requires them, with rotation and access logged
Network exposure	Security groups open to 0.0.0.0/0; public management endpoints	Hub-and-spoke or equivalent design; private endpoints for data services; internet exposure reviewed against an approved list	Exposure validated continuously from outside; egress controlled
Workload and pipeline security	Images and functions never rescanned	Vulnerability scanning of VMs, images and functions, prioritised by exposure and KEV; secrets scanning in repositories; pipelines deploy with federated short-lived roles	Agentless and runtime coverage of every workload; signed images and admission control; pipeline identities bound to repository and branch
Logging, detection and response	Provider default logs only; nobody watching	Organisation-wide control-plane logs to a separate log archive account; provider threat detection enabled; cloud incident playbook	Data-plane logs for sensitive stores; detections for logging changes, new keys and role grants tested regularly; high-confidence containment automated
Resilience and recovery	Backups in the same account as production, if any	Backups in a separate account with restricted deletion; recovery objectives set for critical workloads	Immutable backups (object lock or vault lock); restores and Region failover exercised; recovery time measured

How the model maps to CSA CCM, NIST and CIS

The CSA Cloud Controls Matrix v4.1 is "composed of 197 control objectives that are structured in 17 domains", and now includes the CAIQ questionnaire; STAR Level 1 is a self-assessment and Level 2 a certification or third-party attestation. The NCSC's 14 cloud security principles are "designed to help you choose a cloud provider", and the NCSC adds that "You will separately need to consider how you configure your cloud services securely": this model scores that second part. For AWS estates, the AWS Security Maturity Model orders actions into four phases (Quick Wins, Foundational, Efficient, Optimized) by ease, cost and impact, which roughly track our Levels 2 to 5. Treat the mapping below as a sense check, not an official crosswalk.

Dimension	CSA CCM v4.1 domains	NIST CSF 2.0	CIS Controls v8.1
Governance and shared responsibility	GRC, A&A	GV.OC, GV.RM, GV.PO, GV.SC	15 (service providers)
Landing zone and guardrails	IVS, CCC	PR.PS, ID.AM	1, 4
Human identity and privileged access	IAM	PR.AA	5, 6
Workload and machine identity	IAM, CEK	PR.AA, ID.AM	5, 6
Posture and configuration	CCC, TVM	PR.PS, ID.RA	4
Data protection and keys	DSP, CEK	PR.DS	3
Network exposure	IVS	PR.IR	12, 13
Workload and pipeline security	TVM, AIS, STA	ID.RA, PR.PS	7, 16
Logging, detection and response	LOG, SEF	DE.CM, DE.AE, RS.MA	8, 13, 17
Resilience and recovery	BCR	PR.DS, RC.RP	11

ISO/IEC 27001:2022 covers cloud use in Annex A 5.23, with configuration management in 8.9 and logging in 8.15. NIST SP 800-210 treats IaaS, PaaS and SaaS as a hierarchy, so IaaS access control guidance carries up to the others.

Identity and NHI in the cloud

This dimension separates Level 3 from Level 4 more than any other, because cloud attackers mostly sign in: ATT&CK v20 lists T1078.004 Cloud Accounts, T1552.005 Cloud Instance Metadata API and T1098.003 Additional Cloud Roles among its cloud techniques. What Level 4 looks like on each platform:

AWS: "Require workloads to use temporary credentials with IAM roles to access AWS" is one of AWS's IAM best practices; IAM last accessed information and Access Analyzer unused access findings drive removal of unused roles, keys and permissions, and IMDSv2 is required on every instance. See the AWS Security Guide.
Azure: managed identities replace secrets because they "eliminate the need for developers to manage these credentials"; user-assigned identities have an independent lifecycle and must be deleted explicitly, so they need owners. Service principal secrets and certificates are inventoried and time-limited. See the Microsoft Azure Security Guide.
Google Cloud: the "Disable service account key creation" and "Disable service account key upload" organisation policy constraints are enforced at the organisation root, workload identity federation serves external workloads, and the key exposure response constraint is set to DISABLE_KEY. See the Google Cloud Security Guide.
Pipelines and clusters: CI/CD jobs use OIDC federation to short-lived roles, and Kubernetes workloads use the provider's workload identity rather than node credentials. See the CI/CD Pipeline Identity Security Guide and the Kubernetes NHI Security Guide.

The Capital One breach shows why role scope matters as much as removing keys: request forgery returned temporary role credentials, and the role could read storage. See the Cloud Workload Identity Guide and the Cloud PAM and CIEM Guide, and score machine identity governance in more depth with the NHI Governance Maturity Model.

Self-assessment questions

Score each dimension from 1 to 5 using exports from the organisation, IAM reports and posture tools, not the architecture diagram. Take the lowest score among the dimensions your most likely serious incident (usually stolen credentials or exposed data) would depend on as your overall level.

Governance: can you produce a complete list of every AWS account, Azure subscription and Google Cloud project the organisation pays for, each with an owner?
Guardrails: which preventive policies apply at the root of each hierarchy, and could a workload administrator turn off logging or make storage public?
Human identity: how many human identities can reach a cloud console without phishing-resistant MFA, and who holds standing Owner, Global Administrator or AdministratorAccess?
Workload identity: how many access keys and service account keys are active, how old is the oldest, and when was each last used?
Posture: what share of critical posture findings were fixed within your target last quarter, and how many are older than 90 days?
Data: which storage resources are publicly accessible today, and is each one a recorded exception?
Detection: if someone stopped your organisation trail or deleted a log sink at 3am, who would be alerted and how fast?
Recovery: could an attacker holding production administrator credentials delete your backups?

Moving up a level

Size changes the route, not the target. A small organisation on one provider can reach Level 3 with the provider's landing zone service (such as AWS Control Tower or Azure landing zones) and built-in posture and threat detection; the AWS Security Maturity Model notes startups may focus mainly on its first two phases. A large or multi-cloud organisation needs a platform team owning guardrails as code, a CNAPP or equivalent for consistent posture across providers, and central workload identity governance. See the CNAPP Guide.

From Ad hoc to Developing

Inventory every account, subscription and project, including any paid on expenses, with an owner.
Protect root and Global Administrator accounts with phishing-resistant MFA, remove root access keys, and set billing and budget alerts.
Turn on each provider's audit logging and posture tool in every account, and block public storage at account level as a minimum.

From Developing to Defined

Build or adopt a landing zone with separate security, log archive and workload accounts, and move existing accounts in one at a time.
Test preventive guardrails before enforcing them at the root: Azure Policy audit effects and Google Cloud organisation policy dry-run show what would be blocked, and AWS SCPs go on a test OU first. Keep a tested break-glass path to roll back.
Federate all human access through one identity provider with phishing-resistant MFA, and replace standing administrator roles with just-in-time elevation. See the JIT Access Guide.
Send organisation-wide control-plane logs to the log archive account, and alert on any change to logging.
Adopt a baseline (CIS AWS Foundations is at v7.1.0; use the matching CIS benchmark for Azure and Google Cloud), assign every critical finding an owner and due date, and write a cloud incident playbook. See the Cloud Incident Response Guide.

From Defined to Managed

Move all deployments to infrastructure as code with policy checks in the pipeline; treat console changes in production as drift. See the Cloud Misconfiguration Guide.
Block creation of long-lived keys by policy, migrate workloads to roles, managed identities and federation, and rotate or delete every remaining key.
Right-size permissions from usage data and remove identities unused for 90 days.
Enable data-plane logs for sensitive stores and find sensitive data with DSPM. See the DSPM Buyer's Guide.
Move backups to a separate account with immutability, and run a restore test for each critical workload.

From Managed to Optimised

Implement data perimeters so only trusted identities reach trusted resources from expected networks.
Auto-remediate high-confidence findings and contain high-confidence detections, with a documented release process.
Test detections with red teaming and attack simulation; feed lessons into guardrails.

Metrics that show maturity

Guardrail coverage: percentage of accounts, subscriptions and projects inside the managed hierarchy with baseline guardrails and central logging (target 100%).
Static credentials: number of active access keys and service account keys, and the age of the oldest.
Unused privilege: percentage of granted permissions or admin roles not used in 90 days.
Phishing-resistant MFA: percentage of human cloud identities covered.
Remediation speed: median days to fix critical posture findings, and the count older than 90 days.
Detection of tampering: minutes from a test logging change to an alert being worked.

Common failure patterns

Shadow accounts outside the landing zone: a forgotten test tenant without MFA was the start of the Microsoft Midnight Blizzard breach. Anything outside the hierarchy has no guardrails, logs or owner.
Posture score as the goal: sharing links and keys escape checks that only look at bucket policies, as the Microsoft SAS token exposure showed with 38TB exposed through one link.
Keys left after the migration: workloads move to roles, but the old key is never deleted; in the Toyota T-Connect key exposure a key sat on public GitHub for five years.
Backups the attacker can reach: backups deletable by production administrators do not survive an attacker holding those credentials, as the Codefinger S3 ransomware made clear.
Guardrails enforced untested: a root deny policy breaks production pipelines and is removed for good instead of fixed.

Practitioner checklist

Score all ten dimensions with evidence from the live estate.
Set Level 3 as the 12-month target, with Level 4 for workload and machine identity.
Inventory every account, subscription and project and bring it under the landing zone.
Enforce phishing-resistant MFA and remove standing administrator roles.
Block new long-lived keys by policy and track the remaining ones to zero.
Send organisation-wide logs to a separate account and alert on logging changes.
Keep backups immutable in a separate account and test restores.
Baseline the six metrics now, report them quarterly and reassess yearly.

Cloud Security Maturity Model