Cloud Security Posture Review Template (CSA CCM v4.1)

Periodic cloud posture review: scope, shared responsibility, CSPM findings by CCM v4.1 domain, identity, exposure, data, logging, drift, risks, actions, trend

セキュリティエンジニアリングフルCSA CCM v4.1 (domains and IDs); CIS Benchmarks namedcloud posture review更新 2026/10/24

エディタで開く.mdをダウンロード

使い方: Use it when you review the configuration posture of AWS, Azure or Google Cloud estates each quarter. Fill scope, coverage gaps and the CCM domain table first, then rate risk and agree actions. The main pitfall is reporting raw finding counts instead of risk, exposure and trend.

プレビュー

Cloud Security Posture Review: [Organisation or cloud estate name], [review period]

Periodic review of the security posture of one or more cloud estates: scope and accounts, shared responsibility split, cloud security posture management (CSPM) findings grouped by the domains of the Cloud Security Alliance Cloud Controls Matrix (CCM) v4.1 (January 2026), identity, network exposure, data protection, logging coverage, guardrail drift, exceptions, risk rating, remediation plan and trend against the previous review. CCM domains are cited by name and identifier only; CIS Benchmarks are named as configuration baselines and not reproduced. This report records the state of an estate at a point in time; the approved patterns it checks against live in Cloud Security Reference Patterns (security/cloud-security-reference-patterns) and the landing zone design. Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company.

Document control

Field	Value
Document ID	[CSPR-YYYY-QN]
Version	[0.1]
Status	[Draft / In review / Approved / Superseded]
Owner	[@cloud-security-lead]
Approvers / reviewers	[@ciso], [@head-of-platform], [@cloud-account-owners]
Last updated	YYYY-MM-DD
Classification	Confidential: contains unremediated weaknesses
Review period	[YYYY-MM-DD to YYYY-MM-DD]
Data snapshot date	YYYY-MM-DD (CSPM export and inventory taken on this date)
Estates in scope	[Example: AWS organisation, Microsoft Azure tenant, Google Cloud organisation]
Baselines used	[Internal cloud baseline v[x]; CIS Benchmark for [provider] v[x] (licensed copy); provider security recommendations]
Control framework mapping	CSA CCM v4.1 (domains and control IDs only)
Previous review	[CSPR-YYYY-QN]
Next review	YYYY-MM-DD

Approvals

Role	Name	Decision	Date
Chief information security officer	[@name]	[Accepted / Changes requested]	YYYY-MM-DD
Head of platform or cloud engineering	[@name]	[Decision]	YYYY-MM-DD
Risk owner for exceptions (section 10)	[@name]	[Decision]	YYYY-MM-DD
Internal audit (observer)	[@name]	[Noted]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	Draft from CSPM export and inventory
0.2	YYYY-MM-DD	[@name]	Example: Account owners validated findings; false positives removed
1.0	YYYY-MM-DD	[@name]	Example: Accepted by CISO; remediation plan agreed

Executive summary
Scope and review method
Estate inventory and shared responsibility
Findings by CCM domain
Identity and access posture
Network exposure
Data protection and encryption
Logging and detection coverage
Guardrail drift and policy as code
Exceptions and risk acceptance
Risk rating
Remediation plan
Trend and metrics
Glossary and references

1. Executive summary

Overall posture: [Improving / Stable / Deteriorating] compared with [previous review ID].

Example (Corvid Commerce, Q3 2026): Posture improved for the second quarter in a row. The configuration pass rate rose from 92.5% to 93.6% and open critical findings fell from 7 to 4. Excluding 120 checks added by the CSPM vendor this quarter, the like-for-like pass rate is 93.9% (section 13). The legacy analytics account holds one of the four open critical findings (two internet-readable buckets with customer exports, CSPR-F-001) and a public database endpoint pending exception EXC-021. It needs a decision this cycle: either migrate the workload into the governed landing zone or accept the risk for 90 days with compensating controls. Logging coverage of the cloud control plane is complete, but data-plane logging for object storage covers only 71% of buckets holding confidential data.

Headline measure	Previous	Current	Target	Status
Configuration pass rate (section 13) Example	92.5%	93.6%	95.0%	Improving
Open critical findings Example	7	4	0	Off target
Open high findings Example	31	23	10 or fewer	Off target
Critical findings past SLA Example	3	1	0	Off target
Accounts outside the governed landing zone Example	5	3	0	Improving
Control-plane audit logging coverage Example	98%	100%	100%	On target

Top risks (detail in section 11):

Example: RISK-CSPR-001: public read access on two storage buckets with customer exports in the legacy analytics account.
Example: RISK-CSPR-002: long-lived access keys for 14 machine users, 3 of them (used by a third-party ETL tool) with administrative rights.
Example: RISK-CSPR-003: incomplete data-plane logging on confidential storage limits breach investigation.

Decisions requested:

ID	Decision	Options	Recommended	Decision owner
DEC-001 (Example)	Legacy analytics account	Migrate by YYYY-MM-DD, or accept risk 90 days	Migrate; interim block of public access	[@cto]
DEC-002 (Example)	Ban new static cloud keys for workloads	Policy now, or after workload identity rollout	Policy now, with 60-day exception path	[@ciso]

2. Scope and review method

2.1 Scope

Item	In scope	Out of scope (reason)
Cloud estates	[Example: AWS organisation `corvid-prod-org`, Azure tenant `corvid.example`, Google Cloud organisation `corvid.example`]	[Example: Partner-managed marketing site (covered by supplier assessment)]
Environments	[Production, staging, shared services, sandbox]	[Developer personal sandboxes with no data (spot-checked only)]
Regions	[All enabled regions]	[None]
Service types	IaaS, PaaS, managed Kubernetes, serverless, managed databases, object storage	SaaS applications (covered by SaaS posture review)
Identity planes	Cloud IAM, workforce identity provider federation into cloud	Customer identity (see CIAM design)

2.2 Method

Export the CSPM finding set and the cloud asset inventory on the snapshot date.
Reconcile the account list from the CSPM tool with the organisation or tenant hierarchy. Record every account the tool does not cover in section 3.3.
Map each failed check to one CCM v4.1 domain (primary) using the control ID mapping held in the CSPM tool or the internal baseline. Record unmapped checks as "Unmapped" and fix the mapping.
Remove confirmed false positives with a written reason; keep the count.
Validate the top findings with account owners in a 30-minute session per business unit.
Rate risk per theme using section 11 and agree actions in section 12.
Compare with the previous review (section 13).

2.3 Sources of evidence

Source	What it provides	Owner
CSPM platform [name]	Configuration findings against baselines, mapped to CCM	[@cloud-security]
Provider-native security hubs [names]	Provider recommendations and threat findings	[@cloud-security]
Cloud asset inventory	Accounts, resources, tags, owners	[@platform]
Identity provider and cloud IAM reports	Users, roles, keys, last use	[@iam-team]
Policy-as-code repository	Preventive guardrails and their versions	[@platform]
SIEM log source register	Log types ingested per account	[@soc]

2.4 Limitations

[Example: The CSPM tool evaluates configuration only; it does not observe runtime traffic or application flaws.]
[Example: Two Azure subscriptions were onboarded mid-period; their trend data starts at this review.]
[Example: CIS Benchmark checks rely on the CSPM vendor's licensed implementation; the benchmark text is not reproduced here.]

3. Estate inventory and shared responsibility

3.1 Estate summary

Estate	Accounts, subscriptions or projects	In CSPM	Resources evaluated	Owner tags complete
AWS Example	42 accounts	41	9,880	96%
Microsoft Azure Example	9 subscriptions	9	2,310	91%
Google Cloud Example	6 projects	5	1,140	88%
Total Example	57	55	13,330

3.2 Shared responsibility split

Record who operates each layer for the main service models. The provider's published shared responsibility model is the starting point; the customer column is what this review measures.

Layer	IaaS (virtual machines)	PaaS (managed database)	Serverless functions	Managed Kubernetes
Physical, hypervisor, provider network	Provider	Provider	Provider	Provider
Operating system patching	Customer	Provider	Provider	Provider (control plane), customer (node images unless auto-upgraded)
Network controls (security groups, firewall rules, private endpoints)	Customer	Customer	Customer	Customer
Identity, roles and keys	Customer	Customer	Customer	Customer (cluster RBAC and cloud IAM)
Data classification and encryption choices	Customer	Customer	Customer	Customer
Logging enablement and retention	Customer	Customer	Customer	Customer
Application code and dependencies	Customer	Customer	Customer	Customer

3.3 Coverage gaps

ID	Account or scope	Gap	Impact	Action
GAP-001 (Example)	AWS `corvid-legacy-analytics`	Not onboarded to CSPM; created before the landing zone	Findings unknown beyond manual sample	Onboard by YYYY-MM-DD (ACT-006)
GAP-002 (Example)	Google Cloud project `corvid-ml-sandbox`	CSPM service account lacks folder-level viewer role	No evaluation this period	Grant role, re-run

4. Findings by CCM domain

CCM v4.1 has 17 domains and 207 control specifications. The table lists every domain so that gaps in assessment are visible. Counts are open findings after false-positive removal. Domains marked "Other evidence" are not assessed by configuration scanning and are covered by the reviews named.

CCM domain ID	Domain name	Critical	High	Medium	Low	Total	Notes
A&A	Audit and Assurance						Other evidence: internal audit plan
AIS	Application and Interface Security	0	0	3	8	11	Example: API gateway TLS policy, WAF logging
BCR	Business Continuity Management and Operational Resilience						Other evidence: DR test reports
CCC	Change Control and Configuration Management	0	0	5	12	17	Example: resources created outside IaC
CEK	Cryptography, Encryption and Key Management	0	2	9	12	23	Example: key rotation disabled on 9 keys
DCS	Datacenter Security						Provider responsibility; provider attestation reports reviewed
DSP	Data Security and Privacy Lifecycle Management	1	4	14	22	41	Example: public buckets, untagged data stores
GRC	Governance, Risk and Compliance						Other evidence: exception register (section 10)
HRS	Human Resources						Out of scope for configuration review
IAM	Identity and Access Management	2	8	21	30	61	Example: static keys, unused admin roles
IPY	Interoperability and Portability						Out of scope for configuration review
IVS	Infrastructure and Virtualization Security	1	6	19	25	51	Example: open management ports, flat VPCs
LOG	Logging and Monitoring	0	2	11	18	31	Example: bucket access logs, flow logs
SEF	Security Incident Management, E-Discovery and Cloud Forensics						Other evidence: incident response exercise
STA	Supply Chain Management, Transparency and Accountability						Other evidence: supplier assessments
TVM	Threat and Vulnerability Management	0	1	6	14	21	Example: outdated node images, scanner agents missing
UEM	Universal Endpoint Management						Out of scope (endpoint programme)
Total		4	23	88	141	256	Example

Domain names follow the CCM v4 structure; confirm them against your licensed CCM v4.1 copy, which is the authoritative list.

4.1 Finding record format

Record each finding that is critical, high or part of a top risk in this format.

Field	Value
Finding ID	CSPR-F-[NNN]
CCM domain and control ID	[Example: DSP, DSP-[nn]]
Baseline check	[Internal check ID or CSPM rule ID]
Resource and account	[ARN, resource ID or URI], [account]
Severity (tool) and rated risk (section 11)	[Critical / High / Medium / Low]
Exposure	[Internet-facing / Internal / Isolated]
Data class	[Restricted / Confidential / Internal / Public]
First seen	YYYY-MM-DD
Owner	[@team]
Status	[Open / In remediation / Excepted / Closed]
Action ID	[ACT-NNN]

4.2 Top findings

Finding ID	Domain	Summary	Exposure	Data	Age (days)	Owner
CSPR-F-001 (Example)	DSP	Two object storage buckets allow anonymous read	Internet	Confidential (customer exports)	37	[@analytics]
CSPR-F-002 (Example)	IAM	Machine users of the third-party ETL tool with an administrative policy; oldest access key 400 days	Internal	Restricted	400	[@data-platform]
CSPR-F-003 (Example)	IAM	Entra ID Global Administrator account without phishing-resistant MFA in the Azure tenant	Internal	Restricted	5	[@azure-admins]
CSPR-F-004 (Example)	IVS	Remote administration port open to any address on a bastion replacement host	Internet	Internal	6	[@ops]

5. Identity and access posture

Target model: IAM Solution Design (security/iam-solution-design). Secret and key rules: Secrets Management Standard (security/secrets-management-standard).

Measure	Formula	Previous	Current	Target
Human cloud access through federation Example	federated human principals / all human principals	94%	98%	100%
Privileged roles with phishing-resistant MFA Example	privileged humans with FIDO2 or equivalent / privileged humans	89%	95%	100%
Static access keys for workloads Example	count of active long-lived keys attached to machine identities	22	14	0
Keys older than rotation period Example	keys older than the standard's period / active keys	41%	29%	0%
Unused privileged roles (90 days) Example	count	17	9	0
Standing administrator assignments Example	permanent admin assignments not using just-in-time elevation	31	18	5 or fewer (break-glass only)

Observations:

[Example: Just-in-time elevation is live in AWS and Azure; Google Cloud still relies on standing project owner grants in two projects.]
[Example: Cross-account trust policies allow assumption from three external accounts not listed in the supplier register.]

6. Network exposure

Exposure class	Count	With approved reason	Behind WAF or managed edge	Notes
Public load balancers and gateways Example	18	18	18	Expected
Virtual machines with public IP Example	7	4	0	3 without reason (ACT-004)
Management ports open to any source Example	2	0	0	Critical and high findings
Managed databases with public endpoint Example	1	0	0	Legacy analytics
Publicly readable object storage Example	5	3 (static web assets)	3	2 unexpected (CSPR-F-001)
Kubernetes API endpoints public Example	2	2 (IP allow-list)	n/a	Plan private endpoints; see Kubernetes Cluster Design (`ops/kubernetes-cluster-design`)

Record the external attack surface source (CSPM, external scanning, DNS inventory) and reconcile them: a public address found by external scanning but missing from the inventory is a high finding.

7. Data protection and encryption

Measure	Previous	Current	Target
Data stores with a data classification tag Example	81%	87%	100%
Confidential or restricted stores encrypted with customer-managed keys Example	72%	80%	100%
Customer-managed keys with rotation enabled Example	84%	90%	100%
Stores with public access block at account level Example	39 of 42 AWS accounts	41 of 42	All
Backups encrypted and in a separate account or vault Example	90%	93%	100%
TLS 1.2 or later enforced on public endpoints Example	97%	100%	100%

Key management practices are defined in PKI and Certificate Architecture (security/pki-certificate-architecture) and the secrets standard. Record deviations here only as findings.

8. Logging and detection coverage

Required sources and retention: Security Logging Standard (security/security-logging-standard).

Log source	Accounts required	Enabled	Centralised in SIEM	Immutable storage	Detection rules active
Control-plane audit logs Example	57	57	57	Yes	42
Identity provider sign-in logs Example	n/a	Yes	Yes	Yes	18
Network flow logs (production) Example	24	22	22	Yes	6
Object storage data access logs (confidential) Example	31 buckets	22	22	Yes	3
Managed Kubernetes audit logs Example	6 clusters	6	6	Yes	9
DNS query logs Example	24	15	15	No	2

Coverage formula: coverage = sources enabled and centralised / sources required. Example: data access logs on confidential buckets = 22 / 31 = 71%.

9. Guardrail drift and policy as code

Approved guardrails: Cloud Landing Zone Design (architecture/landing-zone-design), section 7 and section 9.

Guardrail ID	Guardrail	Type	Expected scope	Applied	Drift	Action
GR-001 (Example)	Deny disabling of control-plane audit logs	Preventive (organisation policy)	All accounts	57 / 57	None
GR-002 (Example)	Deny public object storage unless tagged `public-approved`	Preventive	All accounts except web asset account	54 / 56	2 accounts excluded without record	ACT-001
GR-003 (Example)	Deny creation of long-lived user access keys	Preventive	Workload accounts	30 / 42	Not applied in legacy OU	ACT-002
GR-004 (Example)	Require encryption with customer-managed keys for restricted data stores	Detective with auto-ticket	All	57 / 57	Rule version 1.3 deployed, 1.4 approved	ACT-007
GR-005 (Example)	Restrict regions to approved list	Preventive	All	57 / 57	None

Also record:

Resources created outside IaC (click-ops) in production: [Example: 63 resources, 0.8% of 7,900 production resources].
Policy-as-code test pass rate in the pipeline: [Example: 100% of 48 policy tests].
Accounts vended without the baseline in the period: [Example: 0].

10. Exceptions and risk acceptance

Exception ID	Finding or guardrail	Reason	Compensating controls	Residual risk	Approved by	Expiry
EXC-014 (Example)	GR-002 for `corvid-web-assets`	Static website assets must be public	Bucket holds only build output; write access limited to the release pipeline	Low	[@ciso]	YYYY-MM-DD
EXC-019 (Example)	CSPR-F-002: the 3 ETL machine-user keys (recorded in the secrets standard register as SMX-003)	Third-party ETL tool does not support workload identity	Administrative policy replaced by a policy scoped to the ETL buckets (ACT-002), IP condition, 30-day rotation, alert on use from a new IP	Medium	[@ciso]	YYYY-MM-DD (90 days)
EXC-021 (Example)	Public database endpoint in legacy analytics	Pending migration (DEC-001)	IP allow-list, TLS required, database audit logging on	High	Pending decision	n/a

Rules applied in this review:

Exceptions for critical findings require CISO approval and expire after at most 90 days (Example).
Exceptions for high findings require the head of platform and expire after at most 180 days (Example).
An exception with no compensating control is not granted; the finding stays open and escalates.
Expired exceptions this period: [Example: 2, both reopened as findings].

11. Risk rating

Rating method (Example): likelihood 1 to 5 multiplied by impact 1 to 5. Score 15 to 25 is High, 8 to 14 is Medium, 1 to 7 is Low. Use the scale in your enterprise risk methodology if one exists.

Risk ID	Theme	Linked findings	Likelihood	Impact	Score	Rating	Treatment
RISK-CSPR-001 (Example)	Public exposure of customer exports	CSPR-F-001, EXC-021	4	5	20	High	Mitigate (ACT-001, ACT-006)
RISK-CSPR-002 (Example)	Long-lived privileged machine credentials	CSPR-F-002, GR-003 drift	3	5	15	High	Mitigate (ACT-002)
RISK-CSPR-003 (Example)	Insufficient data-plane logging for investigations	Section 8	3	4	12	Medium	Mitigate (ACT-005)
RISK-CSPR-004 (Example)	Open management ports on internet-facing hosts	CSPR-F-004	3	4	12	Medium	Mitigate (ACT-004)
RISK-CSPR-005 (Example)	Standing administrator assignments in Google Cloud	Section 5	2	4	8	Medium	Mitigate (ACT-003)

Transfer High and Medium risks to the enterprise risk register (Risk Register Template, compliance/risk-register) with the same IDs.

12. Remediation plan

Action ID	Action	Reduces	Owner	Due	Verification	Status
ACT-001 (Example)	Remove public access from the two buckets; apply GR-002 to the two excluded accounts	RISK-CSPR-001	[@analytics-lead]	YYYY-MM-DD	CSPM check passes; external scan shows no anonymous read	In progress
ACT-002 (Example)	Apply GR-003 to legacy OU; replace 11 of the 14 workload keys with workload identity; scope the 3 ETL keys under EXC-019 to the ETL buckets	RISK-CSPR-002	[@platform-lead]	YYYY-MM-DD	Static workload key count is 3 or fewer, each covered by EXC-019; no key has an administrative policy	Planned
ACT-003 (Example)	Move Google Cloud owner grants to just-in-time elevation	RISK-CSPR-005	[@gcp-admin]	YYYY-MM-DD	IAM report shows no standing owner outside break-glass	Planned
ACT-004 (Example)	Close management ports; use session manager or identity-aware proxy	RISK-CSPR-004	[@ops-lead]	YYYY-MM-DD	No port 22 or 3389 open to any source	In progress
ACT-005 (Example)	Enable data access logging on the 9 remaining confidential buckets and ingest to SIEM	RISK-CSPR-003	[@soc-lead]	YYYY-MM-DD	Coverage 31 / 31	Planned
ACT-006 (Example)	Onboard legacy analytics account to CSPM; migrate per DEC-001	RISK-CSPR-001, GAP-001	[@analytics-lead]	YYYY-MM-DD	Account in CSPM and landing zone	Planned
ACT-007 (Example)	Deploy GR-004 rule version 1.4	Section 7	[@platform-lead]	YYYY-MM-DD	Policy version in all accounts	Planned

Remediation SLAs for findings follow Vulnerability Management Policy (security/vulnerability-management-policy) where the finding is a vulnerability, and the internal cloud baseline for configuration findings. Example configuration SLAs: critical 7 days, high 30 days, medium 90 days, low next quarterly cycle.

13. Trend and metrics

Metric	Formula	Q4 prev. year	Q1	Q2	Q3 (current)
Configuration pass rate Example	passed checks / evaluated checks	89.9%	91.2%	92.5% (16,380 / 17,700)	93.6% (17,236 / 18,420)
Open critical findings Example	count at snapshot	12	9	7	4
Open findings, all severities Example	count at snapshot	341	297	263	256
Mean time to remediate, critical (days) Example	sum of days open for closed criticals / closed criticals	19	14	11	8
SLA adherence, critical and high Example	closed within SLA / closed	71%	78%	83%	88%
Accounts with full guardrail set Example	compliant accounts / accounts in scope	84%	88%	91%	95%

Rule set changes in the period: [Example: the CSPM vendor added 120 checks for managed AI services in Q3, producing 640 evaluations of which 541 passed (84.5%). Excluding them, the Q3 like-for-like pass rate is (17,236 - 541) / (18,420 - 640) = 16,695 / 17,780 = 93.9%, so the wider rule set lowered the headline rate by about 0.3 points and the like-for-like gain over Q2 is 1.4 points (92.5% to 93.9%).]

13.1 Sign-off

Acceptance criteria for closing this review:

Every critical and high finding has an action or an approved exception.
Every High risk has a named treatment owner and appears in the risk register.
Coverage gaps (section 3.3) have onboarding actions.
Decisions in section 1 are recorded with the decision owner.

14. Glossary and references

14.1 Glossary

Term	Meaning
CSPM	Cloud security posture management: tooling that evaluates cloud configuration against rules and reports deviations
CCM	Cloud Controls Matrix: the CSA control framework for cloud computing, organised into domains and control IDs
Guardrail	A preventive or detective control applied centrally across accounts, usually as policy as code
Drift	A difference between the approved configuration or guardrail set and what is deployed
Shared responsibility	The split of security duties between the cloud provider and the customer for each service model
Pass rate	Passed checks divided by evaluated checks for a fixed rule set
Exception	A time-limited, approved deviation from a baseline with compensating controls
Landing zone	The governed multi-account foundation into which workloads are deployed

14.2 Related templates

Template	Use
Cloud Security Reference Patterns Template (AWS SRA, MCSB, CCM v4.1) (`security/cloud-security-reference-patterns`)	Approved patterns this review checks against
Cloud Landing Zone Design Template (AWS, Azure, Google Cloud) (`architecture/landing-zone-design`)	Guardrails, account structure and policy as code
IAM Solution Design Template (NIST SP 800-63-4, SSO, PAM) (`security/iam-solution-design`)	Target identity model
Secrets Management Standard (`security/secrets-management-standard`)	Static key and secret rules
Vulnerability Management Policy (`security/vulnerability-management-policy`)	Remediation SLAs for vulnerabilities
Security Logging Standard (`security/security-logging-standard`)	Required log sources and retention
Kubernetes Cluster Design (`ops/kubernetes-cluster-design`)	Cluster baseline and endpoint exposure
Zero Trust Architecture Plan Template (NIST SP 800-207, CISA ZTMM 2.0) (`security/zero-trust-architecture`)	Programme context for identity and network findings
Security Architecture Document Template (NIST SP 800-160, STRIDE) (`security/security-architecture`)	System-level design for systems with recurring findings
Penetration Test Report Template (PTES, OWASP WSTG) (`security/pentest-report`)	Exploitation testing, which this review does not perform

14.3 References

Cloud Security Alliance, Cloud Controls Matrix v4.1 and CAIQ v4.1, released 27 January 2026 (207 control specifications in 17 domains): https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4-1
Cloud Security Alliance, CCM and AICM licensing FAQ (terms for internal use, customisation and redistribution): https://cloudsecurityalliance.org/artifacts/ccm-aicm-licensing-faq
Center for Internet Security, CIS Benchmarks for cloud providers (obtain the current version from CIS): https://www.cisecurity.org/cis-benchmarks
NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, Release 5.2.0 (27 August 2025), for optional mapping of findings: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
The cloud provider's published shared responsibility model and security recommendations for each estate in scope.

Standard and licence note

Structure aligned with the Cloud Security Alliance Cloud Controls Matrix v4.1 (January 2026). CCM domain names and identifiers are cited for mapping only; no control specification text, implementation guideline or auditing guideline is reproduced. The CCM is free for internal use under CSA terms, and customisation or commercial reuse of its content requires a licence from CSA; the free download may not be modified or redistributed (see the CSA CCM licensing FAQ), so use your own licensed copy for control-level work. CIS Benchmarks are named only; obtain and apply them under the CIS terms. NIST SP 800-53 is a work of the United States Government. Check the current official versions before relying on this review, as updates may have been published. Cloud Security Alliance, CCM, CIS and CIS Benchmarks, and the cloud provider names are trademarks of their owners; this template is not affiliated with or endorsed by them. Original text written for this collection. Template licence: MIT.