The Cloud Controls Matrix (CCM) is published by the Cloud Security Alliance (CSA), a nonprofit that develops cloud security best practice. Version 4 organizes 197 control objectives into 17 domains and, unlike general-purpose standards, assigns each control to the parties in a cloud relationship. Cloud service providers use it to answer customer due diligence at scale; cloud customers use it to know which controls remain theirs after they move a workload.
The 17 domains of CCM v4
Alongside the control specifications, the CCM v4 package includes implementation and auditing guidelines, mappings to other standards, and guidance on the Shared Security Responsibility Model (SSRM). CSA revises the matrix periodically, so check its site for the latest minor release and mapping updates before you baseline.
Shared responsibility is the point
A control like encryption key rotation might be owned entirely by an IaaS provider, shared with the customer, or owned entirely by the customer depending on the service model. CCM v4 makes that explicit. For a SaaS company sitting on a hyperscaler, this produces a layered picture: some controls you inherit from AWS, Azure, or GCP; some you operate yourself; and some you pass on to your own customers, who need to know what they must configure.
CAIQ and the STAR program
The Consensus Assessments Initiative Questionnaire (CAIQ) turns CCM controls into yes/no questions with space for explanation. It is the basis for CSA's STAR (Security, Trust, Assurance and Risk) program and its public registry, where providers publish their assurance status so customers can review it before sending their own questionnaire.
STAR assurance levels
A roadmap from questionnaire to Level 2
- Define the service boundary: which products, regions, and underlying cloud providers are in scope.
- Assign SSRM ownership for every control objective: provider-owned, shared, or customer-owned, and which upstream provider you inherit from.
- Gap assess against CCM using existing ISO 27001 or SOC 2 evidence as a starting point, then close gaps in domains those programs treat lightly, such as IPY and portions of DCS and UEM.
- Complete the CAIQ with specific, verifiable answers, and publish it for Level 1.
- Extend your audit: add CCM criteria to your next ISO 27001 certification audit for STAR Certification, or to your SOC 2 examination for STAR Attestation.
- Maintain it: revisit answers when architecture, sub-processors, or regions change.
Evidence that backs a CAIQ answer
Mistakes that weaken CCM assurance
- Answering "yes" on the CAIQ for controls that are actually inherited, without naming the provider or referencing its assurance report.
- Letting the published CAIQ go stale after a major architecture change.
- Treating CCM as a separate project when most of its evidence already exists in an ISO 27001 or SOC 2 program.
- Ignoring the customer-owned column, which leaves customers to discover their obligations during an incident.
How Asurvo helps
Asurvo includes CSA CCM v4 and cross-maps it to ISO 27001, SOC 2, and NIST frameworks, so evidence collected once counts wherever it applies. Direct-API integrations with AWS, Azure, GCP, and identity providers pull configuration evidence continuously. When a prospect sends a questionnaire, Third Party and the Trust Center help you answer from maintained evidence rather than rewriting answers each time. For the reuse approach in general, read evidence reuse.