Framework

CSA Cloud Controls Matrix
v4 domains, CAIQ, STAR, and evidence

The Cloud Security Alliance Cloud Controls Matrix (CCM) is the cloud-native control framework most enterprise security programmes converge on for cloud security. CCM v4 organises around 200 control specifications across 17 domains, paired with the CAIQ v4 assessment questionnaire and the CSA STAR registry. This page covers the 17 domains, the shared responsibility model, the assessment and registry mechanics, adoption signals and pitfalls, cross-walks to ISO 27001 / 27017 / 27018, SOC 2, NIST SP 800-53, FedRAMP, and PCI DSS, and the audit-grade evidence a CCM programme keeps in one operating record.

Get Started Free

No credit card required. Free plan available forever.

CSA Cloud Controls Matrix explained

The Cloud Security Alliance Cloud Controls Matrix (CSA CCM) is the cloud-native control framework most enterprise security programmes converge on when they need a single reference catalogue for cloud security controls. CCM v4 is the current version. It names roughly 200 control specifications across 17 domains, with each control naming the layer of the cloud stack it applies to and the responsibility split it expects between the cloud service customer and the cloud service provider. The CCM is paired with the Consensus Assessments Initiative Questionnaire (CAIQ) v4, the yes-or-no assessment companion procurement teams increasingly require before they will close a cloud purchase.

For internal security teams, AppSec teams, cloud security teams, vulnerability management functions, GRC owners, security engineering teams, and CISOs, CCM is the framework that lets a cloud security programme communicate consistently across procurement reviews, audit committees, regulator questions, and customer security questionnaires. Programmes already operating against ISO 27001, ISO 27017, SOC 2, or NIST SP 800-53 do not need to replace those frameworks; CCM cross-walks to each and adds the cloud-specific obligations the underlying catalogues do not name in full.

The standard scope: framework, questionnaire, and registry

CCM does not sit in isolation. It is one leaf in a three-part CSA programme that buyers and regulators read together: the framework (CCM), the assessment questionnaire (CAIQ), and the public registry (STAR). The three together carry the procurement, audit, and ongoing assurance shape an enterprise cloud-buying motion expects. The CSA STAR framework page covers the assurance overlay in detail: the three STAR levels (Level 1 self-assessment, Level 2 third-party certification or attestation against ISO/IEC 27001 or SOC 2 with the CCM, Level 3 continuous self-assessment), the registry mechanics, the buyer-side and provider-side operating shape, and the cross-walk to FedRAMP, ISO/IEC 27017, ISO/IEC 27018, and the regulator-aligned cloud regimes the STAR posture serves.

A cloud-specific control framework

The Cloud Security Alliance Cloud Controls Matrix (CSA CCM) is a control framework purpose-built for cloud computing. It names the security controls a cloud customer should evidence against the cloud services it consumes, and the controls a cloud service provider should evidence against the services it provides. CCM v4 organises the catalogue across 17 domains and roughly 200 control specifications, with each control naming the layer of the cloud stack it lives in and the responsibility split it expects between customer and provider.

Paired with CAIQ, the assessment questionnaire

The Consensus Assessments Initiative Questionnaire (CAIQ) is the assessment companion to the CCM. CAIQ v4 is a yes-or-no questionnaire that lets a cloud customer evaluate a cloud service provider against the CCM control set without rebuilding the question bank from scratch. Many enterprise vendor security reviews start with a CAIQ rather than a bespoke security questionnaire because the CAIQ language already names the cloud-specific obligations CCM expects.

Underpins the STAR Registry

CSA STAR (Security, Trust, Assurance, and Risk) is the registry the framework feeds. STAR Level 1 is a self-assessment that publishes a completed CAIQ or CCM mapping. STAR Level 2 is a third-party assessment (STAR Certification against ISO 27001 with the CCM, or STAR Attestation against SOC 2 with the CCM). STAR Level 3 is continuous self-assessment. The registry is publicly searchable, which is why many enterprise procurement teams expect a STAR entry before they will close a cloud purchase.

The 17 CCM v4 domains

CCM v4 organises its control specifications across 17 domains that cover the cloud security surface end to end. Each domain holds multiple control specifications, with the typical spread running from a handful of controls in the smaller domains (DCS, UEM) to a few dozen in the larger ones (IAM, IVS, GRC). The domain list below is the inventory a CCM mapping reads against; the audit pack carries the mapping per domain, per service, per responsibility split.

AIS: Application and Interface Security

Secure development, application security testing, and API security controls for cloud-hosted applications. AIS reads against SAST, DAST, dependency analysis, and API testing evidence that the cloud application produces during the lifecycle.

AAC: Audit Assurance and Compliance

Compliance and audit obligations for cloud customers and cloud service providers. AAC covers regulatory mapping, independent audit cadence, evidence retention, and the right-to-audit obligations the cloud relationship expects.

BCR: Business Continuity Management and Operational Resilience

Continuity planning, disaster recovery, resilience testing, and recovery objective alignment between cloud customer and provider. BCR carries the cloud-specific dependencies (region failover, multi-zone replication, provider-side recovery commitments) the legacy continuity frameworks do not name.

CCC: Change Control and Configuration Management

Change management, baseline configuration, secure configuration enforcement, and the change tracking the cloud customer can demonstrate against the workloads it operates. CCC reads against the configuration drift evidence cloud security teams produce continuously.

CEK: Cryptography, Encryption, and Key Management

Cryptographic controls, encryption-at-rest and encryption-in-transit obligations, and the key management responsibility split between provider-managed and customer-managed keys. CEK is one of the domains where the shared responsibility line is most consequential.

DCS: Data Center Security

Physical security controls for the data centres the cloud provider operates. DCS is almost entirely a provider obligation in IaaS and PaaS, with the customer reading against the provider attestation and the SOC 2 / ISO 27001 evidence the provider publishes.

DSP: Data Security and Privacy Lifecycle Management

Data classification, data ownership, data handling, data lifecycle, and the privacy obligations that follow. DSP is where data classification meets cloud control, and it is the domain regulator-aligned programmes read most carefully against ISO 27018, GDPR, and the privacy obligations that follow personal data into cloud services.

GRC: Governance, Risk, and Compliance

Information security governance, risk management, policy hierarchy, and the management-system discipline above the technical controls. GRC reads against the ISMS the cloud customer operates and the ISMS the cloud provider operates, with the cloud relationship expecting both.

HRS: Human Resources Security

Personnel security, background checks, training, and the privileged-access discipline cloud operations require. HRS names personnel controls explicitly because cloud admin actions touch many customers in a single change.

IAM: Identity and Access Management

Identity governance, access provisioning, authentication strength, privileged access, and the identity boundary between customer and provider. IAM is the largest CCM domain by control count because identity is the most consequential cloud control surface.

IPY: Interoperability and Portability

Data portability, application portability, and the exit obligations the cloud relationship carries. IPY is the domain that turns "cloud lock-in" from a procurement worry into a control obligation; the cloud customer evidences the ability to leave with the data and the configuration intact.

IVS: Infrastructure and Virtualization Security

Network security, virtualisation security, tenant isolation, and the segmentation discipline cloud workloads require. IVS reads against the cloud network controls and the workload-isolation evidence the provider attests to.

LOG: Logging and Monitoring

Log generation, log retention, monitoring coverage, alerting cadence, and the audit trail cloud services produce. LOG is where the cloud-side telemetry meets the customer-side SIEM and detection engineering record.

SEF: Security Incident Management, E-Discovery, and Cloud Forensics

Incident response, e-discovery support, forensic readiness, and the incident notification cadence the cloud relationship expects. SEF is the domain that maps to ISO/IEC 27035 incident management and to the regulator-side notification obligations.

STA: Supply Chain Management, Transparency, and Accountability

Vendor and sub-processor management, supply chain transparency, and the accountability obligations the cloud relationship layers onto third-party risk management. STA reads against NIST SP 800-161 supply chain risk and the third-party risk programmes most enterprises already operate.

TVM: Threat and Vulnerability Management

Vulnerability scanning, threat intelligence, patch cadence, and the vulnerability remediation discipline cloud services require. TVM is the domain a vulnerability management programme already produces evidence against; CCM names the cloud-specific cadence and coverage expectations.

UEM: Universal Endpoint Management

Endpoint security, mobile device management, BYOD controls, and the endpoint posture the cloud trust model reads against. UEM is the domain that connects device-posture evidence to the cloud access decisions.

The shared responsibility model as a control obligation

CCM v4 carries an explicit shared responsibility model. Each control specification names who operates it: the Cloud Service Provider (CSP), the Cloud Service Customer (CSC), a third party (3P), or a documented blend. The shared row is where the audit conversation usually lands because that is where customer and provider both have to evidence their part of the obligation without overlap or gap. CCM turns the shared-responsibility diagram from a marketing illustration into a documented control allocation per service.

  • Cloud Service Provider (CSP) responsibility: controls the CSP operates on behalf of all customers, evidenced through provider attestations (SOC 2 Type II, ISO 27001 certificate, ISO 27017 certificate, ISO 27018 certificate, the published CAIQ, the STAR registry entry, the FedRAMP authorisation package where applicable).
  • Cloud Service Customer (CSC) responsibility: controls the customer operates against the cloud services it consumes, evidenced through the customer-side ISMS, the customer-side vulnerability programme, the customer-side incident response, the configuration baseline the customer enforces, and the access-control discipline the customer runs.
  • Shared responsibility: controls the customer and provider both operate, with the boundary defined per service. The shared row is where most cloud incidents land in audit reviews; the responsibility is documented per service rather than assumed.
  • Third party (3P): controls operated by a sub-processor or upstream supplier. The CSP carries the assurance obligation back to the customer, evidenced through the CSP supply-chain programme and the 3P attestations the CSP relies on.

When CCM becomes the right framework to adopt

The adoption decision is rarely top-down. CCM tends to enter a programme when one of the signals below crosses a threshold and the programme realises a common cloud control framework would dissolve the friction. The pattern matches the way ISO 27001 enters early and CCM enters once the cloud estate is large enough that the cross-cutting friction outweighs the framework adoption cost.

  • Procurement asking for a CAIQ. Enterprise procurement and vendor risk teams increasingly require a completed CAIQ as a precondition to a security review. A cloud service offered without a CAIQ slows the procurement cycle and may be rejected before the security review begins.
  • STAR Level 2 in the enterprise vendor checklist. STAR Certification (ISO 27001 plus CCM) or STAR Attestation (SOC 2 plus CCM) is appearing as a tendered requirement in enterprise RFPs, particularly for regulated sectors and federal-adjacent buyers.
  • Multi-cloud evidence reconciliation pain. Programmes operating across AWS, Azure, GCP, and SaaS find that mapping each provider attestation to a single internal control set is friction-heavy without a common framework; CCM is the common framework most enterprises converge on.
  • Regulator references. Several regulators (FFIEC for US banking, EBA for EU banking, MAS TRM for Singapore financial services) reference CSA CCM as an acceptable cloud control framework. Programmes facing regulator-cloud-questioning frequently fall back on a CCM mapping as the reconcilable answer.
  • Customer security questionnaire load. Sales engineering and security operations teams answering bespoke customer security questionnaires find that publishing a CAIQ deflects 60 to 80 percent of the questionnaire load to a single document, with bespoke follow-ups only where the CAIQ answer is genuinely insufficient.
  • ISO 27001 plus cloud uplift. Programmes already operating an ISO 27001 ISMS but lacking ISO 27017 and ISO 27018 evidence often adopt CCM as the cloud-specific extension because the CCM cross-walks to both standards explicitly.

Recurring adoption pitfalls

CCM is forgiving on the order programmes adopt the domains and on the specific tooling that backs the controls. It is unforgiving about a small number of patterns that erode the integrity of the mapping and leave the programme with the appearance of CCM coverage rather than an operating cloud-control framework. The patterns below are the recurring ones across early and mid-stage adoptions.

  • Treating CCM as a one-off mapping exercise. Programmes that produce a CCM-to-internal-controls mapping at one point in time and never revisit it find the mapping drifts with each service launch, each acquisition, and each cloud-provider change. The CCM mapping is a living document that the security programme refreshes on a documented cadence.
  • Confusing the CAIQ with the audit evidence. A completed CAIQ is a self-assessment, not an audit. Programmes that publish a CAIQ without the underlying control evidence end up answering follow-up questions that ask for the evidence anyway. The CAIQ is the index; the evidence pack is the substance.
  • Mapping CCM only to ISO 27001 and stopping there. CCM cross-walks against many frameworks (ISO 27001 / 27017 / 27018, SOC 2, NIST SP 800-53, PCI DSS, HIPAA, FedRAMP, NIST CSF, ENISA). Programmes that map only against the in-house certification miss the cross-framework leverage CCM was designed to provide.
  • Underweighting the IPY (portability) domain. The portability and exit obligations CCM names are the controls procurement and legal read most carefully against contract terms. A programme that evidences strong IAM and weak IPY is well-defended against day-to-day risk and poorly positioned against the contract review.
  • Letting the shared responsibility line stay implicit. CCM expects a documented split per service. Programmes that operate against a generic "shared responsibility" diagram from the provider find that the audit conversation collapses when the question is "which side runs control X for service Y in region Z". The CCM expects that question to have a written answer.
  • CCM as a substitute for ISO 27001 or SOC 2. CCM is a control framework; STAR Level 2 reads against ISO 27001 or SOC 2 with CCM layered on, not against CCM alone. Programmes that confuse the layering find that the buyer-side STAR-Level-2 expectation is not met because the underlying certification is missing.

What an auditor or buyer reads against

A STAR Level 2 assessment, a customer security questionnaire response, or an enterprise procurement review reads the CCM record against three lenses. The lenses below are the shape the conversation takes; programmes that produce the evidence pack with these lenses in mind shorten the assurance cycle and reduce the bespoke follow-up to a manageable residual.

  • Coverage. Every cloud service in the customer estate is mapped against the relevant CCM domains, with the controls the customer operates and the controls the provider operates named explicitly. Coverage gaps are visible as services without a documented CCM mapping.
  • Decision durability. Risk acceptance, exceptions, and compensating controls against specific CCM control specifications are recorded with the named owner, the rationale, the expiry, and the review cadence. Decisions persist beyond the individual who made them.
  • Framework alignment. The CCM mapping cross-walks against ISO 27001 / 27017 / 27018, SOC 2, NIST SP 800-53, PCI DSS, HIPAA, and the regulator-specific cloud frameworks the programme reads against. The cross-walk is a single source of truth rather than parallel spreadsheets.

A phased rollout from cloud sprawl to a CCM operating record

CCM adoption is most successful as a phased programme rather than a single mapping exercise. The phases below describe a path that takes a programme from cloud estate without a common control framework to a CCM record that compliance tracking, vendor risk, engineering, and security leadership read against on the same cadence.

Phase 1: Scope and inventory

Identify the cloud services in scope (IaaS, PaaS, SaaS, internal cloud), the providers, the regions, and the data classifications. The scope decision is the input every later phase reads against; programmes that skip it land in a CCM mapping exercise without a stable boundary.

Phase 2: Pull provider evidence

Collect the CSP-side attestations (SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, FedRAMP if applicable, the published CAIQ, the STAR registry entry). The provider-side evidence reduces the CCM controls the customer has to evidence directly to the customer-side and shared-responsibility rows.

Phase 3: Map customer-side controls

Per CCM domain, name the customer-side controls already operating, the evidence they produce, and the gaps. The mapping is per service rather than per provider because the responsibility split changes per service. The output is a customer-responsibility matrix that pairs with the provider attestation.

Phase 4: Cross-walk to other frameworks

Layer the CCM mapping against ISO 27001 / 27017 / 27018, SOC 2, NIST SP 800-53, PCI DSS, HIPAA, and the regulator-specific cloud frameworks the programme reads against. The cross-walk is where CCM pays its keep: one mapping satisfies several reads.

Phase 5: Govern and publish

Publish a CAIQ (or a STAR registry entry) on the cadence the programme commits to. Run the management-review discipline against the CCM mapping. Treat the CCM record as a controlled document with a named owner, a review cadence, and a versioning trail rather than a one-off spreadsheet.

Phase 6: Steady-state

Refresh the CCM mapping when services launch, when providers change, when regulators change their cloud expectations, and on a documented annual cadence at minimum. The CCM record is the operating layer the cloud security programme reads against rather than an audit-time artefact.

How CCM relates to ISO 27017, ISO 27018, SOC 2, NIST SP 800-53, and adjacent regimes

CCM is a control framework, not a certifiable management system. The certification and attestation evidence the cloud relationship reads against lives in the underlying regimes a programme already operates against. The relationships below are the ones programmes most often need to read together.

  • The ISO 27001 framework page covers the certifiable ISMS. STAR Certification (Level 2) is ISO 27001 with the CCM layered on; the certification reads against the ISO 27001 management system and the CCM control mapping at the same audit.
  • The ISO 27017 framework page covers the cloud-specific extension to ISO 27002. CCM and ISO 27017 cover overlapping ground (cloud-specific obligations on top of an ISMS); CCM is broader and ecosystem-agnostic, ISO 27017 is the international standard track. Most programmes that adopt ISO 27017 also map CCM as a buyer-facing artefact.
  • The ISO 27018 framework page covers the privacy-extension for personal data in public cloud. CCM domain DSP cross-walks to ISO 27018 directly; programmes processing personal data in cloud services typically read CCM and ISO 27018 together.
  • The SOC 2 framework page covers the AICPA Trust Services Criteria. STAR Attestation is SOC 2 with the CCM layered on; the SOC 2 Type II report and the CCM cross-walk read against the same Trust Services Criteria evidence the SOC 2 examination produces.
  • The NIST SP 800-53 framework page covers the federal-side control catalogue. CCM cross-walks against NIST SP 800-53 Rev. 5 control families directly; programmes operating against the FedRAMP authorisation track read CCM as the customer-side cloud overlay on the NIST SP 800-53 baseline.
  • The FedRAMP framework page covers the United States federal cloud authorisation programme. CCM and FedRAMP are adjacent; FedRAMP is the federal-side cloud authorisation, CCM is the enterprise-side cloud control framework. Many CSPs publish both a FedRAMP authorisation and a STAR registry entry to serve federal and commercial customers from one programme.
  • The PCI DSS framework page covers the payment card industry standard. CCM v4 cross-walks to PCI DSS v4.0; programmes handling cardholder data in cloud services use the CCM mapping to reconcile the PCI DSS requirements against the cloud-side control evidence.
  • The NIST SP 800-161 framework page covers cybersecurity supply chain risk management. CCM domain STA cross-walks to NIST SP 800-161; programmes running a mature supply-chain risk programme read the two together to evidence the cloud-side third-party obligations.
  • The Cloud Security Posture Management explainer covers the operational tool category for cloud-control enforcement. CSPM evidence (configuration baselines, drift detection, public exposure register) feeds the IVS, CCC, and IAM domain evidence the CCM mapping expects.
  • The Cloud Native Application Protection Platform explainer covers the umbrella category above CSPM. CNAPP evidence reads against multiple CCM domains at once (AIS, IVS, CCC, TVM); CCM is the reconcilable framework the CNAPP findings land into rather than a separate set of evidence buckets.

Where SecPortal fits in a CSA CCM programme

SecPortal is the operating layer for the CCM programme record, not a CSPM platform, a CNAPP, a cloud configuration scanner, or a federated identity broker. The platform handles the CCM mapping itself, the customer-responsibility matrix per service, the cloud-side findings the scanning work produces, the cross-walk against the underlying certification regimes, the document evidence the STAR submission expects, and the management-review cadence the framework reads against, so the CCM evidence sits on one operating record rather than spread across drives, spreadsheets, and chat threads.

  • Compliance tracking that maps the same finding and the same control evidence across CSA CCM, ISO 27001, ISO 27017, ISO 27018, SOC 2, NIST SP 800-53, PCI DSS, and the regulator-aligned cloud frameworks the programme reads against, so the cross-walk lives on one record rather than parallel spreadsheets
  • Findings management with CVSS 3.1 scoring so the TVM (Threat and Vulnerability Management) domain has owners, deadlines, and verification evidence per finding rather than a programme-wide vulnerability bucket without remediation traceability
  • External, authenticated, and code scanning so the AIS (Application and Interface Security), IVS (Infrastructure and Virtualization Security), and TVM domains have named coverage across internet-facing infrastructure, authenticated application surface, and source repositories the cloud workloads build from
  • Encrypted credential storage (AES-256-GCM) so the credentials authenticated scanning uses against cloud-hosted applications meet the CEK (Cryptography, Encryption, and Key Management) expectations for the testing surface rather than introducing a control gap inside the assessment workflow
  • Repository connections via GitHub, GitLab, and Bitbucket OAuth so the AIS code-side evidence reads from the same source-control record the engineering function operates against, with the build provenance the auditor expects
  • Continuous monitoring with daily, weekly, biweekly, and monthly scan schedules so the LOG (Logging and Monitoring) and TVM domains evidence the cadence rather than reconstruct it during examination
  • Document management for the CCM mapping itself, the CAIQ, the customer-responsibility matrix, the provider attestations, and the STAR registry submissions, so the evidence pack is versioned and retrievable rather than scattered across drives
  • Activity log with CSV export that captures every state change to a finding, a control mapping, or a CCM domain owner with timestamp and named user, so the audit trail is reproducible without a multi-team excavation
  • MFA enforcement (TOTP) on the SecPortal workspace itself so the IAM discipline the CCM expects from the security programme is not undermined at the platform that holds the evidence
  • AI report generation that turns the engagement record and the CCM mapping into a customer-facing or board-ready CCM-shaped summary without manual rewriting

The cloud-side findings that feed the TVM and AIS domains are where most of the day-to-day vulnerability work touches CCM. Findings from authenticated scans against the cloud-hosted applications, external scanning against the internet-facing cloud surface, and code scanning against the repositories the cloud workloads build from all read against the same CCM control specifications the mapping expects. The cloud security assessment workflow keeps the line from each finding through to the CCM domain auditable. The control mapping cross-framework crosswalks workflow carries the same CCM mapping into the ISO 27001, ISO 27017, SOC 2, NIST SP 800-53, and PCI DSS reads the programme already operates. The audit evidence retention and disposal workflow carries the evidence-lifecycle discipline the STAR submission and the customer-side audit expect. The vendor security questionnaire response workflow carries the CAIQ-side response cadence procurement teams ask against, with the same source record the engineering function uses.

For internal teams running the programme, the internal security teams workspace bundles the platform with the engagement structure CCM adoption expects across the cycle. For the cloud security function that owns the CSPM, CNAPP, and configuration baseline work the CCM domains read against, the cloud security teams workspace covers the operational angle on the cloud surface CCM names. For the GRC function that holds the cross-framework reconciliation against ISO 27001, ISO 27017, SOC 2, NIST SP 800-53, and the regulator-aligned cloud regimes, the GRC and compliance teams workspace carries the audit-side angle. For the AppSec function that owns the AIS evidence in the cloud applications, the AppSec teams workspace carries the application-layer angle CCM expects. For security leaders carrying the cloud-security accountability and the CCM scorecard cadence, the CISOs and security leaders workspace covers the programme-level reporting model.

For the compliance-side mechanics the CCM mapping rides on, the compliance tracking capability carries the cross-framework mapping shape, the findings management capability carries the per-finding control-evidence chain, and the document management capability carries the CCM mapping, the CAIQ, the customer-responsibility matrix, and the provider attestations on one versioned record. For analytical context on how cross-framework evidence holds up over time, the audit evidence half-life research covers the durability patterns the CCM mapping reads against.

Key control areas

SecPortal helps you track and manage compliance across these domains.

The CCM framework, CAIQ, and STAR registry

CCM v4 is the control framework. The Consensus Assessments Initiative Questionnaire (CAIQ) v4 is the yes-or-no assessment companion procurement teams use against the framework. CSA STAR is the public registry where the assessment results land: STAR Level 1 (self-assessment), STAR Level 2 (third-party, ISO 27001 with CCM or SOC 2 with CCM), STAR Level 3 (continuous self-assessment). Programmes selling into enterprise increasingly need at least a CAIQ in the STAR registry; regulated and federal-adjacent buyers ask for STAR Level 2.

The 17 CCM v4 domains

CCM v4 spans 17 domains: AIS (Application and Interface Security), AAC (Audit Assurance and Compliance), BCR (Business Continuity Management and Operational Resilience), CCC (Change Control and Configuration Management), CEK (Cryptography, Encryption, and Key Management), DCS (Data Center Security), DSP (Data Security and Privacy Lifecycle Management), GRC (Governance, Risk, and Compliance), HRS (Human Resources Security), IAM (Identity and Access Management), IPY (Interoperability and Portability), IVS (Infrastructure and Virtualization Security), LOG (Logging and Monitoring), SEF (Security Incident Management, E-Discovery, and Cloud Forensics), STA (Supply Chain Management, Transparency, and Accountability), TVM (Threat and Vulnerability Management), and UEM (Universal Endpoint Management).

Shared responsibility as a documented control allocation

Each CCM control specification names who operates it: Cloud Service Provider (CSP), Cloud Service Customer (CSC), third party (3P), or a documented blend. The shared row is where most audit conversations land because that is where customer and provider both have to evidence their part without overlap or gap. CCM turns the shared-responsibility diagram from a marketing illustration into a control allocation per service, recorded per service, region, and data classification.

CCM as the cross-framework spine

CCM cross-walks to many frameworks at once: ISO 27001 (the ISMS that STAR Certification reads against), ISO 27017 (cloud-specific ISMS extension), ISO 27018 (cloud privacy extension), SOC 2 (Trust Services Criteria), NIST SP 800-53 (federal-side catalogue underlying FedRAMP), PCI DSS v4.0 (payment card industry), HIPAA (US healthcare), NIST CSF, NIST SP 800-161 (supply chain), and the regional cloud regulations many programmes face. One CCM mapping satisfies several reads, which is the practical reason enterprise programmes adopt it.

The CSP-side, CSC-side, and shared evidence pack

The CSP-side evidence (SOC 2 Type II report, ISO 27001 certificate, ISO 27017 certificate, ISO 27018 certificate, FedRAMP authorisation package where applicable, published CAIQ, STAR registry entry) reduces the CCM controls the customer has to evidence directly. The CSC-side evidence covers the customer ISMS, the vulnerability programme output, the incident response record, the configuration baseline, and the access-control discipline. The shared row reads against both sides at once, per service, with the boundary documented.

Adoption signals and pitfalls

Adoption signals include procurement requiring a CAIQ, STAR Level 2 in enterprise RFPs, multi-cloud evidence reconciliation pain, regulator references (FFIEC, EBA, MAS TRM), customer security questionnaire load, and ISO 27001-plus-cloud uplift programmes. Recurring pitfalls include treating CCM as a one-off mapping exercise, confusing the CAIQ with the audit evidence, mapping only to one underlying framework, underweighting the IPY portability domain, letting the shared responsibility line stay implicit, and using CCM as a substitute for ISO 27001 or SOC 2 rather than as a layered control framework.

A phased rollout from cloud sprawl to a CCM record

Scope and inventory (which services, providers, regions, and data classifications are in scope). Pull provider evidence (SOC 2, ISO 27001 family, FedRAMP, CAIQ, STAR). Map customer-side controls per service. Cross-walk to the underlying regimes (ISO 27001, ISO 27017, ISO 27018, SOC 2, NIST SP 800-53, PCI DSS, HIPAA). Govern and publish the CAIQ on the committed cadence. Steady-state: refresh on service launches, provider changes, regulator changes, and on a documented annual cadence at minimum.

Evidence the framework expects to see

The CCM mapping itself with the per-service control allocation. The completed CAIQ (versioned and dated). The customer-responsibility matrix per service. The CSP-side attestations pinned to the controls they evidence. The cross-walk to ISO 27001, ISO 27017, ISO 27018, SOC 2, NIST SP 800-53, PCI DSS, and any regulator-aligned cloud regimes. The CCM-domain-level findings the vulnerability and security testing work produces. The decision record for risk acceptance, exceptions, and compensating controls. The management-review cadence the framework reads against.

Related features

Compliance tracking without a full GRC platform

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Document management for every security engagement

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

Every action recorded across the workspace

Hold the CSA CCM mapping on one workspace

Capture the CCM mapping, the CAIQ, the customer-responsibility matrix, the cross-walks to ISO 27001, ISO 27017, ISO 27018, SOC 2, NIST SP 800-53, and PCI DSS, the CSP attestations, and the cloud-side findings on one operating record alongside the SAST, DAST, and external scanning evidence the workspace already holds. Start free.

Get Started Free

No credit card required. Free plan available forever.