The Cloud Controls Matrix,
explained plainly

The Cloud Controls Matrix (CCM) is a cybersecurity control framework built specifically for cloud computing, published and maintained by the Cloud Security Alliance (CSA). It is not a law you have to comply with, and it is not a certification you hold on its own — it is a structured set of security controls, written for the realities of cloud service delivery, that a provider implements and that a customer can assess against.

That framing matters. The CCM does not ask "is your product secure?" in the abstract. It lays out specific control objectives across the areas that matter for cloud (access, data, applications, infrastructure, supply chain, incident response and governance) and asks you to show, control by control, how you meet them and who owns each one. Because cloud responsibility is shared between provider and customer, the matrix is explicit about that split rather than leaving it implied.

The current version is CCM v4. If you read older material referring to a different domain count or control numbering, it is likely describing an earlier release — the framework is revised periodically as cloud practice moves, and v4 is the version to map against today.

The CCM organizes its controls into 17 domains, each covering a distinct area of cloud security. Across those domains sit roughly 197 control objectives — the individual things you are expected to be doing. The domains include identity and access management, data security and privacy lifecycle management, application and interface security, governance, risk and compliance, logging and monitoring, threat and vulnerability management, business continuity and operational resilience, and supply-chain and third-party management, among others.

Reading the matrix domain by domain is the fastest way to understand where your cloud security stands. Each control objective is concrete enough to answer plainly (you either do the thing, or you have a gap to close) which is exactly why customers find the CCM more useful than a generic policy statement. It turns "are you secure?" into a list of specific, checkable questions.

You are not expected to treat all 197 controls as equally relevant in every situation. The matrix is built to be applied to your service, with the shared-responsibility split making clear which controls fall to the provider and which to the customer. Working through the domains, deciding what applies, and recording your position on each is the core of using the CCM well.

The CCM ships alongside the CAIQ — the Consensus Assessment Initiative Questionnaire. The CAIQ is a set of yes/no questions, each mapped to a CCM control, designed for a cloud customer to evaluate a provider’s security posture without having to invent their own questionnaire from scratch. A provider completes the CAIQ once and can hand it to any customer who asks how they handle a given control.

This is, in practice, where the CCM earns its keep day to day. Every cloud and SaaS vendor knows the pain of bespoke security questionnaires arriving from each prospect, all asking the same things in different words. A completed CAIQ is the recognized answer to most of them: instead of re-answering a hundred custom forms, you point to your CAIQ, which already maps your controls to a format procurement teams recognize.

Keeping the CAIQ honest and current is the work. The questionnaire is only as good as the controls behind it, so the answers have to track what you actually do — not what you intended to do at the start of last year. A CAIQ that drifts out of date is worse than none, because it gets caught the moment a customer probes a control in depth.

The CCM is the control set; the CSA STAR program (Security, Trust, Assurance and Risk) is how you demonstrate it to the outside world. STAR runs on two levels of assurance, and choosing between them is one of the first real decisions a provider makes.

STAR Level 1 is a self-assessment. You complete a CAIQ (or a CCM-based assessment) describing how you meet each control and publish it to the public STAR Registry, where customers can find and read it. It is unverified by a third party — its value is transparency and speed: you are putting your security position on record, in a standard format, for anyone evaluating you to see.

STAR Level 2 is a third-party assessment, and it comes in two forms that build on standards you may already hold. STAR Certification is built on top of an ISO/IEC 27001 certification: an accredited assessor evaluates your cloud controls against the CCM in conjunction with your ISMS. STAR Attestation is built on a SOC 2 examination — it pairs the CCM with a SOC 2 report. Either way, Level 2 means an independent party has checked your cloud controls, which carries more weight with customers than a self-assessment alone.

The CCM is aimed squarely at cloud service providers (including SaaS vendors) who face security reviews from their customers. If you sell software that runs in the cloud to organizations that care how you handle their data, you will eventually be asked to evidence your cloud security, and the CCM is the most widely recognized, cloud-native way to do it.

It is rarely pursued for its own sake. Most teams adopt it because a customer’s procurement or security team asked for a CAIQ, or because a prospect checked the STAR Registry and did not find them. The CCM has become a common language for cloud security between buyers and sellers, which is precisely why a completed assessment unblocks deals that a vague security page does not.

The practical test is the same as for any security framework: are you losing or slowing deals because you cannot demonstrate, control by control, how you secure the cloud service you sell? If customer security reviews are a recurring tax on your sales cycle, a current CAIQ and a STAR listing are usually the most efficient answer — and most of the work is simply running cloud security well, written down in a format buyers already trust.

One of the CCM’s genuine strengths is that it ships with mappings to many other standards and frameworks — ISO/IEC 27001, SOC 2, NIST, PCI DSS and others. Each CCM control points to the corresponding requirements elsewhere, so the work you do for one framework is visible against the others rather than starting from zero each time.

This is why the CCM fits naturally alongside frameworks a cloud provider often already holds. If you are certified to ISO/IEC 27001, much of your ISMS evidence maps directly onto CCM controls — and STAR Certification is literally built on top of an ISO 27001 certification. If you have a SOC 2 report, STAR Attestation builds on that examination. The CCM does not replace these; it extends them into cloud-specific territory and gives customers a cloud-shaped lens on the same underlying controls.

The CCM also overlaps with ISO/IEC 27017, the code of practice for information security controls for cloud services. A team working toward cloud-specific assurance often touches all of these at once, and the value compounds when the same control evidence answers several of them rather than living in a separate binder per framework.

Because there is no "CCM certificate", teams sometimes ask how, concretely, they prove they meet the framework. The answer runs through the artifacts the CCM and STAR define: a completed CAIQ that records your position on each control, a published entry in the STAR Registry, and, if you go to Level 2, a third-party assessment riding on your ISO 27001 certification or SOC 2 report.

For many providers, the right first step is STAR Level 1: complete the CAIQ honestly, publish it, and use it to answer customer reviews. It is fast, it is transparent, and it puts a recognized document in front of buyers immediately. Level 2 is the move when customers want independent verification (typically larger or more regulated buyers) and it is most efficient when you already hold the ISO 27001 or SOC 2 foundation it builds on.

In all cases, what you are really demonstrating is a running set of controls, not a one-time document. The CAIQ and the assessment are snapshots of a system; their credibility depends on the controls behind them being real and current. Treating the CCM as a living record rather than a form you fill in once is what keeps it convincing when a customer looks closely.

The hardest part of the CCM is not completing it the first time — it is keeping it true afterwards. Your cloud service changes constantly: new subprocessors, new regions, a re-architected access model, a different logging stack. Every one of those can move your answer to a CCM control, and a CAIQ that no longer matches reality is a liability the moment a customer audits a claim.

This is where most teams quietly lose ground. The CAIQ gets assembled from spreadsheets and shared drives for one big customer review, then drifts as the product moves, so the next review means reconstructing it from scratch. The cost is paid again and again, in the time it takes to rebuild evidence that was never kept in one place and linked to the controls it supports.

Maintaining the CCM continuously, by keeping each control’s status, owner and evidence current as the service evolves, is what turns the framework from a recurring fire drill into a standing asset. A current CAIQ answers the next customer review in a click, and a maintained control set carries straight into a STAR Level 2 assessment when you decide to take that step.