PS Product SecurityKnowledge Base

☁️ CSA Cloud Controls Matrix (CCM) — Practical Guide for Product and Cloud Security

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, Board-Ready Product Security Reporting Pages, Compliance-to-Engineering Evidence Pass release evidence JSON, audit-ready control matrices, exception register, quarterly scorecards
AIS — Application & Interface Security application-layer and interface-facing controls Application Security, API Security 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, Annual Product Security Report for Stakeholders 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, Cloud Auditing by API and Configuration State, Infrastructure as Code Maturity and Test Strategy 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, Secret Management on HashiCorp Vault, Mozilla SOPS 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, Cloud Security Across AWS, Azure, and GCP 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, Log Redaction, Backups, and Privacy by Design 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, Policy Exception Governance Pack 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, JIT, PAM, Break-Glass, and Admin Access joiner/mover/leaver evidence, privileged-access training, offboarding checklists
IAM — Identity & Access Management human and machine access design AWS IAM and Role Design, Workload Federation and Non-Human Identities, JIT, PAM, Break-Glass, and Admin Access 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, Zero-Trust Egress and Private Connectivity Patterns 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, Container and Kubernetes Security 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, Cloud Audit Cookbook by Provider 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, Runtime Investigation Playbook 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, Signing, Attestation, and Verification, Vendor Agents, Runners, and Build Integration Trust Boundaries SBOMs, provenance, attestations, vendor questionnaires, signature verification results
TVM — Threat & Vulnerability Management discovery, triage, prioritization, and reduction of exploitable weaknesses SAST Noise Reduction, Terraform Security Scanning and Checkov, Kubernetes Top 10 Misconfigurations scanner outputs, prioritized backlog, remediation aging, exception decisions
UEM — Universal Endpoint Management endpoint governance for admin, developer, and managed device surfaces Developer Workstation Hardening, JIT, PAM, Break-Glass, and Admin Access 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

External references

Product Security Knowledge Base - v5.1 addendum pass
Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.