CSA CCM & STAR

Introduction: The Cloud Controls Matrix and the STAR Programme

The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) is the de-facto reference framework for cloud-computing security. First released in 2010 and evolved through successive versions, CCM provides a structured catalogue of security controls tailored specifically to the realities of cloud service delivery, where responsibility for security is shared between a cloud service provider (CSP) and the customers who consume its services. The current major version, CCM v4, comprises 197 control objectives organised across 17 security domains, and it is accompanied by the Consensus Assessments Initiative Questionnaire (CAIQ), a companion set of yes/no questions that allow a provider to assert how each control is implemented.

The Security, Trust, Assurance and Risk (STAR) programme is the assurance layer that sits on top of CCM. STAR is a publicly accessible registry and certification scheme through which cloud providers document, and independent assessors validate, the security posture of a given cloud offering. STAR is structured in tiers of increasing rigour: Level 1 is a self-assessment based on the CAIQ, Level 2 is a third-party independent assessment (STAR Attestation, STAR Certification, or a C-STAR assessment for the Greater China market), and a continuous-monitoring tier delivers near-real-time assurance. Together, CCM and STAR give buyers a transparent, comparable way to evaluate the security of cloud services before and during procurement.

This guide is written for security and compliance leaders, cloud architects, GRC practitioners and auditors who need to plan, execute or assure a CCM/STAR programme. It walks through the framework structure, provides a master assessment checklist covering every domain, and sets out a phased implementation approach, scoring model, evidence expectations and mappings to adjacent standards. Throughout, the emphasis is on practical, auditor-grade specifics rather than abstract theory.

What is CSA CCM / STAR

CCM is a controls framework: a normalised, cloud-specific catalogue of control objectives that a provider or consumer can use to design, operate and audit a secure cloud environment. Unlike a general-purpose standard, CCM is explicitly built around cloud concepts, the shared responsibility model, the three service models (IaaS, PaaS, SaaS) and multi-tenancy. Each control objective is expressed as a concise statement of intent, and each is accompanied by implementation guidance, a shared-responsibility indicator and mappings to other authoritative standards.

Two companion artefacts make CCM operational. The CAIQ translates each control objective into one or more assessment questions that a provider answers, typically with a yes/no/NA response plus a narrative explanation and a statement of which party (provider, tenant, or shared) owns the control. The CCM implementation guidelines and the shared-responsibility model columns tell an organisation how the control is expected to be discharged across service models.

STAR is the assurance and transparency programme that consumes CCM/CAIQ output. A provider that completes a CAIQ can publish it to the public STAR Registry as a Level 1 self-assessment. To reach Level 2, an accredited third party validates the controls, either as a STAR Attestation (built on the SOC 2 framework and AICPA criteria), a STAR Certification (built on ISO/IEC 27001 with a CCM-based maturity scoring), or C-STAR for China. A continuous-monitoring tier extends assurance beyond a point-in-time snapshot. The result is a single, comparable, buyer-facing signal of cloud trustworthiness.

• CCM v4: 197 control objectives across 17 domains, each with implementation guidance and shared-responsibility guidance.
• CAIQ v4: the questionnaire form of CCM used to capture provider assertions and evidence pointers.
• STAR Level 1: publicly published self-assessment (CAIQ or CCM) on the CSA STAR Registry.
• STAR Level 2: independent third-party validation via Attestation (SOC 2), Certification (ISO 27001 + maturity), or C-STAR.
• STAR Continuous: ongoing, machine-readable assurance for near-real-time monitoring.
• CCM includes cross-mappings to ISO 27001/27002/27017/27018, NIST, PCI DSS, SOC 2, and other frameworks.

Who must comply

CCM/STAR is voluntary in the sense that no single law mandates it by name, yet it has become a contractual and procurement expectation across large swathes of the market. It applies to any organisation that builds, sells or heavily consumes cloud services, and it is increasingly requested in supplier due-diligence and RFP processes.

Structure of CSA CCM / STAR

CCM v4 is organised into 17 domains. Each domain has a two- or three-letter identifier and contains a set of numbered control objectives (for example, IAM-01 through IAM-16). The 17 domains collectively contain 197 controls. The table below lists every CCM v4 domain, its identifier and its scope. Control counts per domain vary; the identifiers shown are the canonical CCM v4 domain codes.

STAR layers assurance tiers on top of this structure. The relationship between CCM (the controls) and STAR (the assurance) is summarised below.

Master assessment checklist

This is the core of the guide. For every CCM domain it sets out what an assessor should verify and the typical evidence that substantiates the control. The intent is that a lead assessor can work domain by domain and leave no control area unexamined. Verify each item against the current CCM control text and the provider's CAIQ responses, and confirm both design and operating effectiveness where the STAR tier requires it.

A&A — Audit & Assurance

AIS — Application & Interface Security

BCR — Business Continuity Management & Operational Resilience

CCC — Change Control & Configuration Management

CEK — Cryptography, Encryption & Key Management

DCS — Datacenter Security

DSP — Data Security & Privacy Lifecycle Management

GRC — Governance, Risk & Compliance

HRS — Human Resources

IAM — Identity & Access Management

IPY — Interoperability & Portability

IVS — Infrastructure & Virtualization Security

LOG — Logging & Monitoring

SEF — Security Incident Management, E-Discovery & Cloud Forensics

STA — Supply Chain Management, Transparency & Accountability

TVM — Threat & Vulnerability Management

UEM — Universal Endpoint Management

Scoping

Scoping a CCM/STAR engagement means fixing precisely which cloud service(s), environments and control responsibilities are being assessed. Because CCM is cloud-specific and multi-tenant, scope decisions turn heavily on the service model and on the split of responsibility between provider and customer. Get scoping wrong and the assessment either over-claims (asserting controls the provider does not actually own) or under-claims (leaving material control areas unassessed).

• Service definition: name the exact cloud service, edition and deployment region(s) in scope; exclude out-of-scope offerings explicitly.
• Service model: determine IaaS, PaaS or SaaS, since this drives which controls fall to the provider versus the tenant.
• Shared-responsibility mapping: for each of the 17 domains, record whether the control is provider, customer, or shared, using the CCM shared-responsibility columns.
• Environment boundary: define production, DR and management planes in scope; note test/dev exclusions.
• Data types: identify personal, sensitive and regulated data processed, as this raises DSP, CEK and compliance expectations.
• Sub-service organisations: decide whether sub-processors are carved-in or carved-out (relevant to STA and STAR Attestation).
• Assessment tier: fix the target STAR level (1, 2 Attestation, 2 Certification, or Continuous), which sets the evidence rigour.
• Time period: for period-of-time assessments (SOC 2 Type II / Certification), define the observation window.

Implementation approach

A CCM/STAR programme is best delivered in phases. The phasing below assumes an organisation moving from no formal cloud-control baseline towards a validated STAR Level 2 listing, but each phase adds value independently and can be a stopping point.

Phase 1 — Mobilise and scope

• Activities: appoint a programme owner and steering group; confirm target STAR tier; define service/environment scope; obtain the current CCM/CAIQ.
• Deliverables: programme charter, scope statement, shared-responsibility matrix, stakeholder RACI, project plan.

Phase 2 — Gap assessment against CCM

• Activities: assess current controls against all 197 CCM objectives; complete a draft CAIQ; score maturity; identify gaps and quick wins.
• Deliverables: completed draft CAIQ, gap register with severity, maturity heat-map, prioritised remediation roadmap.

Phase 3 — Remediation and control build

• Activities: implement missing controls (policy, technical, process); harden configurations; stand up logging/monitoring; close SoD and IAM gaps.
• Deliverables: updated policies/standards, implemented technical controls, remediation evidence, revised CAIQ.

Phase 4 — Evidence, operate and internal validation

• Activities: operate controls to generate evidence over the required period; run internal audit/readiness review; test BCP, IR and access reviews.
• Deliverables: evidence library, internal audit report, control operating-effectiveness records, readiness sign-off.

Phase 5 — STAR submission or independent assessment

• Activities: publish CAIQ to the STAR Registry (Level 1) or engage an accredited assessor/CB for Attestation or Certification (Level 2).
• Deliverables: STAR Registry entry, assessor report, STAR Attestation/Certification, maturity score (Certification).

Phase 6 — Continuous improvement and monitoring

• Activities: track KPIs; remediate findings; refresh CAIQ on change; move towards STAR Continuous with automated control monitoring.
• Deliverables: KPI dashboard, updated CAIQ, surveillance/re-certification plan, continuous-monitoring feeds.

Maturity and scoring model

STAR Certification does not merely pass or fail a provider; it assigns a management-capability maturity score across the CCM control domains, derived from a Capability Maturity Model style assessment. The scoring reflects how well controls are defined, managed and continuously improved. The indicative model below describes the maturity levels an assessor evaluates. In addition, STAR overall awards a bronze/silver/gold-style rating based on the aggregate maturity achieved.

For STAR Attestation (SOC 2 based) there is no maturity star rating; instead the assessment concludes on whether controls are suitably designed (Type I) and operating effectively over the period (Type II), with any exceptions documented. For Level 1 self-assessment there is no score at all: the value is transparency, and buyers weigh the completeness and credibility of the published CAIQ.

Assessment and audit approach

Whether performing an internal readiness review or an accredited STAR assessment, the following ordered approach ensures consistent, defensible results.

1. Confirm scope, service model and shared-responsibility split; agree the target STAR tier and, if applicable, the observation period.
2. Obtain and review the current CCM/CAIQ and the provider's completed self-assessment as the assessment baseline.
3. Plan the assessment: build a test programme mapping each in-scope control to procedures (inquiry, inspection, observation, re-performance).
4. Perform design assessment: confirm each control is suitably designed to meet the CCM objective.
5. Perform operating-effectiveness testing (for period assessments): sample evidence across the window to confirm the control ran as designed.
6. Assess maturity (for Certification): score each domain against the capability maturity model.
7. Document exceptions, deficiencies and gaps with severity, root cause and impact.
8. Agree management responses and remediation plans with owners and timelines.
9. Draft the report (CAIQ, Attestation, or Certification) and perform quality review.
10. Publish to the STAR Registry / issue the certificate, then schedule surveillance, re-assessment or continuous monitoring.

Evidence request list

The following categorised evidence list supports a CCM/STAR assessment. It is illustrative rather than exhaustive; tailor it to the in-scope service and STAR tier.

• Governance and policy: information security policy suite, governance charter, risk methodology and register, exception register, management review minutes.
• Shared responsibility and scope: service descriptions, shared-responsibility matrix, architecture and data-flow diagrams, sub-processor list.
• Identity and access: IAM policy, MFA/PAM configuration, RBAC matrix, access review/recertification records, joiner-mover-leaver logs.
• Cryptography and data: encryption and key-management policy, KMS/HSM records, key rotation logs, data classification and retention schedules, disposal certificates.
• Change and configuration: change policy, CAB records, hardening baselines, drift/config-scan reports, CI/CD and pipeline access controls.
• Vulnerability and threat: scan reports, patch/remediation records, penetration-test reports and retests, anti-malware and threat-intel evidence.
• Logging and monitoring: logging policy, log source inventory, SIEM/alerting configuration, time-sync config, sample retained logs.
• Resilience: BCP/DR plans, BIA, RTO/RPO matrix, backup and restore-test logs, DR exercise reports.
• Incident and forensics: IR plan and playbooks, incident register, breach-notification records, post-incident reviews.
• Human resources: screening records, employment/NDA agreements, awareness-training records, offboarding evidence.
• Physical and datacentre: facility security policy, access logs, environmental monitoring, provider datacentre certifications.
• Supply chain: supplier register and risk tiering, contracts/SLAs/DPAs, provider audit reports and CAIQ reviews.
• Endpoint: endpoint inventory, UEM/MDM configuration, EDR/encryption coverage, endpoint DLP evidence.

Roles and responsibilities

KPIs to track

• Percentage of CCM controls implemented (design) and operating effectively.
• Average CCM domain maturity score and trend over time.
• Number and severity of open gaps/findings, and mean time to remediate.
• MFA and privileged-access coverage across in-scope identities.
• Vulnerability remediation SLA adherence (by severity).
• Patch compliance rate and mean time to patch critical vulnerabilities.
• Backup success rate and DR/BCP test pass rate against RTO/RPO.
• Mean time to detect and respond to security incidents.
• Access-review completion rate and orphaned-account count.
• Percentage of suppliers assessed and STAR/CAIQ coverage of key providers.
• CAIQ freshness (time since last refresh) and STAR listing currency.

Readiness checklist

• Programme scope, service model and shared-responsibility matrix are documented and signed off.
• Target STAR tier (Level 1, 2 Attestation, 2 Certification, or Continuous) is agreed.
• A completed, current CAIQ exists with narratives and evidence pointers for all 197 controls.
• All 17 CCM domains have been gap-assessed and material gaps remediated.
• Policies exist and are approved for governance, IAM, cryptography, change, logging, BCP, IR and supply chain.
• MFA, least-privilege and privileged access controls are enforced and reviewed.
• Encryption at rest and in transit is verified with a functioning key-management lifecycle.
• Logging, monitoring and alerting are operational with protected, time-synchronised logs.
• BCP/DR and incident-response plans have been tested within the required period.
• Vulnerability scanning, patching and penetration testing are current with SLAs met.
• An evidence library covers the observation period for operating-effectiveness testing.
• An internal readiness review has been completed and sign-off obtained before external assessment.

Common gaps

• Misassigning shared responsibility, especially over-claiming provider controls in IaaS/PaaS deployments.
• A CAIQ completed as a marketing exercise, with 'yes' answers unsupported by evidence.
• MFA gaps for privileged, service and break-glass accounts despite general MFA coverage.
• Incomplete key-management lifecycle: encryption enabled but no rotation, revocation or HSM protection.
• Logs collected but not protected, retained, time-synchronised or actively monitored.
• BCP/DR plans that exist on paper but have never been tested against stated RTO/RPO.
• Access reviews not performed at planned intervals, leaving orphaned and over-privileged accounts.
• Supply-chain and sub-processor risk unassessed, breaking the STA domain and STAR Attestation carve-in logic.
• Configuration drift with no detection, undermining CCC and hardening baselines.
• Data classification and retention undefined, weakening DSP and privacy obligations.
• Treating STAR Level 1 self-assessment as equivalent to independent Level 2 assurance.
• Stale CAIQ/STAR listings that no longer reflect the current environment after change.

CSA CCM / STAR mapped to other frameworks

A major strength of CCM is that each control is cross-mapped to other authoritative standards, allowing an organisation to assess once and evidence many. The table summarises the principal mappings and how CCM domains relate to adjacent frameworks. Always confirm the exact control-level mappings in the current official CCM spreadsheet.

How CyberSigma helps

Frequently asked questions

Need help with CSA CCM / STAR?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.