Home
Browse frameworks
Contact us
SAMMY premium
Sign in
Use SAMMY for free
Cloud Security Maturity Model 2.0
Browse Cloud Security...
AIMA
ASPICE Cybersecurity
ASVS
BSIMM 15
CIS Critical Security Controls
Cloud Controls Matrix
Cloud Security Maturity Model 2.0
CRA Framework
Cybersecurity Fundamentals
Cybersecurity Fundamentals 2.0
DSOMM
NIS2
NIST 800-171 Rev 2
NIST 800-171 Rev 3
NIST 800-34
NIST 800-53 v5
NIST CSF 2.0
NIST SSDF
OpenSAMM1.5
PCI DSS 4.0.1
SAMM
Secure Controls Framework
Governance
Cloud providers approved
CCoE exists
Initial benchmarks established
Cloud registry exists
CCoE has authority
Cloud security control objectives established
Control specifications enforced
Governance managed using automation tooling
Control objectives and specifications continuously updated in alignment with CSP releases
Organization Management
Most deployments are organized in a hierarchy
Core security checklist for new deployments manually enforced
CSPM implemented and actively used
Cloud service provider preventive policies are in use
Deployments used to manage blast radius
Cloud Service Provider preventive policies are consistently used
Security controls are automatically provisioned and managed using automation aligned with landing zones/account factories
IAM
SSO utilized for most console/portal access
MFA is required for cloud console/portal access
Users do not access the cloud console/portal outside of SSO
MFA enforced for API/CLI access
IAM policies are automatically assessed for overly broad access or possible privilege escalations in production deployments
An IAM data perimeter is enforced
JIT access used for access to production deployments
Security Monitoring
Core log collection established, but not necessarily consistent
Management plane API activity logs are consistently collected and centralized
CSP threat/detection feeds are enabled and collected for at least production environments
Robust cloud platform security telemetry centrally collected
Cloud-native threat detectors are enabled
Cloud security telemetry configurations are consistently and automatically provisioned into all deployments for the cloud management plane, resources, workloads and services
Automated tooling validates that security telemetry feeds and detections are active and effective, ideally through noise/fault injection
Network Security
Sensitive ports are not exposed to the internet
Compute resources on cloud networks are not directly exposed to the internet
Security groups should not allow excessive port ranges
Networks are implemented using IaC with approved secure patterns
Implement initial minimum viable network designs
Internet-facing network security misconfigurations are automatically remediated
Workload Security
Some instances/VMs managed with configuration management tooling
Instances/VMs are assessed for vulnerabilities
Containers use the CSP's orchestration platform
Moderate use of immutable instances/VMs
Use of long-running instances/VMs is minimized
Images are created using CI/CD pipelines with integrated security testing
A container security platform is in place
Function-as-a-service workloads (FaaS/serverless) do not have excessive privileges
Cloud-native vulnerability assessment is used consistently
Immutable workloads are the standard and do not enable remote administrative ports
Serverless/FaaS functions are continuously monitored, tracked and assessed for misconfigurations and code-level security issues
App Security
Threat modeling for cloud
Some applications are deployed using CI/CD pipelines
Basic security testing is integrated into some pipelines but may not be standardized
Initial use of cloud-native WAF with at least the OWASP Top 10 rules or equivalent implemented
Secrets management in use for applications
Security testing in CI/CD pipelines is consistent
Critical or high vulnerabilities block builds
Production applications are continuously assessed for expected cloud provider defenses and cloud security misconfigurations
Production cloud applications are tested by a red team and/or penetration testing using cloud-native techniques
Security testing of IaC is consistent
Data Security
Object storage is not public unless approved
Volume storage uses default encryption
Cloud provider controls to prevent public object storage are enabled
Customer-managed encryption keys are used for some resources or services
Deployments are continuously scanned for new public exposures
Customer-managed keys are service-specific and scoped to least privilege
Deployments assessed for unapproved sensitive data
Unapproved public data exposures are automatically remediated
Risk Assessment and Provider Management
Cloud providers undergo a risk assessment
The cloud provider registry includes which data classifications are approved for use in the CSP
The cloud provider registry includes risk ratings and approvals for CSP services, aligned with data classifications
Security performs risk assessments on all production deployments annually or after major updates; assessments use cloud-native threat/risk models
Security uses a formal process and criteria to assess the initial and ongoing risks of cloud deployments
Cloud provider risks are assessed continuously at the service level
Resilience
Multi-availability zone autoscaling is used
Virtual machines/instances and databases have recent snapshots
Object storage lifecycle or backups in use
Most compute workloads are autoscaled or serverless
Most deployments are based on infrastructure as code
Critical object storage and database data is accessible in at least two regions
All production deployments are configured and managed with infrastructure as code
Chaos engineering is implemented
Compliance and Audit
Basic compliance is manually assessed
Cloud providers and services are approved for regulated data, and this list is available within the organization
In-scope deployments consistently assessed for compliance before approval and on a scheduled basis
Technical compliance is continuously assessed using automation
Some preventive guardrails in place to meet high-level compliance requirements
Compliance reporting is automated, centralized and normalized across deployments and cloud providers
Incident Response
Incident response team is designated for cloud incidents and has manual processes
Cloud-specific playbooks are documented for major cloud incident types
Cloud incident responders have at least full-read access to all cloud deployments
Cloud Detection and Response, SOAR or other automated enrichment and process automation is in use
Incident response automation support tools ("jump kit") in use
Incident responders have the capability to escalate to full admin access in all cloud deployments
Automated remediation is available and in use for certain incidents and environments
Dev/cloud teams engaged in incident response for their deployments using ChatOps or other workflow automation
APP-03.4: Secrets management in use for applications
APP-03.4: Application secrets are stored in a secrets manager or vaulting solution.
Control automation: Either
AWS control specification: AWS Secrets Manager is in use
Azure control specification: Azure Key Vault is in use
GCP control specification: none
Third-party (CSPM/CNAPP) control specification: none
✕
Not Applicable - Not applicable
Level 1: Initial - Initial. Manually managing policies/procedures, mostly through console. Architectures tend to resemble traditional infrastructure (e.g., low use of serverless and high reliance on network security controls). IAM mostly ad hoc with little-to-no federation.
Level 2: Repeatable - Repeatable. Policy-/checklist-based and relies more on manual or simple tooling. High variability between projects; not coordinated across deployments. Initial use of infrastructure as code (Terraform/CloudFormation), but security not consistently engaged in design/review. Federation on some accounts, but limited use of MFA due to difficulties supporting teams (especially on the command line).
Level 3: Defined - Defined. Policies and central coordination in place. Some initial security automation still executed manually. Some third-party tooling (orchestration with other tools), Federation on most accounts with widespread MFA, but still gaps on consistency. Security starting to review and promote use of CloudFormation/Terraform. CSPM/CNAPP (CSP or third party) in use.
Level 4: Capable - Capable. Strong centralized security management with consistent enforcement. Automation and guardrails across multiple deployments. Expanding library. Big shift from manual management and execution to running security operations with centralized platforms with centralized management and reporting. Consistent use of federation and MFA, with some gaps supporting toolchains.
Level 5: Efficient - Efficient. All major activities centrally managed, covering all of the CSMM domains. Integrated into infrastructure-as-code (IaC) environment. Built into the stack with provisioning automation. Federation and MFA working consistently across toolchains (e.g., command-line support).
Not applicable
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
Level 4: Capable
Level 5: Efficient
Description
Control automation: Either
AWS control specification: AWS Secrets Manager is in use
Azure control specification: Azure Key Vault is in use
GCP control specification: none
Third-party (CSPM/CNAPP) control specification: none
✕