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

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

Approvals

Revision history

Contents

1. Executive summary
2. Scope and review method
3. Estate inventory and shared responsibility
4. Findings by CCM domain
5. Identity and access posture
6. Network exposure
7. Data protection and encryption
8. Logging and detection coverage
9. Guardrail drift and policy as code
10. Exceptions and risk acceptance
11. Risk rating
12. Remediation plan
13. Trend and metrics
14. 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.

Top risks (detail in section 11):

1. Example: RISK-CSPR-001: public read access on two storage buckets with customer exports in the legacy analytics account.
2. 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.
3. Example: RISK-CSPR-003: incomplete data-plane logging on confidential storage limits breach investigation.

Decisions requested:

2. Scope and review method

2.1 Scope

2.2 Method

1. Export the CSPM finding set and the cloud asset inventory on the snapshot date.
2. 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.
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.
4. Remove confirmed false positives with a written reason; keep the count.
5. Validate the top findings with account owners in a 30-minute session per business unit.
6. Rate risk per theme using section 11 and agree actions in section 12.
7. Compare with the previous review (section 13).

2.3 Sources of evidence

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

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.

3.3 Coverage gaps

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.

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.

4.2 Top findings

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).

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

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

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).

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.

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

Rules applied in this review:

1. Exceptions for critical findings require CISO approval and expire after at most 90 days (Example).
2. Exceptions for high findings require the head of platform and expire after at most 180 days (Example).
3. An exception with no compensating control is not granted; the finding stays open and escalates.
4. 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.

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

12. Remediation plan

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

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

14.2 Related templates

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.