10 CSA Cloud Controls Matrix (CCM)

Modern enterprises increasingly depend on cloud services.

Organizations use:

Infrastructure as a Service

Platform as a Service

Software as a Service

Containers

Kubernetes

Serverless Computing

Cloud Databases

Cloud Storage

Cloud Security Services

This creates an important GRC challenge:

Who Is Responsible
for Security?

Cloud Provider?

Customer?

Both?

Traditional security frameworks provide important security principles, but cloud computing introduces unique risks involving:

Shared Responsibility

Multi-Tenancy

Virtualization

Cloud APIs

Cloud Identity

Data Location

Service Providers

Cloud Supply Chains

Elastic Infrastructure

Automation

The Cloud Security Alliance Cloud Controls Matrix (CCM) provides a cloud-specific control framework designed to address these challenges.

Learning Objectives

By the end of this lesson, you will be able to:

explain the purpose of the CSA Cloud Controls Matrix.
understand how CCM supports cloud security governance.
understand CCM control domains.
understand cloud shared responsibility.
distinguish CSP and customer responsibilities.
understand inherited and shared controls.
use CCM for cloud-provider assessments.
use CCM for SaaS assessments.
understand CAIQ.
understand STAR.
understand cloud assurance concepts.
map CCM controls to enterprise controls.
map CCM requirements to other frameworks.
build a cloud control matrix.
collect cloud security evidence.
evaluate cloud control effectiveness.
identify cloud control gaps.
integrate CCM into third-party risk management.
integrate CCM into cloud architecture reviews.
integrate CCM into continuous compliance.
create cloud GRC dashboards.
build an enterprise cloud governance program.

1. What Is the Cloud Controls Matrix?

The Cloud Controls Matrix, commonly called:

CCM

is developed by the:

Cloud Security Alliance

The CCM provides a structured cybersecurity control framework specifically designed for:

Cloud Computing

Conceptually:

Cloud Risks
      ↓
CSA CCM
      ↓
Cloud Security Controls
      ↓
Implementation
      ↓
Assessment
      ↓
Assurance

2. Why CCM Exists

Cloud computing changes traditional security responsibilities.

In a traditional data center:

Organization
      ↓
Physical Infrastructure
      ↓
Network
      ↓
Servers
      ↓
Operating Systems
      ↓
Applications
      ↓
Data

The organization may control almost everything.

In cloud computing:

Cloud Provider
      +
Customer
      ↓
Shared Security
Responsibility

This requires a framework designed specifically for cloud environments.

3. The Cloud Security Problem

Imagine an organization uses:

AWS

Microsoft Azure

Google Cloud

Microsoft 365

Salesforce

ServiceNow

Security responsibilities are distributed across many providers.

The organization must understand:

What Does
the Provider Secure?

What Must
We Secure?

What Is Shared?

What Evidence
Proves It?

CCM helps structure these questions.

4. CCM Is Cloud-Specific

CCM addresses security topics that are particularly important in cloud environments.

Examples include:

Cloud Governance

Cloud Identity

Virtualization

Cloud Configuration

Data Security

Application Security

Cloud Infrastructure

Logging

Supply Chain

Interoperability

Portability

5. CCM Architecture

Conceptually:

Cloud Security Risks
        ↓
CCM Domains
        ↓
Control Objectives
        ↓
Security Controls
        ↓
Implementation
        ↓
Evidence
        ↓
Assessment
        ↓
Assurance

6. CCM Domains

The CCM organizes controls into multiple cloud-security domains.

Major areas include topics such as:

Audit & Assurance

Application & Interface Security

Business Continuity

Change Control

Cryptography

Data Security & Privacy

Datacenter Security

Governance

Human Resources

Identity & Access Management

Infrastructure & Virtualization

Interoperability & Portability

Logging & Monitoring

Security Incident Management

Supply Chain Management

Threat & Vulnerability Management

Always use the applicable current CCM version when performing a formal assessment.

7. Why Domains Matter

Domains allow organizations to organize cloud controls according to security capability.

Example:

Cloud Environment
      ↓
IAM
      ↓
Identity Controls

Another:

Cloud Workloads
      ↓
Infrastructure Security
      ↓
Configuration Controls

8. Audit & Assurance

Audit and assurance controls help establish:

Independent Assessment

Control Testing

Audit Planning

Evidence

Assurance Reporting

Questions include:

Are Controls Tested?

Who Tests Them?

How Frequently?

Are Findings Remediated?

9. Application Security

Cloud applications must be securely designed and developed.

Controls may address:

Secure Development

Code Review

Application Testing

API Security

Software Dependencies

Secure Deployment

10. Application Security Lifecycle

Design
      ↓
Develop
      ↓
Test
      ↓
Deploy
      ↓
Monitor
      ↓
Improve

Security should exist throughout the lifecycle.

11. API Security

Cloud services depend heavily on APIs.

Risks include:

Weak Authentication

Excessive Permissions

API Abuse

Injection

Data Exposure

Missing Rate Limits

Controls should address:

Authentication

Authorization

Encryption

Logging

Validation

Monitoring

12. Business Continuity

Cloud outages can disrupt critical business services.

Controls should address:

Business Impact Analysis

Backup

Recovery

Resilience

Failover

Continuity Testing

13. Cloud Resilience

Example:

Primary Region
      ↓
Failure
      ↓
Secondary Region
      ↓
Service Recovery

But architecture alone is insufficient.

Organizations should:

Test Recovery

14. Change Management

Cloud environments change rapidly.

Changes may occur through:

Console

API

Terraform

CloudFormation

Bicep

CI/CD

Kubernetes

Controls should ensure changes are:

Authorized

Reviewed

Tested

Recorded

Monitored

15. Infrastructure as Code

Modern cloud governance increasingly depends on:

Infrastructure as Code

Conceptually:

Terraform
      ↓
Security Validation
      ↓
Approval
      ↓
Deployment

This enables security controls before infrastructure reaches production.

16. Cryptography

Cloud environments require strong cryptographic controls.

Areas include:

Encryption at Rest

Encryption in Transit

Key Management

Certificate Management

Key Rotation

Secrets Management

17. Encryption Responsibility

Example:

Cloud Provider
      ↓
Provides Encryption Capability

Customer
      ↓
Enables and Configures Encryption

This demonstrates shared responsibility.

18. Key Management

Organizations should understand:

Who Owns Keys?

Where Are Keys Stored?

Who Can Use Them?

How Are They Rotated?

How Are They Revoked?

19. Data Security

Cloud governance begins with understanding:

What Data
Is in the Cloud?

Data may include:

PII

PHI

Payment Data

Credentials

Financial Data

Intellectual Property

Customer Data

20. Data Lifecycle

Create
      ↓
Store
      ↓
Use
      ↓
Share
      ↓
Archive
      ↓
Destroy

Controls should protect data throughout this lifecycle.

21. Data Classification

Example:

Public

Internal

Confidential

Restricted

Classification can determine:

Encryption

Access

Logging

Retention

Sharing

requirements.

22. Data Location

Cloud services may store data across:

Countries

Regions

Availability Zones

Backup Locations

GRC professionals should understand:

Data Residency

Data Sovereignty

Cross-Border Transfers

23. Data Deletion

Ask:

When Data
Is Deleted

Is It Really
Deleted?

Evaluate:

Primary Storage

Backups

Replicas

Logs

Archives

24. Governance

Cloud governance establishes:

Policies

Roles

Responsibilities

Risk Management

Security Standards

Accountability

Without governance:

Cloud Adoption
      ↓
Uncontrolled Growth
      ↓
Security Drift

25. Cloud Governance Structure

Executive Leadership
      ↓
Cloud Governance
      ↓
Cloud Security
      ↓
Platform Teams
      ↓
Application Teams

26. Human Resources Security

Cloud security also depends on people.

Controls may address:

Background Screening

Security Training

Joiner-Mover-Leaver

Acceptable Use

Termination

Privileged Personnel

27. Joiner-Mover-Leaver

Join
      ↓
Access Granted

Move
      ↓
Access Updated

Leave
      ↓
Access Removed

Cloud access should follow this lifecycle.

28. Identity & Access Management

IAM is one of the most important cloud-security domains.

Controls include:

Authentication

Authorization

MFA

Least Privilege

Privileged Access

Service Accounts

Access Reviews

29. Cloud Identity Model

Identity
      ↓
Authentication
      ↓
Authorization
      ↓
Cloud Resource

30. Least Privilege

Users should receive:

Only the Access
Required
for Their Role

Avoid:

Administrator
for Everyone

31. Privileged Access

Privileged accounts require stronger controls.

Examples:

MFA

PAM

Approval

Logging

Session Monitoring

Periodic Review

32. Service Accounts

Cloud environments often contain:

Service Accounts

Workload Identities

API Keys

Machine Credentials

These identities should be:

Inventoried

Restricted

Rotated

Monitored

33. Infrastructure Security

Cloud infrastructure includes:

Virtual Machines

Containers

Kubernetes

Networks

Storage

Databases

Serverless

Controls should address secure configuration.

34. Cloud Configuration

Common risks include:

Public Storage

Open Firewall Rules

Excessive IAM

Unencrypted Databases

Disabled Logging

Public Management Ports

35. Secure Configuration Baseline

Define:

Approved
Cloud Configuration

Then continuously compare:

Actual Configuration
      ↓
Security Baseline
      ↓
Deviation

36. Virtualization

Cloud infrastructure relies heavily on virtualization.

Security concerns may include:

Isolation

Hypervisor Security

Tenant Separation

Virtual Networks

Virtual Storage

Customers typically inherit significant portions of these controls from infrastructure providers.

37. Container Security

Container environments introduce:

Image Risk

Registry Risk

Runtime Risk

Secrets

Privileges

Vulnerabilities

Controls should cover the full container lifecycle.

38. Kubernetes Security

Important areas include:

RBAC

Network Policies

Secrets

Pod Security

Admission Control

Audit Logging

Runtime Monitoring

39. Interoperability

Organizations should understand whether cloud systems can:

Exchange Data

Integrate Securely

Use Standard Interfaces

Poor interoperability can create:

Security Gaps

Manual Processes

Vendor Dependency

40. Portability

Portability addresses the ability to move:

Data

Applications

Workloads

between environments.

This matters for:

Business Continuity

Vendor Exit

Concentration Risk

41. Vendor Lock-In

Ask:

Can We
Leave the Provider?

Consider:

Data Export

Migration

Data Format

Contract Terms

Deletion

Cost

42. Logging & Monitoring

Cloud environments generate enormous telemetry.

Examples:

Authentication Logs

API Logs

Network Logs

Application Logs

Cloud Audit Logs

Security Alerts

43. Centralized Logging

A mature architecture may use:

Cloud Accounts
      ↓
Central Logging
      ↓
SIEM
      ↓
Detection
      ↓
SOC

44. Logging Coverage

Track:

Resources
Sending Logs
────────────── × 100
In-Scope Resources

45. Security Incident Management

Cloud incident-response controls should address:

Detection

Triage

Containment

Investigation

Recovery

Notification

Lessons Learned

46. Cloud Incident Example

Compromised
Cloud Credential
      ↓
Unauthorized API Calls
      ↓
Detection
      ↓
Credential Revocation
      ↓
Investigation
      ↓
Recovery

47. Cloud Forensics

Organizations should prepare for:

Log Collection

Snapshot Collection

Cloud Audit Trails

Identity Investigation

Timeline Reconstruction

before incidents occur.

48. Supply Chain Management

Cloud providers depend on:

Subprocessors

Infrastructure Providers

Software Vendors

Managed Services

Open-Source Software

This creates:

Fourth-Party Risk

49. Cloud Supply Chain

Customer
      ↓
SaaS Provider
      ↓
Cloud Provider
      ↓
Technology Vendors
      ↓
Subprocessors

Risk can exist at every layer.

50. Vendor Dependency Mapping

Maintain:

Vendor

Service

Data

Access

Criticality

Subprocessors

Assurance

51. Threat & Vulnerability Management

Cloud environments should continuously identify:

Vulnerabilities

Misconfigurations

Threats

Exposures

52. Vulnerability Sources

Examples:

VM Scanning

Container Scanning

Dependency Scanning

Cloud Security Posture

Application Testing

Penetration Testing

53. Vulnerability Lifecycle

Discover
      ↓
Prioritize
      ↓
Assign
      ↓
Remediate
      ↓
Retest
      ↓
Close

54. Cloud Shared Responsibility

One of the most important CCM concepts is understanding:

Shared
Responsibility

Cloud providers and customers have different security responsibilities.

55. Traditional Environment

Customer

Data
Application
Operating System
Network
Servers
Storage
Physical Facility

Customer controls nearly everything.

56. IaaS Responsibility

Conceptually:

Customer

Data
Applications
Operating Systems
Configuration
Identity

────────────

Provider

Virtualization
Physical Infrastructure
Datacenter

Exact responsibilities depend on the service.

57. PaaS Responsibility

Customer

Data
Applications
Identity
Configuration

────────────

Provider

Runtime
Operating System
Infrastructure
Physical Environment

58. SaaS Responsibility

Customer

Users
Data
Access
Configuration

────────────

Provider

Application
Platform
Infrastructure
Physical Environment

Again, actual responsibilities vary by service.

59. Responsibility Matrix

Maintain:

Control	CSP	Customer	Shared	Inherited
Physical Security	✓
User Access Approval		✓
Encryption			✓
Hypervisor				✓
Logging Configuration			✓

60. Why Responsibility Mapping Matters

Without it:

Provider Assumes
Customer Handles It

Customer Assumes
Provider Handles It
      ↓
Nobody Handles It

This creates:

Control Gap

61. Inherited Controls

An organization may inherit controls from its provider.

Example:

SaaS Provider
      ↓
AWS
      ↓
Physical Security

But inheritance should be:

Documented

Validated

Monitored

62. Shared Controls

Example:

Provider
Provides Encryption
      +
Customer
Configures Encryption

Both contribute to the security outcome.

63. Cloud Provider Assessment

CCM can be used to evaluate:

AWS

Azure

Google Cloud

SaaS Providers

PaaS Providers

Managed Cloud Services

64. Provider Assessment Workflow

Identify Provider
      ↓
Determine Service
      ↓
Assess Criticality
      ↓
Identify CCM Controls
      ↓
Collect Evidence
      ↓
Evaluate Gaps
      ↓
Determine Risk

65. CAIQ

CSA also provides the:

Consensus Assessments
Initiative Questionnaire

commonly called:

CAIQ

CAIQ helps organizations gather information about cloud-provider security practices.

66. CAIQ Purpose

Instead of asking:

Is Your Cloud Secure?

CAIQ enables structured questions covering cloud-security controls.

Conceptually:

CCM Controls
      ↓
CAIQ Questions
      ↓
Provider Responses
      ↓
Assessment

67. CAIQ in Vendor Risk

Example workflow:

New SaaS Vendor
      ↓
Criticality Assessment
      ↓
CAIQ
      ↓
Evidence
      ↓
Security Review
      ↓
Risk Decision

68. Questionnaire Alone Is Not Enough

Vendor says:

Yes

to every security question.

That is:

Assertion

not necessarily:

Assurance

69. Validate Responses

High-risk controls may require:

Policy

Configuration

SOC Report

ISO Certificate

Penetration Test

Architecture

Independent Assessment

70. CSA STAR

CSA also maintains the:

Security, Trust,
Assurance and Risk

or:

STAR

program.

STAR provides mechanisms for cloud providers to communicate security and assurance information.

71. STAR Concept

Cloud Provider
      ↓
Security Information
      ↓
Transparency
      ↓
Customer Assurance

72. Why STAR Matters

Organizations evaluating cloud providers can use available assurance information to better understand:

Security Practices

Control Coverage

Assessment

Transparency

73. Vendor Assurance Hierarchy

Conceptually:

Questionnaire
      ↓
Supporting Evidence
      ↓
Independent Assurance
      ↓
Continuous Monitoring

Higher-risk providers generally require stronger assurance.

74. Evidence Sources

Possible cloud-provider evidence includes:

CAIQ

STAR Information

SOC Reports

ISO Certificates

Penetration Tests

Policies

Architecture

Security Documentation

Configuration Evidence

75. Evidence Validation

For every artifact ask:

Correct Provider?

Correct Service?

Correct Scope?

Current?

Relevant?

Independent?

76. Example — SOC 2

Vendor provides:

SOC 2 Report

Check:

Service Covered?

Period?

Exceptions?

Subservice Organizations?

Relevant Controls?

77. Example — ISO 27001

Vendor provides:

ISO 27001 Certificate

Check:

Certification Scope

Locations

Services

Validity

Certification Body

78. CCM Control Mapping

CCM can support mappings to other security frameworks.

Conceptually:

CCM Control
      ↓
Enterprise Control
      ↓
ISO 27001
      ↓
NIST
      ↓
SOC 2
      ↓
PCI DSS

79. Why Mapping Matters

Without mapping:

Cloud Assessment

ISO Assessment

SOC Assessment

NIST Assessment

may repeatedly test the same security capability.

With common controls:

Enterprise Control
      ↓
One Implementation
      ↓
Multiple Frameworks

80. Common Control Example

Enterprise control:

IAM-001
Privileged MFA

supports:

CSA CCM

ISO 27001

NIST

SOC 2

PCI DSS

where mappings and scope are appropriate.

81. Enterprise Cloud Control Framework

Build:

Cloud Risks
      ↓
CSA CCM
      ↓
Enterprise Controls
      ↓
Cloud Standards
      ↓
Technical Guardrails

82. Cloud Standard

Example:

Cloud Storage
Security Standard

Requirements:

No Public Access

Encryption Required

Logging Enabled

Approved Region

Backup Required

83. Technical Guardrail

Turn requirements into automated controls.

Example:

Public Storage
Detected
      ↓
Block Deployment

84. Preventive Controls

Examples:

IAM Policy Restrictions

Organization Policies

Service Control Policies

Policy-as-Code

Admission Controls

85. Detective Controls

Examples:

CSPM

SIEM

Cloud Audit Logs

Configuration Monitoring

Security Alerts

86. Corrective Controls

Examples:

Automated Remediation

Ticket Creation

Resource Isolation

Credential Revocation

87. Cloud Control Lifecycle

Requirement
      ↓
Control
      ↓
Technical Standard
      ↓
Implementation
      ↓
Monitoring
      ↓
Evidence
      ↓
Assessment

88. Cloud Evidence Automation

Instead of manually collecting:

Screenshots

use:

Cloud APIs

Configuration Exports

Automated Reports

Security Platforms

where appropriate.

89. Example — Storage Encryption

Requirement:

Cloud Storage
Must Be Encrypted

Automated evidence:

Cloud API
      ↓
Enumerate Storage
      ↓
Encryption Status
      ↓
Evidence Report

90. Example — MFA

Identity API
      ↓
Enumerate Admins
      ↓
Check MFA
      ↓
Coverage Report

91. Example — Logging

Cloud Inventory
      ↓
In-Scope Resources
      ↓
Logging Enabled?
      ↓
Logs Received?
      ↓
Coverage

92. Continuous Cloud Compliance

Traditional:

Annual Assessment

Cloud:

Infrastructure
Changes Daily

Therefore:

Continuous
Compliance

becomes important.

93. Continuous Compliance Model

Cloud Inventory
      ↓
Control Tests
      ↓
Configuration Monitoring
      ↓
Evidence
      ↓
Exceptions
      ↓
Remediation

94. Control Drift

Example:

Monday:

Database
Private

Tuesday:

Database
Public

Annual assessment may not detect the problem quickly enough.

Continuous monitoring can.

95. Cloud Security Posture Management

CSPM tools can help identify:

Misconfiguration

Public Exposure

Weak IAM

Encryption Gaps

Logging Gaps

Policy Violations

96. Cloud-Native Controls

Cloud providers also provide native capabilities for:

Configuration Monitoring

Threat Detection

IAM Analysis

Logging

Encryption

Vulnerability Management

These can support CCM control implementation.

97. Multi-Cloud Governance

Many enterprises use:

AWS

Azure

Google Cloud

SaaS

A common control model helps maintain consistent requirements.

Enterprise Cloud Controls
        ↓
AWS
Azure
GCP
SaaS

98. Cloud Control Abstraction

Instead of:

AWS Requirement

Azure Requirement

GCP Requirement

define:

Enterprise Requirement:
Privileged Access
Requires MFA

Then implement it appropriately in each platform.

99. Cloud Risk Register

Track risks such as:

Public Storage

Weak IAM

Unencrypted Data

Unsupported Workloads

Shadow Cloud

Vendor Concentration

Missing Logging

100. Cloud Risk Record

Example:

Risk:
Public Cloud Storage

Impact:
Sensitive Data Exposure

Likelihood:
Possible

Control:
Storage Access Policy

Owner:
Cloud Security

Treatment:
Prevent Public Access

101. Cloud Exceptions

Sometimes workloads cannot meet a standard.

Exceptions should contain:

Requirement

Reason

Risk

Compensating Control

Owner

Approval

Expiration

102. Exceptions Must Expire

Avoid:

Permanent
Security Exception

Better:

Exception
      ↓
Expiration
      ↓
Review
      ↓
Remediate / Renew

103. Cloud Security Dashboard

Example:

CLOUD CONTROL HEALTH

Cloud Accounts                125

Critical Misconfigurations      7

High-Risk IAM Findings          9

Public Resources                3

Encryption Coverage          99.6%

Logging Coverage             98.9%

Open Exceptions                14

Illustrative values only.

104. CCM Assessment Dashboard

Track:

Applicable Controls

Implemented

Partial

Not Implemented

Evidence Missing

Exceptions

Findings

105. Vendor Cloud Dashboard

Track:

Critical Cloud Vendors

CAIQ Completed

Independent Assurance

Open Findings

Expired Evidence

High-Risk Vendors

106. Executive Cloud Reporting

Executives need:

What Cloud Risks Matter?

Which Providers
Create Concentration Risk?

Where Is Sensitive Data?

Which Controls
Are Failing?

What Is Exposed?

What Is Overdue?

What Decisions
Are Required?

107. Cloud Governance Committee

Possible members:

Cloud Security

Enterprise Architecture

GRC

Engineering

Privacy

Legal

Procurement

Risk

Operations

108. Cloud Governance Review

Review:

Cloud Risk

New Providers

Architecture Exceptions

Control Failures

Compliance

Incidents

Major Changes

109. Cloud Onboarding

Before onboarding a new cloud service:

Business Need
      ↓
Data Classification
      ↓
Risk Tier
      ↓
Security Assessment
      ↓
CCM / CAIQ
      ↓
Architecture Review
      ↓
Contract Review
      ↓
Approval

110. Cloud Vendor Risk Tiering

Example:

Tier 1

Sensitive Data

Critical Service

Privileged Access

Requires strongest assessment.

Tier 2

Internal Data

Important Service

Requires moderate assessment.

Tier 3

Low-Risk Data

Noncritical Service

May use lighter assessment.

111. CCM in Third-Party Risk

CCM can strengthen TPRM by providing:

Cloud-Specific
Security Requirements

rather than generic vendor questionnaires.

112. CCM in Architecture Review

Cloud architects can map proposed designs against:

CCM Controls

before deployment.

113. CCM in DevSecOps

CCM Requirement
      ↓
Technical Policy
      ↓
CI/CD Security Check
      ↓
Deployment Decision

114. Example — Public Storage

CCM requirement:

Protect Cloud Data

Technical rule:

Storage Must
Not Be Public

CI/CD:

Terraform
      ↓
Policy Check
      ↓
Public?
      ↓
BLOCK

115. Example — Encryption

CCM
      ↓
Encryption Requirement
      ↓
IaC Policy
      ↓
Encryption Disabled?
      ↓
BLOCK

116. Example — Logging

CCM
      ↓
Logging Requirement
      ↓
Cloud Policy
      ↓
Logging Disabled?
      ↓
Alert / Remediate

117. CCM in Internal Audit

Internal Audit can use CCM to assess:

Cloud Governance

Cloud Provider Risk

Cloud Configuration

IAM

Data Protection

Logging

Resilience

118. Audit Evidence

Auditors may examine:

Cloud Policies

Architecture

Configurations

CAIQ

SOC Reports

Cloud Logs

CSPM Reports

Risk Registers

119. CCM in Continuous Monitoring

Controls suitable for automation include:

Encryption

MFA

Public Exposure

Logging

Vulnerability Status

Configuration

Asset Inventory

120. Cloud Compliance Calendar

Track recurring activities:

Vendor Reviews

Access Reviews

Evidence Refresh

Recovery Tests

Penetration Tests

Certificate Expiration

Exception Reviews

Control Assessments

121. Common Mistake — Provider Is Secure, Therefore We Are Secure

Incorrect:

Cloud Provider
Secure
      =
Customer Secure

Correct:

Provider Security
      +
Customer Configuration
      +
Customer Governance
      =
Cloud Security

122. Common Mistake — Assume Everything Is Inherited

Cloud customers still own significant responsibilities.

Especially:

Identity

Data

Configuration

Application Security

User Access

123. Common Mistake — Generic Vendor Questionnaire

A generic questionnaire may miss cloud-specific issues such as:

Tenant Isolation

Cloud APIs

Data Residency

Portability

Virtualization

Shared Responsibility

124. Common Mistake — Accept Yes/No Answers

Question:

Do You Encrypt Data?

Vendor:

Yes

GRC should ask:

Which Data?

Where?

Which Algorithm?

Who Manages Keys?

What Evidence?

125. Common Mistake — Ignore Service Scope

Vendor may provide assurance for:

Product A

while the organization uses:

Product B

Always validate scope.

126. Common Mistake — Ignore Subprocessors

Your SaaS provider may rely on:

Cloud Provider

Email Provider

Analytics Provider

Support Provider

These create additional risk.

127. Common Mistake — Annual Cloud Review Only

Cloud changes too quickly.

Better:

Continuous Monitoring

128. Common Mistake — Manual Evidence Everywhere

Manual evidence creates:

Stale Evidence

Human Error

Assessment Effort

Slow Detection

Automate high-value evidence where practical.

129. Common Mistake — No Exit Strategy

Organizations should understand:

How Do We
Leave the Provider?

before critical dependency develops.

130. Common Mistake — No Cloud Inventory

You cannot govern:

Cloud Services
You Do Not Know Exist

131. Shadow Cloud

Employees may adopt cloud services without formal approval.

This creates:

Unknown Data

Unknown Vendors

Unknown Controls

Unknown Risk

132. Cloud Discovery

Use:

Procurement

SSO

CASB

Expense Data

Network Data

Vendor Inventory

to identify cloud services.

133. End-to-End Example — SaaS Assessment

Organization wants to purchase:

HR SaaS Platform

The service will process:

Employee PII

134. Step 1 — Risk Tier

Because sensitive employee data is involved:

High-Risk
Cloud Vendor

135. Step 2 — CCM Scope

Relevant domains include:

IAM

Data Security

Cryptography

Logging

Incident Management

Business Continuity

Supply Chain

136. Step 3 — CAIQ

Send appropriate cloud-security assessment questions.

137. Step 4 — Evidence

Vendor provides:

CAIQ

SOC 2

ISO 27001

Penetration Test Summary

Architecture

BCP Evidence

138. Step 5 — Validate

GRC verifies:

Scope

Period

Service

Exceptions

Subprocessors

Control Coverage

139. Step 6 — Identify Gaps

Example:

MFA
Ready

Encryption
Ready

Logging
Ready

Recovery Testing
Partial

Subprocessor Monitoring
Weak

140. Step 7 — Risk Treatment

Possible actions:

Accept

Mitigate

Contractually Require

Monitor

Reject

141. Step 8 — Contract

Security requirements may include:

Incident Notification

Encryption

Subprocessor Notification

Audit Rights

Data Deletion

Business Continuity

142. Step 9 — Continuous Monitoring

After onboarding:

Assurance Expiration

Security Incidents

Vendor Changes

Subprocessors

Control Findings

Financial Health

should be monitored.

143. End-to-End Example — AWS Workload

Application:

Customer Portal

Environment:

AWS

Data:

Customer PII

144. CCM Requirement — IAM

Enterprise standard:

Privileged Access
Requires MFA

Implementation:

AWS IAM Identity Center
+
MFA

Evidence:

Identity Report

145. CCM Requirement — Data Security

Requirement:

Sensitive Data
Encrypted

Implementation:

Storage Encryption

Database Encryption

TLS

146. CCM Requirement — Logging

Implementation:

CloudTrail
      ↓
Central Logging
      ↓
SIEM

147. CCM Requirement — Configuration

Implementation:

AWS Config
      ↓
Security Rules
      ↓
Findings

148. CCM Requirement — Threat Detection

Implementation:

Cloud Security
Telemetry
      ↓
Threat Detection
      ↓
SOC

149. Continuous Assurance

Cloud APIs
      ↓
Automated Tests
      ↓
Control Health
      ↓
Evidence
      ↓
GRC Dashboard

150. Enterprise CCM Operating Model

Enterprise Risk
      ↓
Cloud Governance
      ↓
CSA CCM
      ↓
Enterprise Cloud Controls
      ↓
Cloud Standards
      ↓
Technical Guardrails
      ↓
AWS / Azure / GCP / SaaS
      ↓
Continuous Monitoring
      ↓
Evidence
      ↓
Assurance

CCM Implementation Roadmap

A practical enterprise implementation can follow:

Phase 1
Cloud Inventory

Phase 2
Risk Classification

Phase 3
CCM Applicability

Phase 4
Control Mapping

Phase 5
Responsibility Mapping

Phase 6
Technical Standards

Phase 7
Evidence

Phase 8
Assessment

Phase 9
Remediation

Phase 10
Continuous Monitoring

Phase 1 — Cloud Inventory

Identify:

IaaS

PaaS

SaaS

Cloud Accounts

Cloud Providers

Critical Services

Phase 2 — Risk Classification

Classify according to:

Data

Criticality

Access

Business Impact

Regulation

Phase 3 — CCM Applicability

Determine which CCM controls apply to each environment.

Phase 4 — Control Mapping

Map:

CCM
      ↓
Enterprise Controls
      ↓
Other Frameworks

Phase 5 — Responsibility Mapping

Classify:

Provider

Customer

Shared

Inherited

Phase 6 — Technical Standards

Translate controls into:

Cloud Security
Standards

Phase 7 — Evidence

Identify:

Evidence Source

Owner

Frequency

Automation

Phase 8 — Assessment

Evaluate:

Design

Implementation

Operation

Phase 9 — Remediation

Track:

Finding

Risk

Owner

Action

Deadline

Validation

Phase 10 — Continuous Monitoring

Automate where possible:

Configuration

Identity

Encryption

Logging

Vulnerabilities

Assets

CSA CCM Readiness Checklist

Governance

cloud governance model defined.
executive ownership established.
cloud security policy approved.
CCM version identified.
roles and responsibilities assigned.

Cloud Inventory

IaaS providers identified.
PaaS providers identified.
SaaS providers identified.
cloud accounts identified.
critical workloads identified.
shadow cloud discovery established.

Data

cloud data classified.
sensitive data identified.
residency requirements identified.
encryption requirements defined.
retention requirements defined.
deletion requirements defined.

Shared Responsibility

CSP responsibilities documented.
customer responsibilities documented.
shared controls identified.
inherited controls identified.
responsibility gaps resolved.

IAM

MFA implemented.
privileged access controlled.
least privilege implemented.
service accounts inventoried.
access reviews established.
joiner-mover-leaver process established.

Infrastructure

secure baselines defined.
public exposure monitored.
network controls implemented.
container security implemented.
Kubernetes security implemented.
configuration drift monitored.

Logging

cloud audit logging enabled.
centralized logging implemented.
SIEM integration established.
logging coverage measured.
retention defined.

Vulnerability Management

cloud workloads scanned.
containers scanned.
dependencies scanned.
findings risk-ranked.
remediation tracked.
exceptions governed.

Vendor Assurance

cloud vendors risk-tiered.
CAIQ used where appropriate.
assurance evidence collected.
scope validated.
subprocessors reviewed.
recurring reviews established.

Continuous Compliance

automated cloud inventory established.
control tests automated where practical.
evidence automated.
configuration drift detected.
exceptions monitored.
dashboards established.

CSA CCM Deliverables

After completing this lesson, you should be able to create:

01 Cloud Governance Strategy

02 Cloud Service Inventory

03 Cloud Risk Classification Model

04 CSA CCM Applicability Matrix

05 Cloud Control Matrix

06 Shared Responsibility Matrix

07 Cloud Control Ownership Matrix

08 Cloud Security Standards

09 Cloud Evidence Catalogue

10 CAIQ Assessment Tracker

11 Cloud Provider Assessment

12 Cloud Assurance Register

13 Cloud Vendor Risk Register

14 Cloud Subprocessor Register

15 Cloud Configuration Baseline

16 Cloud IAM Review

17 Cloud Data Protection Assessment

18 Cloud Logging Assessment

19 Cloud Vulnerability Register

20 Cloud Exception Register

21 Cloud Control Mapping

22 Continuous Cloud Compliance Plan

23 Cloud Control Health Dashboard

24 Cloud Vendor Dashboard

25 Executive Cloud Risk Dashboard

Practical Activity — Build a Shared Responsibility Matrix

Scenario:

Organization Uses:

AWS

Microsoft 365

Salesforce

For each environment identify:

Provider Responsibilities

Customer Responsibilities

Shared Responsibilities

Inherited Controls

Cover at minimum:

Physical Security

IAM

Encryption

Logging

Backup

Vulnerability Management

Incident Response

Practical Activity — Assess a SaaS Provider

Scenario:

Vendor:
HR SaaS Provider

Data:
Employee PII

Criticality:
High

Evaluate the vendor using relevant CCM domains.

Request:

CAIQ

SOC 2

ISO 27001

Penetration Testing

BCP / DR Evidence

Subprocessor Information

Identify:

Control Gaps

Evidence Gaps

Residual Risk

Required Remediation

Practical Activity — Build a Cloud Control Matrix

Create:

CCM Area	Enterprise Control	Owner	Evidence	Responsibility
IAM	MFA	IAM	MFA Report	Shared
Data	Encryption	Cloud Security	Config	Shared
Logging	Audit Logging	SOC	SIEM	Customer
Infrastructure	Secure Baseline	Cloud	CSPM	Customer
Continuity	Recovery	IT	Test	Shared

Expand the matrix for your organization.

Practical Activity — Continuous Cloud Compliance

Select:

MFA

Encryption

Public Storage

Logging

Vulnerabilities

Cloud Inventory

For each define:

Control

Cloud Source

Test

Frequency

Threshold

Owner

Evidence

Remediation

Practical Activity — Cloud Vendor Exit

For a critical SaaS provider, document:

Data Export

Data Format

Migration

Backup

Deletion

Contract Termination

Subprocessor Deletion

Evidence of Destruction

Identify any vendor-lock-in risks.

CCM GRC Mindset

When evaluating cloud environments, ask:

Which Cloud Services
Do We Use?

Which Are Critical?

What Data
Do They Process?

Where Is
the Data Stored?

Who Owns
the Data?

Who Can
Access It?

Who Is
Responsible
for Security?

What Does
the Provider Own?

What Does
the Customer Own?

What Is Shared?

What Is Inherited?

Are Responsibilities
Documented?

Could Any Control
Fall Between
Provider and Customer?

Which CCM Controls
Apply?

How Are They
Implemented?

Who Owns
Each Control?

What Evidence
Proves It?

Does Evidence
Cover the Correct
Cloud Service?

Does Assurance
Cover the Product
We Actually Use?

Is the Evidence
Current?

Is the Provider
Using Subprocessors?

Who Are They?

What Data
Do They Receive?

How Is
Tenant Isolation
Maintained?

How Is
Privileged Access
Controlled?

Is MFA
Required?

How Are
Service Accounts
Managed?

Is Sensitive Data
Encrypted?

Who Controls
Encryption Keys?

Where Are
the Keys Stored?

Where Is
Data Located?

How Is
Data Deleted?

Are Cloud APIs
Protected?

Are Applications
Securely Developed?

Are Cloud
Configurations Secure?

Are Public Resources
Detected?

Are Containers
Scanned?

Is Kubernetes
Securely Configured?

Are Logs
Centralized?

Can Security Events
Be Investigated?

Can We
Recover the Service?

Has Recovery
Actually Been Tested?

How Are
Vulnerabilities Managed?

How Are
Security Exceptions
Governed?

Can Cloud Controls
Be Tested Automatically?

Can Evidence
Be Generated Automatically?

Can CCM Controls
Map to ISO,
NIST, SOC 2,
PCI DSS,
and HITRUST?

What Happens
When the Provider
Changes?

What Happens
When a New
Subprocessor Is Added?

What Happens
When a Control Fails?

Can We
Leave the Provider?

Can We
Recover Our Data?

Can We
Prove Data Was Deleted?

Are We Simply
Using Cloud Services?

Or Are We
Governing Cloud Risk?

That is the mindset of a GRC professional using the CSA Cloud Controls Matrix.

Key Takeaways

The CSA Cloud Controls Matrix is designed specifically for cloud security.
CCM helps organizations translate cloud risks into structured security controls.
Shared responsibility is fundamental to cloud governance.
Security responsibilities differ across IaaS, PaaS, and SaaS.
Controls can be provider-owned, customer-owned, shared, or inherited.
Responsibility mapping prevents controls from falling between organizations.
CCM addresses governance, IAM, data protection, cryptography, infrastructure, logging, resilience, incident response, supply chain, and vulnerability management.
CAIQ provides structured cloud-security assessment questions.
Questionnaire responses should be supported with evidence when risk warrants it.
CSA STAR supports cloud-security transparency and assurance.
Vendor assurance must be evaluated against the actual service and scope being used.
Cloud-provider subprocessors introduce fourth-party risk.
Data residency, portability, deletion, and vendor exit are important cloud-governance considerations.
CCM can strengthen third-party cloud-provider assessments.
CCM can also support architecture review, internal audit, DevSecOps, and continuous compliance.
Cloud controls should be translated into enterprise technical standards.
Technical guardrails can prevent insecure cloud configurations.
Infrastructure as Code enables preventive compliance checks.
Cloud APIs can automate control evidence.
Continuous monitoring is more appropriate for rapidly changing cloud environments than annual assessment alone.
Cloud configuration drift should be detected quickly.
Multi-cloud organizations benefit from provider-neutral enterprise control objectives.
CCM can map into broader enterprise common-control frameworks.
A mature cloud GRC program combines governance, architecture, security engineering, vendor risk, continuous monitoring, and assurance.

Knowledge Check

Before continuing, make sure you can answer:

What is the CSA Cloud Controls Matrix?
Why was CCM created?
Why are cloud-specific controls necessary?
What is shared responsibility?
How does responsibility differ between IaaS, PaaS, and SaaS?
What is a provider-owned control?
What is a customer-owned control?
What is a shared control?
What is an inherited control?
Why should responsibility matrices be maintained?
What is CAIQ?
How can CAIQ support vendor risk assessments?
Why are questionnaire answers alone insufficient for high-risk vendors?
What is CSA STAR?
How can STAR support cloud assurance?
Why should assurance scope be validated?
Why are subprocessors important?
What is fourth-party cloud risk?
Why is data classification important?
What is data residency?
What is data sovereignty?
Why is cloud data deletion important?
What are cloud encryption responsibilities?
Why is key management important?
Why is IAM critical in cloud environments?
How should service accounts be governed?
What are common cloud misconfigurations?
What is configuration drift?
What is a secure cloud baseline?
Why is centralized cloud logging important?
What is cloud logging coverage?
Why does cloud incident response require preparation?
What is cloud portability?
What is vendor lock-in?
Why should organizations maintain a cloud exit strategy?
How can CCM support TPRM?
How can CCM support architecture reviews?
How can CCM support DevSecOps?
What is policy-as-code?
What are preventive cloud controls?
What are detective cloud controls?
What are corrective cloud controls?
What is continuous cloud compliance?
How can cloud APIs automate evidence?
What is cloud control health?
Why should cloud vendors be risk-tiered?
How can CCM map to other frameworks?
What is a common cloud-control framework?
Why is cloud inventory essential?
What makes an enterprise cloud-governance program effective?

What’s Next?

➡️ Next: 11 — SWIFT CSCF & Financial Services Security

In the next lesson, you will move from general cloud-security governance using CSA CCM into the highly controlled world of financial-services cybersecurity and payment infrastructure protection.

You will learn how security governance applies to:

Financial Institutions
      ↓
Payment Infrastructure
      ↓
SWIFT Environment
      ↓
Critical Systems
      ↓
Security Controls
      ↓
Independent Assessment
      ↓
Risk Management
      ↓
Continuous Assurance

We will explore:

SWIFT Customer Security
Controls Framework

Customer Security Programme

SWIFT Architecture

Secure Zones

Privileged Access

Multi-Factor Authentication

Transaction Integrity

Logging & Monitoring

Vulnerability Management

Incident Response

Security Attestation

Independent Assessment

Financial Services
Third-Party Risk

Operational Resilience

and connect these concepts with:

ISO 27001

NIST

PCI DSS

SOC

Cloud Security

Third-Party Risk

Internal Audit

Enterprise GRC

➡️ Next: 11 — SWIFT CSCF & Financial Services Security