# CSA Cloud Controls Matrix (CCM) — Practical Guide
> **Bottom line:** use **CSA CCM** when you need a cloud-specific control lens that is more operational than a high-level risk framework and more portable than provider-specific guidance. In this KB, the most useful way to read the CCM is **domain → owner → engineering page → evidence**.
## Why this page exists
The KB already had a standards map, but many teams still need a more concrete bridge between **"CCM says we should control this"** and **"which engineering artifacts prove we did it?"**.
This page exists to answer four practical questions:
1. what the CCM is actually good at;
2. how to read the 17 domains without turning them into theory-only labels;
3. how to connect each domain to the engineering sections in this KB;
4. what evidence is realistic to collect from release and operating workflows.
## Current-version note
CSA's current downloadable **Cloud Controls Matrix and CAIQ v4.1** package describes the CCM as **207 controls across 17 security domains**. Some older CSA landing text still shows **197 control objectives**. When there is a count mismatch, treat the **v4.1 artifact package and its guidance documents** as the more current source of truth.
## When CCM is the right control lens
Use the CCM when you need to:
* scope cloud controls across **IaaS / PaaS / SaaS**;
* separate **provider responsibility** from **customer responsibility**;
* connect cloud requirements to **implementation guidance, auditing guidance, CAIQ, and STAR**;
* build one cloud-specific control map that still crosswalks to other standards.
## What CCM is not
The CCM is extremely useful, but it is **not**:
* a replacement for provider-native hardening guidance;
* a full secure-SDLC roadmap by itself;
* a substitute for product-specific threat modeling or abuse review;
* a complete audit package unless you also define owners, cadence, and evidence retention.
## How to read the 17 domains in this KB
Use the table below as the working matrix.
| CCM domain | What it means in practice | Best engineering anchors in this KB | Typical evidence examples |
| ---------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **A\&A — Audit & Assurance** | how you prove control operation and audit readiness | [Metrics and Reporting](https://github.com/D3One/Product-Security-Gitbook/blob/main/02-governance-roles-metrics-and-okr/metrics-and-reporting.md), [Board-Ready Product Security Reporting Pages](/metrics-audit-risk-evidence-and-compliance/index/board-ready-product-security-reporting-pages.md), [Compliance-to-Engineering Evidence Pass](/metrics-audit-risk-evidence-and-compliance/index-1/compliance-to-engineering-evidence-pass.md) | release evidence JSON, audit-ready control matrices, exception register, quarterly scorecards |
| **AIS — Application & Interface Security** | application-layer and interface-facing controls | [Application Security](/application-security-and-secure-sdlc/index-1.md), [API Security](/architecture-api-crypto-and-identity/index.md) | SAST/DAST outputs, API test evidence, secure design reviews, authn/authz review notes |
| **BCR — Business Continuity Management & Operational Resilience** | recovery, resilience, continuity, and service survivability | [Product Security Incident Response Playbooks](/attack-paths-testing-detection-and-hardening/index/product-security-incident-response-playbooks.md), [Annual Product Security Report for Stakeholders](/metrics-audit-risk-evidence-and-compliance/index/annual-product-security-report-for-stakeholders.md) | backup/restore test records, tabletop outputs, continuity plans, recovery KPI summaries |
| **CCC — Change Control & Configuration Management** | controlled change, drift reduction, and baseline integrity | [GitLab Release Evidence](/devsecops-cicd-and-supply-chain/index-1/gitlab-release-evidence.md), [Cloud Auditing by API and Configuration State](/cloud-kubernetes-and-infrastructure-security/index/cloud-auditing-by-api-and-configuration-state.md), [Infrastructure as Code Maturity and Test Strategy](/cloud-kubernetes-and-infrastructure-security/index/infrastructure-as-code-maturity-and-test-strategy.md) | merge approvals, deployment approvals, IaC policy results, change tickets, config diffs |
| **CEK — Cryptography, Encryption, & Key Management** | key lifecycle, encryption strategy, and secrets handling | [Application-Level Encryption, Tokenization, Masking, and Key Management](/architecture-api-crypto-and-identity/index-3/application-level-encryption-tokenization-masking-and-key-management.md), [Secret Management on HashiCorp Vault](/cloud-kubernetes-and-infrastructure-security/index/vault-secret-management-on-hashicorp-vault.md), [Mozilla SOPS](/cloud-kubernetes-and-infrastructure-security/index/mozilla-sops-age-kms-and-gitops-secrets.md) | KMS/key policies, encryption configuration, secret-rotation evidence, key access reviews |
| **DCS — Datacenter Security** | physical/cloud-facility controls, usually provider-owned in public cloud | [Vendor Guides and Standards Map](/metrics-audit-risk-evidence-and-compliance/index-1/vendor-guides-and-standards-map.md), [Cloud Security Across AWS, Azure, and GCP](/cloud-kubernetes-and-infrastructure-security/index/cloud-security-across-aws-azure-and-gcp.md) | provider attestations, CAIQ/STAR responses, supplier assurance records |
| **DSP — Data Security & Privacy** | data lifecycle, minimization, exposure control, and privacy-sensitive handling | [Data Classification and Sensitive Data Lifecycle](/architecture-api-crypto-and-identity/index-3/data-classification-and-sensitive-data-lifecycle.md), [Log Redaction, Backups, and Privacy by Design](/architecture-api-crypto-and-identity/index-3/log-redaction-backups-and-privacy-by-design.md) | data flow reviews, retention settings, redaction tests, backup controls, privacy design records |
| **GRC — Governance, Risk Management, & Compliance** | policy, ownership, exceptions, and risk translation | [Governance, Roles, Metrics, and OKR](/metrics-audit-risk-evidence-and-compliance/index.md), [Policy Exception Governance Pack](/metrics-audit-risk-evidence-and-compliance/index/policy-exception-governance-pack.md) | policy set, owner matrix, risk register, exception approvals, review cadence records |
| **HRS — Human Resources Security** | workforce onboarding/offboarding and role-sensitive security practices | [Security Champions Program Playbook](/metrics-audit-risk-evidence-and-compliance/index/security-champions-program-playbook.md), [JIT, PAM, Break-Glass, and Admin Access](/architecture-api-crypto-and-identity/index-2/jit-pam-break-glass-and-admin-access.md) | joiner/mover/leaver evidence, privileged-access training, offboarding checklists |
| **IAM — Identity & Access Management** | human and machine access design | [AWS IAM and Role Design](/cloud-kubernetes-and-infrastructure-security/index/aws-iam-and-role-design.md), [Workload Federation and Non-Human Identities](/architecture-api-crypto-and-identity/index-2/workload-federation-and-non-human-identities.md), [JIT, PAM, Break-Glass, and Admin Access](/architecture-api-crypto-and-identity/index-2/jit-pam-break-glass-and-admin-access.md) | role/policy definitions, access reviews, workload identity configuration, break-glass logs |
| **IPY — Interoperability & Portability** | data/service portability, exit planning, lock-in reduction, migration-safe design | [Third-Party Component Onboarding and Offboarding](https://github.com/D3One/Product-Security-Gitbook/blob/main/21-third-party-and-integration-security/third-party-component-onboarding-and-offboarding.md), [Zero-Trust Egress and Private Connectivity Patterns](/architecture-api-crypto-and-identity/index-1/zero-trust-egress-and-private-connectivity-patterns.md) | export procedures, data portability tests, integration contracts, offboarding runbooks |
| **IVS — Infrastructure & Virtualization Security** | compute, network, cluster, and virtualization-layer control design | [Infrastructure and Cloud Security](/cloud-kubernetes-and-infrastructure-security/index.md), [Container and Kubernetes Security](/cloud-kubernetes-and-infrastructure-security/index-1.md) | hardened images, baseline configs, cluster policy results, cloud network posture snapshots |
| **LOG — Logging & Monitoring** | high-value logging, telemetry integrity, and monitoring coverage | [Logging and Telemetry Strategy](/attack-paths-testing-detection-and-hardening/index/logging-and-telemetry-strategy.md), [Cloud Audit Cookbook by Provider](/cloud-kubernetes-and-infrastructure-security/index/cloud-audit-cookbook-by-provider.md) | audit-log exports, retention settings, centralization checks, alert coverage summaries |
| **SEF — Security Incident Management, E-Discovery, & Cloud Forensics** | incident readiness, investigation, and forensic support | [Product Security Incident Response Playbooks](/attack-paths-testing-detection-and-hardening/index/product-security-incident-response-playbooks.md), [Runtime Investigation Playbook](/cloud-kubernetes-and-infrastructure-security/index-1/runtime-investigation-playbook.md) | incident plans, forensics playbooks, exercised scenarios, case retention evidence |
| **STA — Supply Chain Management, Transparency, & Accountability** | software supply chain trust and third-party control clarity | [Software Supply Chain Foundations](/devsecops-cicd-and-supply-chain/index-1/software-supply-chain-foundations.md), [Signing, Attestation, and Verification](/devsecops-cicd-and-supply-chain/index-1/signing-attestation-and-verification-legacy-vs-current.md), [Vendor Agents, Runners, and Build Integration Trust Boundaries](/devsecops-cicd-and-supply-chain/index-2/vendor-agents-runners-and-build-integration-trust-boundaries.md) | SBOMs, provenance, attestations, vendor questionnaires, signature verification results |
| **TVM — Threat & Vulnerability Management** | discovery, triage, prioritization, and reduction of exploitable weaknesses | [SAST Noise Reduction](/application-security-and-secure-sdlc/index-1/sast-noise-reduction.md), [Terraform Security Scanning and Checkov](/cloud-kubernetes-and-infrastructure-security/index/terraform-security-scanning-and-checkov.md), [Kubernetes Top 10 Misconfigurations](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-top-10-misconfigurations.md) | scanner outputs, prioritized backlog, remediation aging, exception decisions |
| **UEM — Universal Endpoint Management** | endpoint governance for admin, developer, and managed device surfaces | [Developer Workstation Hardening](/learning-labs-interview-and-templates/index-2/developer-workstation-hardening-for-appsec-and-devsecops.md), [JIT, PAM, Break-Glass, and Admin Access](/architecture-api-crypto-and-identity/index-2/jit-pam-break-glass-and-admin-access.md) | endpoint baseline checks, admin workstation rules, MDM posture summaries |
## Text walkthrough of the matrix
### 1) Governance and assurance cluster
The most foundational CCM domains for program owners are **A\&A, GRC, and CCC**.
These domains answer:
* who owns the control;
* how changes are authorized;
* how evidence is retained;
* how audit or customer questions are answered without reconstructing history by hand.
If these domains are weak, even good technical controls become hard to prove.
### 2) Cloud platform and identity cluster
For real cloud programs, the daily operating center of gravity is usually **IAM, IVS, LOG, and TVM**.
These domains cover the areas where drift, privilege mistakes, blind spots, and exploitable misconfigurations accumulate fastest.
### 3) Data and cryptography cluster
**DSP and CEK** matter when the product stores regulated or customer-sensitive data, especially when teams need to explain how encryption, retention, redaction, and secret handling are actually enforced.
### 4) Application and supply-chain cluster
For modern product security teams, **AIS and STA** are the cloud domains that most often intersect with release engineering.
This is where the KB pages on application security, API security, attestation, signing, SBOM, release evidence, and component onboarding are most relevant.
### 5) Resilience and incident cluster
**BCR and SEF** prevent cloud security from becoming a pure prevention-only program. They keep the operating model honest by asking whether the service can recover, whether incidents can be investigated, and whether evidence survives stressful conditions.
### 6) Provider/shared-responsibility cluster
**DCS, HRS, and some parts of UEM/IPY** often sit partly outside app-team ownership. They still belong in the matrix, but many controls are satisfied through platform teams, workforce controls, or provider assurance rather than through one application pipeline.
## Practical operating model for CCM
### Step 1 — define scope by service model
Do not map the entire CCM at once. Start by identifying whether the service is mostly:
* **IaaS-heavy** platform engineering,
* **PaaS-heavy** application hosting,
* **SaaS-heavy** product consumption,
* or a hybrid.
### Step 2 — assign control owners before collecting evidence
For each in-scope domain, assign:
* a **control owner**,
* an **engineering implementation owner**,
* and a **reporting owner**.
If those are all different people, write that down explicitly.
### Step 3 — separate release evidence from recurring operational evidence
A common failure mode is using one evidence type for everything.
Use **release artifacts** for build and deploy controls, and **recurring evidence** for posture, drift, access review, logging coverage, resilience testing, and supplier assurance.
### Step 4 — keep shared responsibility visible
The CCM is strongest when it clarifies who owns what under a shared model.
That means your control matrix should never stop at **"implemented"**. It should also say whether the control is:
* **customer-owned**,
* **provider-owned**,
* or **shared**.
### Step 5 — report by domain, but execute by engineering system
The board or auditor can consume a domain view. The engineering team should consume a workflow view.
That is why this KB keeps deep implementation in engineering sections and uses the CCM mainly as a **translation layer**.
## Use with these pages next
* [Compliance-to-Engineering Evidence Pass](/metrics-audit-risk-evidence-and-compliance/index-1/compliance-to-engineering-evidence-pass.md)
* [Cloud Security Frameworks and Standards — Practical Map](/metrics-audit-risk-evidence-and-compliance/index-1/cloud-security-frameworks-and-standards-practical-map.md)
* [GitLab Release Evidence](/devsecops-cicd-and-supply-chain/index-1/gitlab-release-evidence.md)
* [Cloud Auditing by API and Configuration State](/cloud-kubernetes-and-infrastructure-security/index/cloud-auditing-by-api-and-configuration-state.md)
* [Signing, Attestation, and Verification — Legacy vs Current](/devsecops-cicd-and-supply-chain/index-1/signing-attestation-and-verification-legacy-vs-current.md)
* [Workload Federation and Non-Human Identities](/architecture-api-crypto-and-identity/index-2/workload-federation-and-non-human-identities.md)
## External references
* CSA Cloud Controls Matrix home —
* Cloud Controls Matrix and CAIQ v4.1 —
* Introductory Guidance to CCM —
* CCM Machine Readable Bundle (JSON/YAML/OSCAL) —
* CSA STAR —
***
*Product Security Knowledge Base - v5.1 addendum pass*\
\&#xNAN;*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.product-security.expert/metrics-audit-risk-evidence-and-compliance/index-1/csa-cloud-controls-matrix-ccm-practical-guide.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.