Cloud Security Alliance CCM and STAR Guide: Cloud Controls Matrix

Cloud customers and providers both need a common language for "which security controls exist, and who runs them", and a cloud provider's "Yes" to a questionnaire means little unless both sides know which version, which scope and which party owns each control. The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM), its Consensus Assessments Initiative Questionnaire (CAIQ) and the STAR assurance programme supply that language, and the AI Controls Matrix now extends it to AI services. This guide explains the current versions, the 17 control domains, the implementation and auditing guidelines, the shared security responsibility model, CAIQ and CAIQ-Lite, the STAR Registry and STAR levels, and how to use them as a buyer or a provider. It is for GRC, third-party risk, cloud security and audit teams. For the wider control set see the Cloud Security Guide, and for questionnaires in general the Security Questionnaires Guide.

Key takeaways

• CCM v4.1 is current. Released on 27 January 2026, it has 207 controls in 17 domains, up from 197 control objectives in v4.0, and ships combined with CAIQ v4.1 (283 questions). Always record which version a supplier answered.
• Ownership matters more than the answer. Every CCM control is expressed as provider-owned, customer-owned or shared. A provider's "Yes" on a customer-owned control tells you nothing about your own exposure.
• STAR levels are different kinds of evidence. Level 1 is a self-assessment updated annually; Level 2 is third-party audited, through ISO/IEC 27001 certification (three-year certificate) or SOC 2 attestation (one-year listing). Weight them accordingly.
• The STAR Registry is a starting point, not a verdict. Check the entry's date, version, level and scope against the service you actually buy.
• AI services now have their own matrix. The AI Controls Matrix (AICM), a superset of CCM v4.1 at version 1.1, and STAR for AI extend the same approach to model, orchestration and application providers.

What the Cloud Controls Matrix is, and which version to use

The Cloud Security Alliance CCM (usually shortened to CSA CCM) is a cybersecurity control framework for cloud computing, maintained by CSA as a standards body. It lists control specifications by domain, says which party in the cloud supply chain typically owns each one, and maps them to other frameworks. CSA states that the CCM helps organisations align with "industry-accepted security standards (including, but not limited to ISO, NIST, PCI, and DSS)". You do not need a licence to use the CCM for internal purposes; customising it or using it commercially needs a licence from CSA.

CCM v4.1 is described by CSA as "minor but meaningful updates": refined control language, revisions to existing control objectives and 11 new control specifications in the Datacenter Security, Logging and Monitoring, Security Incident Management, Supply Chain Management and Threat and Vulnerability Management domains. The v4.1 bundle includes mappings to NIST SP 800-171 Rev. 2, MITRE ATT&CK v17.1 and a reverse mapping from DORA, a CAIQ v4.0.3 to v4.1 change analysis, a continuous auditing metrics catalogue and machine-readable formats (JSON, YAML and OSCAL). If your supplier library holds v4.0 answers, use the change analysis to ask only about the controls that changed rather than re-sending the whole questionnaire.

The 17 CCM control domains

The CCM control domains have kept the same 17 codes from v4.0 to v4.1. Control IDs combine the domain code and a number (for example STA-04 in Supply Chain Management), which makes them easy to cite in contracts and findings. The evidence column below is what customers commonly ask for, not CCM text.

Implementation guidelines, auditing guidelines and the shared security responsibility model

Two companion documents turn the matrix into practice.

• Implementation guidelines: CSA describes them as "structured guidance on how to use the CCM", addressing who is responsible for doing what at the control specification level. CSA's 2026 introductory guidance is explicit that they are generic and non-prescriptive, not a how-to manual, so each organisation tailors them to its own risk programme. Version 4.1 implementation guidelines ship in the v4.1 bundle.
• Auditing guidelines: released for v4 in December 2021 and covering all 17 domains, they give auditors a baseline for assessing each control and extend Chapter 7 of CSA's cloud auditing knowledge guide. Auditors must adapt them to their own work programmes and the services in scope.

The CCM shared security responsibility model (SSRM) is the part most often misread. CSA's framing is that the cloud service provider (CSP) is responsible for security "of" the cloud and the cloud service customer (CSC) for securing data it stores or processes "in" the cloud. In the matrix, each control carries an SSRM ownership expression: CSP-owned, CSC-owned or shared, and control STA-04 requires that this ownership be defined. The 2026 introductory guidance refines "shared" into new "Shared Independent" and "Shared Dependent" expressions; read its definitions before mapping your own controls, because the CAIQ's "SSRM Control Ownership" column is only partly aligned with them.

Ownership varies by service model, so CSA advises providers to publish service-specific SSRM guidance. The table shows a typical split; your provider's own SSRM documentation is what counts.

CSA provides no specific questionnaire for customers: customers are expected to build their own compliance documentation from the customer responsibilities that each provider delineates. In practice that means a customer control register keyed to CCM IDs, listing every CSC-owned and shared control for each cloud service you use.

CAIQ v4, CAIQ v4.1 and CAIQ-Lite

The CAIQ questionnaire is built into the CCM and "offers a simple set of "yes/no" questions to assess cloud providers". CSA describes it as "an industry-accepted way to document what security controls exist in IaaS, PaaS, and SaaS services", and the current file, titled STAR Level 1 Security Questionnaire (CAIQ v4.1.0), is what providers use to submit to the STAR Registry.

• Reading a CAIQ as a buyer: check the version, the service and regions in scope, the SSRM ownership column and the free-text comments. A "Yes" with no explanation, or a "Yes" on a control that the ownership column assigns to the customer, needs a follow-up question, not a tick.
• Answering as a provider: answer per service, not per company; state the ownership and what the customer must configure; reference evidence (audit report section, policy, configuration) for each "Yes"; and keep the answer library mapped to CCM IDs so other questionnaires can be filled from it.
• CAIQ-Lite: the CCM-Lite is "a simplified version of the Cloud Controls Matrix (CCM) v4.1", and CAIQ-Lite is its questionnaire. CSA's page gives two sets of figures (96 controls and 138 questions in the body, 91 items and 124 questions in its summary), so confirm the count in the downloaded file. Use it for lower-risk suppliers or as a first-round screen; use the full CAIQ for suppliers that hold sensitive data or run critical services.

CSA also offers Valid-AI-ted, an optional enhancement to STAR Level 1 that uses AI to evaluate CAIQ v4 submissions. It scores the quality of answers; it is still a self-assessment, not an audit.

The STAR programme: Registry and levels

STAR stands for Security, Trust, Assurance, and Risk. The STAR Registry is "a publicly accessible registry" where providers publish their CAIQ self-assessments, certifications and attestations so customers can review them without a bespoke questionnaire.

CSA's 2021 publication calls the Continuous Auditing Certification "aka STAR Level 3" "the most rigorous assurance tier in the STAR program", but the current STAR pages list only Levels 1 and 2. Treat any supplier claim of STAR Continuous status as something to verify on the Registry. CSA's continuous auditing metrics catalogue in the v4.1 bundle remains useful for defining your own control metrics.

STAR certification and STAR attestation suit different audiences: ISO/IEC 27001-based certification is widely recognised internationally, while SOC 2-based attestation is familiar to North American buyers and gives a detailed auditor's report. See the ISO 27001 Certification Guide and the SOC 2 Guide.

AI Controls Matrix and STAR for AI

CSA released the AI Controls Matrix on 10 July 2025 with 243 control objectives in 18 domains, built on the CCM. Version 1.1, announced in July 2026, has 247 control objectives across 18 domains, is "a superset of CCM v4.1" with controls synchronised to it, includes a Model Security (MDS) domain and renames Infrastructure & Virtualization Security to Infrastructure Security. Each control is described along five pillars: control type, applicability and ownership, architectural relevance, lifecycle relevance and threat category.

• Roles: the v1.1 implementation guidelines are written by stakeholder role: Model Provider, Application Provider, Orchestrated Service Provider, AI Customer and Cloud Service Provider. This is the SSRM idea applied to the AI supply chain.
• Components: the controls spreadsheet, AI-CAIQ v1.1 with 320 questions, implementation and auditing guidelines, and mappings to ISO/IEC 42001, the NIST AI RMF and NIST AI 600-1, the EU AI Act, BSI AIC4 and AIUC-1.
• STAR for AI: Level 1 is an AI-CAIQ self-assessment on the Registry; since 20 November 2025, Level 2 combines a Valid-AI-ted AI-CAIQ with an ISO/IEC 42001 certification. See the ISO/IEC 42001 Guide.

For buyers of AI services, ask for the AI-CAIQ alongside the CAIQ: the CAIQ covers the cloud platform, the AI-CAIQ covers model and application controls such as training data handling and model security.

Using CCM and STAR as a buyer

Match the evidence you require to supplier risk, as you would in any third-party programme. See the Third-Party Risk Management Guide.

• Low risk (no sensitive data, no integration): a STAR Level 1 entry or CAIQ-Lite, checked for date and version.
• Medium risk: a full CAIQ v4.1 plus an ISO/IEC 27001 certificate or SOC 2 report, with follow-up on "No" answers and on shared controls.
• High risk (regulated data, privileged access, critical service): STAR Level 2 certification or attestation whose scope names the service you buy, plus targeted questions on IAM, CEK, LOG and SEF controls and contractual commitments that cite CCM IDs.
• Small organisations: rely on the Registry and existing reports instead of sending questionnaires; spend effort on configuring your customer-owned controls, which is where most of your risk sits.
• Large organisations: load CCM IDs into the GRC platform as the common control set for cloud suppliers, map internal standards to them once, and reuse supplier answers across business units.

Implementing CCM and STAR as a provider

1. Scope by service: list each cloud service and deployment model you sell; STAR entries and CAIQ answers should be per service.
2. Define the SSRM: for every CCM control, decide CSP-owned, CSC-owned or shared, and publish customer-facing guidance on what the customer must configure (STA-04).
3. Gap assessment: assess current controls against CCM v4.1 using the implementation guidelines; if you hold v4.0 answers, work from the change analysis.
4. Complete the CAIQ v4.1: answer with evidence references, have legal and security leadership approve, and pilot it with two or three customers before publishing.
5. Publish STAR Level 1: submit to the Registry, optionally with Valid-AI-ted scoring, and set an annual review date. If an answer proves inaccurate, correct and resubmit the entry rather than leaving it to expire.
6. Move to Level 2: extend your ISO/IEC 27001 audit (certification) or SOC 2 engagement (attestation) to include the CCM, using an approved firm and CSA's Code of Practice for implementing Level 2.
7. Add AI: if you provide AI services, complete the AI-CAIQ and plan STAR for AI with ISO/IEC 42001.
8. Maintain: re-assess after major service changes and new CCM releases, and track the expiry of each Level 2 listing.

CSA certification for people

"Cloud Security Alliance certification" can mean an organisational STAR credential or an individual certificate, and the two are often confused in procurement. CSA's individual credentials include the Certificate of Cloud Security Knowledge (CCSK), now at v5 with 12 domains and AI and generative AI replacing the old related technologies chapter, assessed by an open-book online exam of 60 multiple-choice questions with an 80% pass mark; the Certificate of Competence in Zero Trust (CCZT); and Trusted AI Safety Expert (TAISE). The Certificate of Cloud Auditing Knowledge (CCAK), which covered auditing against the CCM, has been unavailable on the ISACA website since 3 October 2025, and CSA has said it hopes to bring it back. An individual certificate says nothing about a provider's controls; ask for STAR or audit evidence instead.

Framework mapping

NIST SP 800-53 SA-9 requires that providers of external system services "comply with organizational security and privacy requirements" and that oversight, roles and responsibilities be defined and documented, which is the SSRM in control language. CSF 2.0 GV.SC-07 asks that supplier risks be "understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship". See the NIST SP 800-53 Guide.

Measurement

• Coverage: share of cloud suppliers with current CCM-based evidence (CAIQ, STAR entry or Level 2 listing) matched to their risk tier.
• Currency: share of supplier evidence on CCM v4.1, and Level 1 entries older than 12 months.
• Expiry: Level 2 certificates and attestations expiring within 90 days without renewal evidence.
• Customer-owned controls: share of CSC-owned and shared CCM controls for each critical service with a named internal owner and a tested configuration.
• Follow-up rate: "No" or unexplained "Yes" answers on IAM, CEK, LOG and SEF controls closed with evidence.

Common failure patterns

• Treating a provider's assurance as yours: customer-owned IAM controls fail regardless of the provider's STAR level. The Snowflake breach involved infostealer credentials used against customer accounts without MFA, a customer-side control.
• Ignoring customer-side configuration: the Capital One breach turned a customer firewall's cloud role credentials into data access; the provider's controls were not the gap.
• Accepting stale or mismatched evidence: a Level 1 entry from two years ago, a v4.0 CAIQ for a service redesigned since, or a Level 2 scope that covers a different product.
• Reading Yes/No without ownership: scoring CAIQ answers without the SSRM column inflates assurance on shared controls.
• Self-assessment presented as audit: Level 1 entries, including those scored by Valid-AI-ted, are still the provider's own claims.
• No non-human identity questions: CAIQ IAM answers often describe human access. Ask specifically how service accounts, API keys and workload identities that reach your data are issued, scoped and rotated. See the Cloud Workload Identity Guide.

Practitioner checklist

• Record the CCM and CAIQ version for every supplier answer and plan migration to v4.1.
• Download the CCM v4.1 bundle and load control IDs into your GRC tool as the cloud supplier control set.
• For each critical cloud service, list CSC-owned and shared controls and assign internal owners.
• Check STAR Registry entries for date, level, version and service scope before accepting them.
• Tier suppliers and require Level 1, full CAIQ or Level 2 evidence accordingly; use CAIQ-Lite only for low risk.
• Follow up every unexplained "Yes" and every "No" on IAM, CEK, LOG and SEF controls.
• Track Level 2 expiry dates (one year for attestation listings, three years for certificates).
• Request the AI-CAIQ from AI service providers and check STAR for AI status.
• As a provider, publish per-service SSRM guidance and review your STAR entry annually.

Standards and references

• Cloud Security Alliance: Cloud Controls Matrix (CCM)
• Cloud Security Alliance: Cloud Controls Matrix v4.1
• Cloud Security Alliance: CCM-Lite and CAIQ-Lite
• Cloud Security Alliance: STAR Levels
• Cloud Security Alliance: Introductory Guidance to the CCM
• Cloud Security Alliance: AI Controls Matrix v1.1
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls (SA-9, SR-6)

Related NHI Mgmt Group resources: Cloud Security Guide · Security Questionnaires Guide · Third-Party Risk Management Guide · Vendor Security Assessment Template