Cloud Security Alliance Cloud Controls Matrix (CCM v4.1)

What it is

The Cloud Security Alliance (CSA) is a non-profit body that publishes research and assurance programmes for cloud computing. Its Cloud Controls Matrix (CCM) is a spreadsheet-based control framework designed specifically for cloud services. Each control has an identifier, a description, implementation and auditing guidelines, and an indication of how responsibility is typically shared between the cloud service provider and the customer. If the shared responsibility model is new to you, read cloud shared responsibility first.

CCM version 4 is organised into 17 domains, including audit and assurance; application and interface security; business continuity; change control; cryptography and key management; data security and privacy; datacentre security; governance; human resources; identity and access management; interoperability; infrastructure and virtualisation security; logging and monitoring; security incident management; supply chain management; threat and vulnerability management; and endpoint management.

Why it matters

Generic frameworks were written with on-premises IT in mind. In the cloud, the most important questions are often "who does this, the provider or us?" and "how can we verify it?". The CCM answers both. Its companion Consensus Assessments Initiative Questionnaire (CAIQ) turns controls into questions that providers answer and publish in the STAR Registry, which saves customers from sending their own questionnaires to every supplier. STAR Level 1 is a self-assessment; Level 2 involves an independent third-party audit, often combined with ISO/IEC 27001 certification or a SOC 2 report.

What changed in v4.1

• Release. CCM v4.1 and CAIQ v4.1 were released in January 2026, succeeding CCM v4.0.13.
• New controls. Eleven control specifications were added in the datacentre security, logging and monitoring, security incident management, supply chain management, and threat and vulnerability management domains. One identity and access management control was removed.
• Clearer language and updated implementation and auditing guidelines; CAIQ v4.1 contains 283 questions, and CCM-Lite and CAIQ-Lite were refreshed for lighter vendor assessments.
• Mappings to other standards are being updated with partners over time.
• STAR transition. The registry began accepting v4.1 submissions alongside v4.0 in March 2026. From December 2027 only v4.1 is accepted for Levels 1 and 2, and v4.0.x is withdrawn in January 2028.

The additions reflect where cloud incidents have actually happened. Logging and monitoring gaps make breaches hard to detect and investigate; supply chain dependencies mean a provider’s own suppliers can become the weak point; and threat and vulnerability management has to keep pace with frequent changes in cloud services. Organisations that already answered CAIQ v4.0 will find most of their evidence still applies, with targeted work needed for the new controls.

CSA has also extended the same approach to AI with the AI Controls Matrix (AICM), built on the CCM structure, for organisations that build or consume AI services.

How practitioners apply it

1. Supplier due diligence. Before adopting a SaaS product, check whether it has a STAR entry. Read its CAIQ answers and any Level 2 audit, and follow up on controls marked as customer responsibility.
2. Define your own responsibilities. For each CCM control in scope, record whether the provider, your team or both are responsible, and what evidence you hold.
3. Cloud architecture reviews. Use CCM domains as a checklist: identity, key management, logging, network segmentation, backup and incident response for each workload.
4. Map once, reuse often. Use the mappings to show how CCM evidence supports ISO/IEC 27001, NIST CSF or regulatory requirements.
5. If you are a provider, publish a CAIQ v4.1 self-assessment and plan your move from v4.0 before the December 2027 deadline.

Tip: A "yes" in a CAIQ is a claim, not proof. Ask for the audit report or certificate that covers the specific service and region you will use.

A short example shows the value of responsibility mapping. For a managed database service, encryption at rest is usually provided by the platform, but key management choices, who can read backups, network exposure of the endpoint and the database user accounts remain with the customer. Writing these splits down per control prevents the common failure where each side assumes the other has it covered, which is behind many cloud data exposures.

Limitations and open questions

• Self-assessment quality varies; Level 1 entries are not independently verified.
• Granularity. Controls describe what should be done, not cloud-provider-specific configuration, so engineers still need provider benchmarks.
• Shared responsibility shifts by service model (IaaS, PaaS, SaaS) and even by individual feature, which a single matrix can only approximate.
• Version transitions create temporary confusion when suppliers report against different versions.