CSA Cloud Controls Matrix (CCM): CSA Cloud Controls Matrix – Tutorial (about 60 minutes)

The Cloud Controls Matrix (CCM) is a free catalogue of security and privacy controls written specifically for cloud computing by the Cloud Security Alliance (CSA), a non-profit industry organisation. Cloud providers use it to describe and prove how they protect their services, and cloud customers use it to decide what to ask a provider, what they must still do themselves, and how to check that the split is working. After this tutorial you will be able to explain how the CCM is organised, read a control and its ownership information, use the companion questionnaire (CAIQ), explain the STAR assurance levels and apply the matrix to a realistic cloud supply chain.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is CCM version 4.1, published by the Cloud Security Alliance in January 2026 together with the Consensus Assessments Initiative Questionnaire (CAIQ) version 4.1. It succeeds CCM v4.0.13, the last maintenance release of version 4.0, which first appeared in January 2021. Version 4.1 contains 207 control specifications in 17 domains (version 4.0 had 197); it adds 11 new controls, removes one identity and access management control and revises the wording of many others. CAIQ v4.1 has 283 questions. CSA has published a transition plan: the STAR Registry accepts both v4.0 and v4.1 submissions during a transition period, only v4.1 submissions are accepted from December 2027, and the v4.0.x matrix and questionnaire are to be withdrawn in January 2028. No version 5 has been announced. The CCM is a framework published by an industry body, not a formal ISO or national standard. Verified 2026-10-29.

Who this is for: cloud and platform engineers, security architects, GRC (governance, risk and compliance) analysts, internal and external auditors, vendor and third-party risk managers, procurement staff, and product or engineering managers at software-as-a-service companies who keep receiving long security questionnaires from customers. It is equally useful on both sides of the cloud relationship: for people who buy cloud services and for people who build and sell them.

Prerequisites: none. Some familiarity with cloud services (virtual machines, managed databases, web applications delivered as a service) helps, but every cloud and security term used here is explained when it first appears.

By the end of this tutorial:

You will be able to explain why the CCM exists, who maintains it and which problems of cloud assurance it was designed to solve.
You will be able to describe the components of CCM v4.1 — the 17 domains, the control specifications, the CAIQ, the implementation and auditing guidelines and the mappings — and how they fit together.
You will be able to read a CCM control row, including its ownership by service model and its architectural and organisational relevance.
You will be able to apply the Shared Security Responsibility Model (SSRM) to divide each control between a provider and a customer.
You will be able to explain how the CCM is assessed through STAR Level 1 self-assessment and STAR Level 2 third-party certification or attestation, and what a STAR Registry listing does and does not prove.
You will be able to plan a practical CCM programme for an organisation that is both a cloud customer and a cloud provider.
You will be able to relate the CCM to ISO/IEC 27001, ISO/IEC 27017, SOC 2, NIST SP 800-53 and the CIS Controls.

Lesson 1 – Origins, purpose and scope

The problem the CCM solves

When an organisation runs its own data centre, it controls everything: the building, the servers, the network, the operating systems, the applications and the people who operate them. Its security team can walk into the server room, read every configuration and interview every administrator. When the same organisation moves workloads to the cloud, much of that stack is now operated by someone else — a cloud service provider — and the customer can no longer inspect it directly. Two questions become urgent. First, what is the provider doing to protect my data and workloads? Second, what do I still have to do myself?

In the early years of cloud adoption, every customer answered these questions in its own way. Banks, hospitals and government agencies each wrote their own security questionnaires, often hundreds of questions long, with different wording for the same topic. Providers spent enormous effort answering slightly different versions of the same questions, and customers received answers they could not easily compare. There was no shared vocabulary for which security tasks belonged to the provider and which to the customer, so gaps appeared: each side assumed the other was handling backups, logging or key management.

The Cloud Security Alliance was formed by practitioners and companies at the end of the 2000s to promote good security practice for cloud computing. Its approach is consensus-based: volunteers from providers, customers, auditors and consultancies draft documents, which are then opened for public peer review before release. The Cloud Controls Matrix first appeared in 2010 as one of the alliance's earliest research outputs. Its aim was to give the whole industry a single, cloud-specific list of control objectives that providers could implement and customers could ask about, with cross-references to the standards and regulations people already had to follow.

How it has evolved

The matrix grew through several versions during the 2010s. Version 3.0.1, used for most of that decade, had 133 control objectives in 16 domains. Version 4.0, released in January 2021, was a major redesign: it introduced a new Logging and Monitoring domain, greatly expanded the privacy content, reorganised many domains and added ownership information based on the Shared Security Responsibility Model. Version 4.0 was then refined through a series of small maintenance releases up to 4.0.13. Version 4.1, released in January 2026 after an open peer review in mid-2025, keeps the 17-domain structure, adds new controls on topics such as API security, data centre resilience, sanitising sensitive data in audit logs, incident record management, supply chain risk policy, transparency about the components of a cloud service, and threat modelling, and tightens the wording of existing controls to make them easier to audit.

Purpose and scope

The CCM has three closely linked purposes:

A control framework. It lists what a well-run cloud service, and a well-run cloud customer, should have in place across governance, technology, people and suppliers.
A common language for transparency. Through its questionnaire and the public STAR Registry, it lets providers describe their controls once, in a standard format, instead of answering every customer separately.
A bridge to other obligations. Its mappings show how each control relates to other standards and regulations, so one piece of work can support several compliance needs.

Its scope is cloud computing in all its service models: infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS). It addresses both parties in the relationship. A common misunderstanding is that the CCM is only for providers. In fact, many controls are partly or wholly the customer's job — for example, managing who in the customer organisation can sign in to a SaaS application, or classifying the data the customer uploads. The CCM is also vendor-neutral: it names no products and does not prescribe one technology over another.

The CCM is a framework, not a law, and it is not a formal standard from ISO or a national standards body. Nobody is legally obliged to use it unless a contract, a customer or a regulator asks for it. Its authority comes from broad industry adoption and from its role in the CSA STAR assurance programme, which you will meet in Lesson 5.

Lesson 2 – Key concepts and vocabulary

The CCM uses a small set of terms consistently. Learn these first; the rest of the tutorial builds on them.

Cloud service provider (CSP) – the organisation that operates a cloud service and offers it to others, such as a public IaaS platform or a SaaS application vendor.
Cloud service customer (CSC) – the organisation that uses a cloud service. A company can be a CSC of one service and a CSP of another at the same time.
Service model – the type of cloud service: IaaS (the provider supplies compute, storage and network; the customer manages operating systems and above), PaaS (the provider also manages the runtime platform; the customer manages applications and data) or SaaS (the provider runs the whole application; the customer manages its users, configuration and data).
Control domain – one of the 17 thematic groups of the CCM, each identified by a short code such as IAM for Identity and Access Management.
Control specification – the requirement statement of an individual control, describing what should be achieved, identified by the domain code and a number (for example, a control in the Logging and Monitoring domain has an ID beginning with LOG-).
Shared Security Responsibility Model (SSRM) – the principle that security in the cloud is divided between provider and customer, and the CSA guidance that records, control by control, how that division typically works for each service model.
Control ownership – the SSRM label for who is responsible for implementing a control: CSP-owned, CSC-owned or shared between them.
Shared (dependent) and shared (independent) – two forms of shared ownership. Dependent means one party's part relies on a hand-over from the other; independent means each party does its own part with no hand-over.
CAIQ – the Consensus Assessments Initiative Questionnaire: a set of yes/no questions derived from the CCM, which providers answer to describe their implementation. Version 4.1 has 283 questions.
Implementation guidelines – CSA guidance explaining how each control can be implemented, including the reasoning behind its typical ownership and what each party should do.
Auditing guidelines – guidance for auditors on what to examine when testing whether a control is designed and operating as intended.
Mapping – a cross-reference between a CCM control and the related requirement in another framework, with a gap rating that shows how well they match.
STAR – the CSA Security, Trust, Assurance and Risk programme, which uses the CCM and CAIQ as the basis for self-assessments and third-party audits of cloud services.
STAR Registry – CSA's free public website listing the self-assessments, certifications and attestations of cloud services.
Compensating control – a measure a customer puts in place to reduce a risk that the provider's controls do not cover, or that a mapped standard does not fully address.

Why ownership is the heart of the CCM

Many control catalogues tell you what to do. The distinctive feature of the CCM is that it also helps decide who does it in a cloud arrangement. Consider encryption of stored data in an IaaS platform. The provider may offer a key management service and encrypt disks by default, but the customer decides whether to use customer-managed keys, who may use them and when they are rotated. Neither side can deliver the outcome alone. If ownership is never discussed, each side may believe the other has it covered. The SSRM forces the conversation to happen control by control, before an incident reveals the gap.

Ownership also depends on the service model. The same control can be largely the customer's job in IaaS and largely the provider's job in SaaS. Patching an operating system is a good example: in IaaS the customer patches the virtual machines it builds, while in SaaS the customer never sees an operating system and the provider is responsible. This is why the CCM records typical ownership separately for IaaS, PaaS and SaaS.

Lesson 3 – Structure of the matrix

The CCM is published as a spreadsheet, with a machine-readable bundle (JSON, YAML and OSCAL, the Open Security Controls Assessment Language) for tools. The download is more than a single list: it is a package of related components. Figure 1 shows how they fit together.

Figure 1 – The control specifications sit at the centre of the CCM package; every other component explains, tests, maps or questions them.

The 17 domains

Every control belongs to one domain. The domain names below are given in summary form; each covers a familiar area of security management, adapted for cloud services.

Code	Domain	What it covers, in brief
`A&A`	Audit and Assurance	Planning and running independent audits and assessments, and acting on their results.
`AIS`	Application and Interface Security	Secure development, testing and deployment of applications and APIs.
`BCR`	Business Continuity Management and Operational Resilience	Continuity planning, backups, redundancy and recovery testing.
`CCC`	Change Control and Configuration Management	Approving, testing and tracking changes and keeping secure baselines.
`CEK`	Cryptography, Encryption and Key Management	Use of encryption and the full lifecycle of cryptographic keys.
`DCS`	Datacenter Security	Physical sites, equipment, secure disposal and environmental protection.
`DSP`	Data Security and Privacy Lifecycle Management	Classification, protection, retention and deletion of data, and privacy obligations.
`GRC`	Governance, Risk and Compliance	Security governance, risk management, policies and legal or regulatory requirements.
`HRS`	Human Resources	Screening, terms of employment, training and leaving procedures.
`IAM`	Identity and Access Management	Accounts, authentication, privileged access and access reviews.
`IPY`	Interoperability and Portability	Ability to move data and workloads between services and to exit a provider.
`IVS`	Infrastructure and Virtualization Security	Securing hypervisors, networks, segmentation and capacity.
`LOG`	Logging and Monitoring	Collecting, protecting, reviewing and alerting on logs.
`SEF`	Security Incident Management, E-Discovery and Cloud Forensics	Incident response, notification and forensic evidence handling.
`STA`	Supply Chain Management, Transparency and Accountability	Managing suppliers, the SSRM itself and transparency towards customers.
`TVM`	Threat and Vulnerability Management	Finding, prioritising and fixing vulnerabilities, and understanding threats.
`UEM`	Universal Endpoint Management	Securing laptops, phones and other devices that access cloud resources.

A useful pattern to notice: in each domain, the first control is about having documented, approved and regularly reviewed policies and procedures for that area. The later controls then cover specific technical and operational outcomes. This makes the CCM easy to use for both a governance review (are the policies in place?) and a technical review (are the outcomes achieved?).

Anatomy of a control row

Each control in the main worksheet is one row with several columns of information. Reading a row correctly is the most important practical skill in this course. Figure 2 shows the parts.

Figure 2 – A control row tells you what is required, who typically owns it in each service model, which technical layers it touches and which teams should care.

Domain, ID and title identify the control and let you cite it consistently, for example in an audit finding or a risk register.
The specification states the expected outcome in one or a few sentences. It says what must be achieved, not which product to buy.
Typical control applicability and ownership gives a starting view of who owns the control for IaaS, PaaS and SaaS. CSA describes this as a high-level simplification: the real split must follow the contract and the actual service.
Architectural relevance uses true/false flags to show which technical layers the control applies to (physical, network, compute, storage, application, data). This helps engineers find the controls that matter for, say, a storage service.
Organisational relevance uses true/false flags to show which functions are usually involved, such as cybersecurity, internal audit, IT operations or legal and privacy. This helps a programme manager route controls to the right owners inside the company.

The CAIQ

The Consensus Assessments Initiative Questionnaire turns each control into one or more closed questions. A provider answers each question with Yes, No or NA (not applicable), records the SSRM ownership for that control, and may describe in its own words how it implements the control and what the customer must do in return. Those two free-text descriptions are optional in the format but are what make a CAIQ genuinely useful to a customer: a bare "Yes" tells you little, while "Yes — customer data is encrypted at rest with provider-managed keys by default; customers may supply their own keys through the key service and are responsible for rotating them" tells you exactly where your duties start.

The CCM spreadsheet includes a reference copy of the CAIQ for reading. The version a provider fills in and submits to the STAR Registry is the separate CAIQ v4.1 file, which CSA calls the STAR Level 1 Security Questionnaire. Shorter "Lite" versions of the CCM and CAIQ exist for organisations that need a lighter, entry-level assessment — useful for smaller providers or lower-risk services, but not a replacement for the full questionnaire where a customer needs depth.

Implementation and auditing guidelines

The implementation guidelines are organised control by control. For each control they explain the reasoning behind the typical ownership and give suggestions for what the provider and the customer should each do. They are deliberately technology-neutral and not prescriptive: CSA expects organisations to adapt them to their own risk assessment and services. The auditing guidelines give assessors a baseline of what to look at — documents, configurations, records and interviews — when testing a control. Alongside these, CSA publishes material on security metrics and a continuous auditing metrics catalogue for organisations that want to measure controls automatically and frequently rather than once a year.

Mappings and gap ratings

The mapping worksheets cross-reference CCM controls to other frameworks. Over the life of version 4, CSA has published mappings to frameworks such as ISO/IEC 27001, 27002, 27017 and 27018, the CIS Controls, NIST SP 800-53 and the AICPA Trust Services Criteria used in SOC 2 reports; the v4.1 release adds mappings to NIST SP 800-171, MITRE ATT&CK and a reverse mapping from the EU Digital Operational Resilience Act (DORA). For each mapping, a gap level shows whether the other framework fully covers the CCM control (no gap), covers part of it (partial gap) or does not cover it at all (full gap). Where there is a gap, an addendum suggests what extra work would close it. The practical value is large: an organisation already certified to ISO/IEC 27001 can see exactly which CCM controls its existing programme already supports and where cloud-specific work is still needed.

Lesson 4 – How it works in practice

Using the CCM is not a one-off form-filling exercise. It is a cycle that starts with understanding the cloud services in scope and ends with continuous checking that the agreed responsibilities are being met. The steps differ slightly depending on whether you are a customer, a provider or both, but the backbone is the same. Figure 3 shows a typical cycle from the customer's point of view.

Figure 3 – A customer's CCM cycle: know your services, tailor the controls, check the provider, agree the split, do your part, cover gaps and keep checking.

Step by step for a cloud customer

Inventory cloud services and data. List every cloud service in use, including small SaaS tools bought by individual departments. For each, note what data it holds and which business processes depend on it. Shadow IT — services adopted without the security team's knowledge — is one of the main sources of uncontrolled risk.
Record the service model and criticality. The service model drives ownership, and criticality drives effort. A SaaS tool holding public marketing content does not need the same depth of review as a PaaS database holding payment data.
Tailor the control set. Start from the full CCM, then mark which controls are relevant for each service and level of risk. Use the architectural relevance flags to filter quickly: a pure SaaS collaboration tool, for instance, does not need the customer to assess hypervisor isolation in detail, while its identity, data and logging controls matter greatly.
Review provider evidence. Check whether the provider is listed in the STAR Registry, read its CAIQ answers and, where available, its third-party certificate or attestation report. Compare the provider's stated ownership with your own understanding.
Agree the split. Put the responsibilities into the contract or service agreement, especially for shared controls: incident notification times, log access, encryption key options, data location, backup and restore, and exit arrangements.
Implement customer-owned controls. Configure the service securely, manage your own users and roles, classify and protect your data, and integrate the provider's logs with your monitoring.
Add compensating controls. Where the provider does not offer something you need — for example, detailed audit logs on a lower subscription tier — decide whether to upgrade, add your own measure, accept the risk formally or choose another service.
Monitor and reassess. Track the provider's certifications and registry entries over time, review changes to the service, and repeat the review at a frequency that matches the risk.

Step by step for a cloud provider

A provider uses the same matrix from the other side. It typically begins by deciding which of its services are in scope, then performs a gap assessment of its security programme against all 207 controls. It assigns an internal owner to each control (the organisational relevance flags help), records its SSRM position for each control and service model, and writes clear implementation descriptions and customer responsibilities. It then completes the CAIQ, reviews the answers with legal and product teams to make sure they are accurate and not over-promising, and publishes the result to the STAR Registry. Many providers follow this with a third-party audit (Lesson 5). Finally, it keeps the answers current: a CAIQ that describes last year's architecture is a liability, because customers rely on it.

Making sense of shared responsibility

Figure 4 shows a simple way to decide the ownership label for any control in your own environment. The typical ownership in the CCM is only a starting point; the decision must reflect your actual service and contract.

Figure 4 – Deciding SSRM ownership: whoever must act owns the control, and shared controls need the interface between the parties written down.

Some practical examples help make the categories concrete:

Physical security of the data centre is normally provider-owned in every service model. The customer cannot implement it, but remains accountable for choosing a provider that does it well and for checking the evidence.
Training of the customer's own staff is customer-owned: no provider can run the customer's awareness programme.
Security incident handling is often shared and dependent: the provider must detect and notify incidents in its part of the stack, and the customer's response depends on receiving that notification promptly and in a usable form.
Classification of data can be shared and independent in IaaS: the provider classifies its own operational data, the customer classifies the data it stores, and neither needs anything from the other to do it.

Remember also that responsibility and accountability are different ideas. A customer can hand the work of a control to a provider, but it cannot hand over its accountability to regulators, its own customers or its board for the protection of its data. This is why even fully provider-owned controls still create a customer task: verify.

The supply chain view

Modern cloud services are layered. A SaaS company typically runs on a PaaS or IaaS platform, uses third-party services for email, monitoring or payments, and may outsource its support. Each of these suppliers is a CSP to the SaaS company, which in turn is a CSP to its own customers. The CCM handles this by allowing ownership to be traced through the chain: when a SaaS provider says "the data centre controls are covered", the honest answer is usually "covered by our IaaS provider, whose STAR listing and audit report we review". The Supply Chain Management, Transparency and Accountability (STA) domain is where these duties live, including documenting the SSRM, managing supplier risk and, in v4.1, giving customers more transparency about the components that make up a service.

Lesson 5 – Assessment, certification and compliance

The CCM itself does not certify anyone. Assessment against it happens mainly through the CSA STAR programme, with additional use by customers and auditors in their own reviews. It is important to understand exactly what each form of assurance means, because organisations frequently overstate or misread them.

Figure 5 – STAR assurance builds on the CAIQ: Level 1 is the provider's own statement, Level 2 adds an independent audit through one of three routes.

STAR Level 1 – self-assessment

At Level 1, the provider completes the CAIQ and submits it to the STAR Registry, where anyone can download it. CSA now also offers an optional automated validation service, Valid-AI-ted, which uses AI to check a submitted CAIQ for completeness and quality, returns a score with improvement suggestions and adds a badge to the listing when it passes. Level 1 is valuable because it is public, standardised and comparable, and because publishing it reduces the number of custom questionnaires the provider must answer. Its limitation is equally important: it is the provider's own statement. No independent auditor has tested whether the answers are true. A customer should treat a Level 1 listing as a well-organised claim, to be weighed together with other evidence.

STAR Level 2 – third-party audit

At Level 2, an independent assessor tests the provider's controls, and the result is published in the registry together with the CAIQ. There are three routes, chosen mainly according to which audit framework the provider already uses and which market it serves:

STAR Certification builds on an ISO/IEC 27001 certification of the provider's information security management system. An accredited certification body, using auditors qualified for STAR, assesses the CCM controls as additional criteria within the 27001 audit. Like 27001 itself, it follows a three-year certification cycle with surveillance audits in between.
STAR Attestation builds on a SOC 2 examination performed by an independent CPA firm under AICPA standards. The CCM criteria are added to the Trust Services Criteria that a SOC 2 report covers, and the result is a report rather than a certificate. SOC 2 reports typically cover a twelve-month period and are renewed every year.
C-STAR is an assessment route for the Greater China market, developed with the Chinese national certification body CEPREI, which combines the CCM with China's national information security management system standard (GB/T 22080).

Level 2 gives much stronger assurance than Level 1, because evidence has been examined by a qualified third party. Even so, customers should still read the scope: which services, regions and data centres were included, which period the audit covered, and whether any exceptions or qualifications were reported. A certificate for one product line says nothing about another.

STAR for AI

CSA has extended the same model to artificial intelligence services through its AI Controls Matrix (AICM), a companion framework built on the CCM, with an AI version of the questionnaire and Level 1 and Level 2 options for AI services. If your cloud service includes AI features, expect customers to ask about this; for the core cloud controls, the CCM remains the reference.

Transition to v4.1

Because the CCM changes over time, assessments always name the version used. CSA's published timeline lets providers move from v4.0 to v4.1 over roughly two years: both versions are accepted for registry submissions during the transition, only v4.1 submissions are accepted from December 2027, and the v4.0.x matrix and questionnaire are withdrawn in January 2028. A later CSA explainer adds that organisations applying to STAR for the first time must use v4.1 from July 2027. A provider planning its next audit cycle should therefore schedule a v4.1 gap assessment — the new controls and revised wording may require new evidence — well before its renewal.

Other uses in compliance

Outside STAR, the CCM is widely used as an internal control baseline, as the backbone of vendor risk questionnaires, and as a mapping hub. Regulated customers — banks, insurers, healthcare organisations, public bodies — often ask cloud suppliers for a completed CAIQ or STAR listing as part of procurement. The mappings help those customers show regulators how cloud controls relate to their own obligations; the v4.1 reverse mapping from DORA, for example, helps financial entities in the European Union relate their ICT third-party risk duties to CCM controls. No regulator automatically accepts a STAR listing as proof of compliance with its rules, though; the listing is evidence to be used in an assessment, not a substitute for one.

What STAR does not prove

It does not prove that the customer has configured the service securely. Many cloud breaches result from customer misconfiguration of a well-secured platform.
It does not prove that every service from the same provider is covered; only the services in the stated scope.
A Level 1 entry does not prove that anything was independently checked.
No listing guarantees the absence of incidents. Assurance reduces uncertainty; it does not remove risk.

Lesson 6 – Worked example

This example is fictional but realistic. It shows how one company uses the CCM in both directions: as a customer of its own suppliers and as a provider to its customers.

The organisation

LedgerLoop is a 120-person company that sells a SaaS reconciliation platform to mid-sized banks and payment companies in Europe and Asia. It runs entirely on a large public IaaS and PaaS platform, uses a managed database service, sends email through a third-party service and outsources first-line customer support to a partner. LedgerLoop holds an ISO/IEC 27001 certificate. Sales are being slowed because every bank sends its own 300-question security questionnaire, and two large prospects have asked whether LedgerLoop is "on the STAR Registry". A new regulation in one market also obliges the banks to assess their critical ICT suppliers more rigorously.

Step 1 – Define scope and roles

The head of security, Amara, defines the scope as the production reconciliation platform in two regions. She lists LedgerLoop's own suppliers (the IaaS/PaaS platform, the email service and the support partner) and notes that LedgerLoop is a CSC of each, while being a CSP to the banks. She appoints control owners using the organisational relevance flags: engineering for application, infrastructure and change controls; IT for endpoints; HR for personnel controls; legal for privacy and contracts; and the GRC analyst for governance and audit.

Step 2 – Reuse the ISO/IEC 27001 work

Using the CCM mapping to ISO/IEC 27001 and 27002, the GRC analyst marks each CCM control as already supported by the existing management system (no gap), partly supported (partial gap) or not addressed (full gap). Most governance, HR and incident controls are already in good shape. The partial and full gaps cluster around cloud-specific topics: documented SSRM for customers, portability and exit support, tenant isolation testing, audit log sanitisation and customer-facing transparency about the platform's components and suppliers.

Step 3 – Inherit and verify supplier controls

For the physical data centre and much of the virtualisation layer, LedgerLoop relies entirely on its IaaS/PaaS provider. Amara downloads that provider's STAR Level 2 listing and its SOC 2 report, checks that the regions and services LedgerLoop uses are in scope, and records the provider-owned controls as "inherited, verified on [date] against report period". For the email service, which only has a Level 1 self-assessment, she reviews the CAIQ answers, notes that the service does not encrypt messages end to end, and decides as a compensating control that LedgerLoop's notifications will never include customer financial data. For the support partner, she adds contract clauses on access, training and incident notification, because the partner handles customer tickets.

Step 4 – Decide LedgerLoop's SSRM towards the banks

Next, Amara's team decides ownership for each control from the banks' point of view. The table shows a sample.

Control area	Ownership towards the banks	How LedgerLoop explains it
Data centre physical protection	CSP-owned (delivered through the IaaS supplier)	Covered by the platform provider; LedgerLoop reviews its audit reports annually.
Application user accounts	Shared, dependent	LedgerLoop provides single sign-on and role features; each bank manages its own users and roles and must remove leavers.
Encryption keys for bank data	Shared, dependent	Data is encrypted by default; banks on the premium tier can supply their own keys and own their rotation.
Security incident notification	Shared, dependent	LedgerLoop notifies within the contractual time; the bank's response depends on that notice.
Data classification	Shared, independent	LedgerLoop classifies its operational data; each bank classifies what it uploads.
Staff security training	Each party for its own staff	LedgerLoop trains its staff and the support partner; banks train theirs.

Step 5 – Close the gaps and complete the CAIQ

Over four months, LedgerLoop closes the main gaps: it publishes a customer responsibility guide, adds an export function and an exit procedure, masks account numbers in application logs, adds threat modelling to its design process, and documents its own suppliers for customers. The team then completes CAIQ v4.1. For every answer they write a short implementation description and, where relevant, the bank's responsibilities. Legal reviews the wording to ensure nothing is promised that the contract does not support. Where the honest answer is No, they answer No and explain the compensating measure or roadmap, rather than stretching a Yes.

Step 6 – Publish Level 1, then plan Level 2

LedgerLoop submits the CAIQ to the STAR Registry as a Level 1 self-assessment and runs it through the optional automated validation to catch incomplete answers. Sales now send prospects the registry link instead of filling in each bank's questionnaire from scratch; most banks accept the CAIQ with a short list of follow-up questions. Because LedgerLoop already holds ISO/IEC 27001, the logical next step is STAR Certification at its next recertification audit, with its certification body adding the CCM controls to the audit scope. Amara schedules the work so that the audit uses v4.1, avoiding a second transition later.

Step 7 – Keep it alive

Finally, LedgerLoop adds CCM control IDs to its risk register and change process, so that any architecture change triggers a check of the affected CAIQ answers. It reviews supplier listings and reports every year, and it updates its registry entry whenever a significant change would make an answer inaccurate. The CCM has become part of how LedgerLoop runs, rather than a document produced once for sales.

What the example teaches

Most organisations are both customers and providers; the CCM handles both roles with the same vocabulary.
Mappings turn existing certifications into a head start rather than starting from zero.
Inherited controls still need verification and scope checking.
The written description of each answer, especially the customer's responsibilities, is where most of the value lies.
Honest No answers with a plan build more trust than optimistic Yes answers that later fail in an audit or incident.

Lesson 7 – Relationship to other standards and frameworks

The CCM rarely stands alone. It is designed to sit alongside management system standards, audit frameworks and other control catalogues, and its mappings make those relationships explicit. The table compares the most common neighbours.

Framework	Owner	What it is	How it relates to the CCM
ISO/IEC 27001	ISO and IEC	Certifiable requirements for an information security management system (ISMS), with a reference set of controls in Annex A.	Provides the management system; the CCM adds cloud-specific controls. STAR Certification is built on a 27001 certification.
ISO/IEC 27017	ISO and IEC	Code of practice giving cloud-specific guidance on information security controls, for providers and customers.	Closest in subject. 27017 is guidance from a formal standards body; the CCM is a broader, more detailed matrix with ownership data, a questionnaire and a public registry. CSA maps the two.
ISO/IEC 27018	ISO and IEC	Code of practice for protecting personal data in public clouds acting as data processors.	Overlaps with the CCM privacy domain (DSP); mapped by CSA.
SOC 2	AICPA	Attestation report by an independent CPA firm on controls relevant to the Trust Services Criteria.	STAR Attestation adds CCM criteria to a SOC 2 examination; CSA maps the CCM to the Trust Services Criteria.
NIST SP 800-53	NIST (USA)	Large catalogue of security and privacy controls for information systems, widely used in government.	More detailed and not cloud-specific; mapped to the CCM so cloud work can support 800-53 based programmes.
CIS Critical Security Controls	Center for Internet Security	Prioritised set of defensive Safeguards grouped into Implementation Groups.	Focuses on prioritised technical actions; the CCM covers governance, supply chain and shared responsibility in more depth. Mapped by CSA.

Choosing and combining

A useful way to think about these relationships is in layers. ISO/IEC 27001 answers "how do we manage information security as a system: risk assessment, objectives, leadership, internal audit, continual improvement?" The CCM answers "which cloud-specific controls should that system include, and who owns each one in a cloud relationship?" SOC 2 and ISO certification answer "has an independent party checked it?" The CAIQ and STAR Registry answer "how do we share all this with customers in a standard, comparable way?" Control catalogues such as NIST SP 800-53 or the CIS Controls offer additional technical depth or prioritisation. Organisations rarely need to pick only one: the CCM's mappings exist so that one set of implemented controls and evidence can satisfy several frameworks at once.

The CCM also connects to other CSA work. The CSA Security Guidance for Critical Areas of Focus in Cloud Computing explains cloud security concepts in depth and is the body of knowledge for the CSA's Certificate of Cloud Security Knowledge (CCSK), a credential for individuals. CSA also offers an auditor-focused credential built around the CCM and STAR. These certify people, not organisations; they are separate from STAR assurance of a cloud service.

Finally, cloud providers' own shared responsibility documents — the pages in which large IaaS providers describe "security of the cloud" versus "security in the cloud" — express the same idea as the SSRM in their own terms. The CCM gives customers a neutral, provider-independent structure into which those provider-specific statements can be translated and compared.

Common pitfalls and best practices

Common pitfalls

Treating ownership labels as final. The typical ownership in the CCM is a general starting point. Copying it without checking the actual contract and service configuration produces a responsibility split that does not match reality.
Assuming "provider-owned" means "nothing to do". The customer still has to verify evidence, check scope and remain accountable for its data.
Accepting a Level 1 listing as independent proof. A self-assessment is the provider's statement; it has value, but it is not an audit.
Ignoring scope. A STAR certificate or SOC 2 report for one service, region or period says nothing about others.
Bare Yes/No answers. A CAIQ without implementation descriptions and customer responsibilities pushes all the real questions back into email threads and meetings.
Optimistic answers. Answering Yes to controls that are only planned or partly in place creates legal and reputational risk when an audit or incident reveals the truth.
Letting answers go stale. Cloud architectures change quickly; an out-of-date questionnaire misleads customers.
Forgetting the supply chain. A SaaS provider that does not review its own suppliers' assurance cannot honestly describe its inherited controls.

Best practices

Start from your existing programme. Use the mappings to reuse ISO/IEC 27001, SOC 2 or NIST work and focus effort on real gaps.
Write the SSRM into contracts. Shared controls, especially dependent ones, need defined hand-overs: notification times, log access, key options, exit support.
Tailor by risk and service model. Use criticality, service model and the relevance flags to decide which controls need deep review for each service.
Explain every answer. Provide implementation descriptions and customer responsibilities for every relevant question.
Verify inherited controls regularly. Review supplier listings and reports at least annually and check their scope and period.
Link CCM IDs to change and risk processes. Make architecture changes trigger a review of affected controls and CAIQ answers.
Plan version transitions early. Schedule a v4.1 gap assessment well before the next audit or registry update.
Measure where you can. Use metrics and, for mature programmes, continuous monitoring rather than relying on annual snapshots.

Summary and key takeaways

The CSA Cloud Controls Matrix is a free, vendor-neutral catalogue of cloud security and privacy controls; the current edition is v4.1 (January 2026), with 207 controls in 17 domains.
Its distinctive contribution is the Shared Security Responsibility Model: for every control, it helps decide whether the provider, the customer or both are responsible, and in which service model.
A control row combines the requirement, typical ownership for IaaS, PaaS and SaaS, and relevance flags for technical layers and organisational functions.
The CAIQ turns controls into yes/no questions; its implementation descriptions and customer responsibilities are where its real value lies.
STAR Level 1 is a public self-assessment; STAR Level 2 adds independent assurance through ISO/IEC 27001-based certification, SOC 2-based attestation or C-STAR.
Mappings with gap ratings let organisations reuse existing compliance work and identify cloud-specific gaps.
Responsibility for work can be shared or outsourced, but accountability for data stays with the customer; inherited controls must be verified.
Providers should move to v4.1 before the transition deadline of December 2027.

Reflection questions

Pick one cloud service your organisation uses. Which three CCM domains matter most for it, and why?
For the same service, choose one control you believe is shared. Is it dependent or independent, and what exactly is the hand-over between the parties?
If a critical supplier only had a STAR Level 1 listing, what additional evidence would you ask for before relying on it, and how would that depend on the data involved?
How would your answers to a CAIQ change if your company moved one product from IaaS virtual machines to a fully managed PaaS?
Which existing certification or report in your organisation could you map to the CCM first, and where would you expect the largest gaps to appear?