Study guide
3.3 Cloud Governance Operating Models & CCM Control Implementation
Certificate of Cloud Security Knowledge CCSK v5
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CCSK Exam Overview & CSA Security Frameworks
1.1 CCSK v5 Exam Structure, Logistics & Open-Book Strategy 1.2 CCSK v5 Source Hierarchy & CSA Cloud Architecture 1.3 CSA Assurance Tools: CCM v4.1, CAIQ v4.1 & the STAR Registry
2 Chapter 2: Cloud Computing Concepts & Architectures
2.1 Cloud Definition, Essential Characteristics & ISO/IEC Standards 2.2 Cloud Service Models (IaaS, PaaS, SaaS) & Abstraction Layers 2.3 Cloud Deployment Models & Shared Responsibility in Practice
3 Chapter 3: Cloud Governance
3.1 Enterprise Governance, Cloud Strategy & Policy Frameworks 3.2 Contracts, Service Level Agreements (SLAs) & Vendor Due Diligence 3.3 Cloud Governance Operating Models & CCM Control Implementation
4 Chapter 4: Risk, Audit, & Compliance
4.1 Cloud Risk Management, Risk Tolerance & Shared Risk Profiles 4.2 Audit Principles, Assurance Inheritance & Third-Party Reports (SOC & ISO) 4.3 Compliance Assessment, Continuous Auditing & Regulatory Mandates
5 Chapter 5: Organization Management
5.1 Cloud Center of Excellence (CCoE) & Organizational Design 5.2 Cloud Vendor Management, Supply Chain Risk & Multi-Cloud Operations 5.3 Cloud Financial Governance (FinOps), Business Continuity & People 5.4 Provider Organization Hierarchies, Identity Mapping & Shared Services
6 Chapter 6: Identity & Access Management
6.1 Cloud IAM Architecture: Authentication, Authorization & RBAC vs. ABAC 6.2 Identity Federation: SAML 2.0, OpenID Connect, OAuth 2.0 & SCIM 6.3 Privileged Access Management (PAM), CIEM & Cloud Secrets Lifecycle
7 Chapter 7: Security Monitoring
7.1 Cloud Telemetry Architecture, Audit Logging & Control Plane Trails 7.2 Cloud Security Posture Management (CSPM) & Configuration Baselining 7.3 Centralized SIEM/SOAR Integration, Cloud Detection and Response (CDR) 7.4 Cloud Telemetry Sources, Collection Architecture & Retention 7.5 AI for Security Monitoring: Use Cases, Risks & Governance
8 Chapter 8: Infrastructure & Networking
8.1 Virtualization Foundations, Hypervisors & Multi-Tenant Isolation 8.2 Cloud Virtual Networks, Subnetting, Security Groups & Microsegmentation 8.3 Hybrid Connectivity, Software-Defined Perimeters (SDP) & DDoS/WAF Defense 8.4 Infrastructure as Code Security, Policy Gates & Drift Control
9 Chapter 9: Cloud Workload Security
9.1 Virtual Machine (VM) Hardening, Golden Images & Immutable Infrastructure 9.2 Container Security: Image Scanning, Registries & Runtime Defense 9.3 Kubernetes Orchestration Security, Serverless (FaaS) & CWPP/CNAPP 9.4 Cloud Workload Types, Security Boundaries & Control Substitution
10 Chapter 10: Data Security
10.1 Cloud Data Lifecycle (CSU-SAD) & Data Discovery/Classification 10.2 Cloud Cryptography: Data at Rest, In Transit (TLS 1.3) & In Use (Confidential Computing) 10.3 Key Management Systems (KMS), HSMs, BYOK/HYOK & Cloud DLP 10.4 Cloud Storage Models & Object Storage Security 10.5 Data Security Posture Management & AI Data Protection
11 Chapter 11: Application Security
11.1 Secure Software Development Lifecycle (SSDLC) & DevSecOps Pipelines 11.2 Application Security Testing: SAST, DAST, SCA & SBOM 11.3 Cloud API Security: OWASP API Top 10 & API Gateway Protections
12 Chapter 12: Incident Response & Resilience
12.1 Cloud Incident Response Lifecycle, Cloud Challenges & Playbooks 12.2 Cloud Digital Forensics: Ephemeral Workloads, Snapshots & Chain of Custody 12.3 Cloud Resilience, Business Continuity & Disaster Recovery Patterns
13 Chapter 13: Related Technologies & Strategies
13.1 Zero Trust Architecture in Cloud (NIST SP 800-207 Principles & Execution) 13.2 Secure Access Service Edge (SASE) & Cloud Access Security Brokers (CASB) 13.3 Artificial Intelligence & Machine Learning Security (CSA AI Safety & LLM Risks) 13.4 CCSK v5 Synthesis, Cross-Domain Scenarios & Exam-Day Strategy
3.3 Cloud Governance Operating Models & CCM Control Implementation
Key Takeaways Explain This Topic AI
Centralised, decentralised, and federated models allocate decision rights differently; automation and clear ownership matter more than assumed speed rankings.
The current downloadable CCM v4.1.1 workbook contains 207 controls in 17 domains; check each control ID and service-specific applicability.
Typical provider/customer allocations are simplified starting points; agree responsibilities for each activity, including provider and tenant identity duties.
Use an approved exception process with designated decision authority, recorded risk, conditions, and review arrangements appropriate to organisational policy.
Define logging scope, protect evidence, and choose retention by applicable requirements; centralisation and WORM features do not make every log tamper-proof.
Last updated: October 2026
Cloud Governance Operating Models & CCM Control Implementation
Cloud governance connects business objectives, risk decisions, and operational controls. An operating model establishes who can make decisions and who performs the work; a control framework supplies requirements to evaluate. Neither a cloud service label nor a framework replaces a service-specific agreement about responsibilities.
A useful implementation combines a documented governance model, an applicable control baseline, evidence, and an exception process. This section uses the CSA Cloud Controls Matrix (CCM) v4.1 family , including the current downloadable v4.1.1 workbook generated on 2 October 2026. Its introduction describes responsibility attributions as typical, simplified starting points that must be revised for the contractually agreed Shared Security Responsibility Model (SSRM). Apply that qualification to the examples throughout this section.
Choose an Operating Model for the Organisation
In a centralised model , a central team holds much of the authority for architecture, provisioning, security, and shared services. It can deliver consistent controls and consolidated spending oversight. It may also create queues if capacity, automation, or decision rights are poorly designed. Centralised does not mean every request must be manually processed: a central team can offer automated self-service within approved boundaries.
In a decentralised model , business units or product teams hold more authority over their environments and budgets. This can support specialised needs and local responsiveness. It creates coordination challenges where teams need common identity, logging, procurement, or incident processes. Decentralisation is not permission to ignore enterprise obligations; a common policy or assurance function can still apply.
In a federated model , central and distributed teams share decision rights. A Cloud Center of Excellence (CCoE), platform group, or another designated body may define common standards and reusable services, while product teams operate their workloads. The organisation must state which decisions are delegated, which require review, and how disagreements are resolved. A federation without clear ownership can reproduce both queues and fragmentation.
Model Useful capability Risk to manage Practical design question
Centralised Common expertise and consistent shared services Overloaded queues or a mismatch with local needs Which routine requests can be safely automated?
Decentralised Local accountability and specialised delivery Divergent configurations and incomplete shared visibility Which enterprise controls and reporting remain common?
Federated Common boundaries with delegated workload decisions Ambiguous handoffs or inconsistent exception handling Who owns each decision and the evidence it requires?
There is no universal deployment-time ranking such as “weeks” for centralisation and “minutes” for federation. Staff skills, platform maturity, workload risk, and approval design matter. Nor is federation a guarantee against shadow IT. Measure outcomes such as delivery lead time, control coverage, exception age, and remediation time instead of assuming an architectural label produces them.
The CCoE and Product-Team Handoff
A CCoE can bring together security, architecture, operations, privacy, procurement, and financial expertise. Its work might include an account or subscription structure, approved infrastructure templates, identity integration, and logging patterns. Product teams then deploy using those services and remain responsible for their documented workload tasks.
Policy as code translates selected requirements into machine-evaluable checks. A deployment pipeline might reject a storage configuration with public write access, while a detective rule reports drift after deployment. These controls reduce repetitive manual review, but do not prove that every aspect of a system is secure.
Define an escalation route for unusual data, a new provider service, or a control the platform cannot enforce. Some deployments can proceed through pre-approved automation; others still need review under organisational policy or law. “Self-service” should describe a usable authorised path, not the removal of every human decision.
Read the Current CCM Precisely
The current workbook's control tab contains 207 controls in 17 domains . The domains cover audit and assurance; application/interface security; resilience; change/configuration; cryptography and keys; datacentres; data/privacy; governance/risk/compliance; people; identity/access; interoperability/portability; infrastructure; logging; incidents/forensics; supply chain; threats/vulnerabilities; and endpoints.
The current domain codes include A&A for audit and assurance, CEK for cryptography/encryption/key management, and I&S for infrastructure security. Do not substitute an invented “CRY” domain or carry older identifiers into a current table without checking the version.
The exam's current CCSK curriculum covers governance, risk, compliance, service models, and shared responsibility. A later CCM workbook is useful implementation evidence, but its 207 controls are not an exam question count or a published allocation of CCSK questions. Do not turn domain counts or an illustrative control selection into exam weights.
Turn a Requirement into a Traceable Control Record
Start with the exact current control identifier and specification, then document applicability, implementation owner, supporting party, evidence, and review arrangements. Break a broad control into practical activities when provider and customer duties differ.
For example, the current workbook identifies DSP-04 with data classification, whereas DSP-03 concerns data inventory. An inventory identifies what data is held and where; classification assigns sensitivity and handling needs. Those activities support each other but are not interchangeable.
Other identifiers must also be read accurately. DCS-01 concerns physical/environmental security policy rather than prescribing biometric access for every datacentre. IAM-05 concerns least privilege rather than being a generic label for every identity task. HRS-02 concerns acceptable use, not a universal employee-background-check rule. Control IDs are precise references, not shortcuts for whichever security topic sounds similar.
An implementation record for classification could state: the enterprise's data owners approve business handling categories; an application team applies them to records; a provider supplies discovery or labelling capabilities; and assurance checks sample the resulting labels and access controls. Another service may delegate more operational work. That does not eliminate the need to agree who approves decisions and verifies performance.
Allocate Responsibility at the Activity Level
The provider typically maintains the physical infrastructure for hosted IaaS, PaaS, and SaaS services. With IaaS virtual machines, a customer commonly maintains guest operating systems and its applications; a managed PaaS arrangement can transfer underlying runtime operating-system work to the provider. SaaS transfers more application operation to the provider, while customer-specific choices may remain.
These are typical examples , not a rule that all tasks in one domain belong exclusively to one party. A provider has identity controls for its own administrators. A customer may approve employee access within a tenant. Both relate to identity, but they are different activities with different evidence.
Activity in an illustrative managed service Possible provider task Possible customer task
Employee access to customer records Operate the service's authentication and authorisation capabilities Approve employee privileges and review tenant access
Data sensitivity handling Supply labels, discovery, or contractual processing safeguards Approve business categories and verify appropriate use
Incident response Investigate platform events and notify through agreed channels Investigate tenant misuse and coordinate its business response
Encryption and keys Operate specified service encryption and key facilities Choose supported settings and perform any retained key duties
Vulnerability management Remediate provider-managed components Remediate customer-managed code and configurations
Use the contract, service documentation, and current responsibility guidance to replace “possible” with named accountable and performing parties. Check handoffs such as notification times, evidence access, and who can change a configuration. A provider assurance report cannot by itself prove that a customer's tenant settings are correct.
Revisit this record when a service changes. Moving a database to a managed tier may change who patches it, which audit events can be exported, and which recovery operations the customer can perform. Record the affected service and region, the agreed boundary, the evidence source, and the person who will investigate a failed control. Test a handoff with a concrete event, such as an employee leaving or a log export failing. A responsibility chart that nobody can execute is an incomplete operating procedure.
CCM, CAIQ, and Provider Assurance
The Consensus Assessments Initiative Questionnaire (CAIQ) helps customers ask providers structured questions about controls. Read a response together with its service scope, date, supporting evidence, and limitations. A “yes” answer is not proof that every product, region, or customer configuration is covered.
The current CSA download distinguishes the CAIQ reference material bundled with CCM from the separate questionnaire intended for STAR Level 1 submission. Use the appropriate current submission template; uploading any spreadsheet labelled CAIQ is not automatically valid. The workbook introduction makes this distinction explicit.
CSA describes STAR Level 1 as self-assessment and Level 2 as third-party certification or attestation routes. Check the listing and scheme actually held rather than calling a self-assessment an independent audit. Assess the relevant service, assurance period, exceptions, and remaining customer controls. A registry entry supports due diligence; it does not transfer the customer's decisions to CSA.
CCM also supports comparisons with other frameworks. A mapping can identify overlap or a gap, but it does not mean every control fully satisfies every mapped standard. Confirm the mapping's source and target editions and inspect the target requirement. The current workbook introduction discusses mapping gaps and distinguishes the MITRE ATT&CK threat-technique mapping from compliance-framework mappings. Use each comparison for its stated purpose, rather than declaring universal compliance from one cross-reference.
A Policy Exception Is a Governed Risk Decision
GRC-04 calls for an approved exception process under the governance programme, and CCC-08 addresses exceptions within change/configuration management. Neither makes one organisation's signatory list or software architecture mandatory for every customer.
A practical exception request should explain the affected resources and policy, the business need, the threat or exposure, proposed mitigations, and the requested duration or review point. Risk assessment may be qualitative, quantitative, or both, as appropriate to the organisation's method and available evidence. Invented precision is not better than a well-supported qualitative assessment.
A workable lifecycle is:
Record and scope: Identify the owner, affected service, data, control, and reason compliance cannot currently be achieved.
Evaluate: Assess impact, likelihood, obligations, alternatives, and the effectiveness of proposed safeguards.
Decide: Obtain approval or rejection from the authority designated by policy. Security and data owners may advise or approve where that model assigns them authority.
Implement and track: Record conditions, mitigation owners, remediation milestones, and the next review or expiry required by the policy.
Reassess and close: Verify remediation, reconsider continued acceptance, or revoke the exception when conditions change.
A CISO and business data owner may be the right approvers in a particular enterprise; they are not a universal two-signature rule in CCM. Similarly, a 90-day exception or a reminder 30 days before expiry can be a local design choice, not an industry-wide maximum or alert requirement.
Keep records auditable and protected against unauthorised change. A central register often helps connect owners and controls across teams; it need not be a special immutable database in every organisation. Integrating approved exceptions with posture reports should preserve visibility of accepted risk. Do not silently disable detection or relabel a genuine exposure as a false positive merely because it has been accepted.
Logging, Evidence, and Retention
Continuous configuration checks and event monitoring can detect changes between formal assessments. They complement independent assessment rather than making it obsolete. Automated evidence still needs a defined scope, reliable collection, and interpretation; an unavailable log source is not evidence that no incident occurred.
The current CCM includes log protection, restricted log access, and a defined logging scope. In particular, LOG-07 supports deciding which events and metadata must be logged and revisiting that decision as requirements and threats change. It does not require recording every possible API event without considering applicability, service availability, privacy, or cost.
A useful logging design considers:
Coverage: Administrative events, access to important data, relevant application activity, identity events, and changes to logging itself, according to risk and obligations.
Collection: Available service logs, export settings, delivery latency, gaps, clock consistency, and alerts when collection fails.
Protection: Separation of duties, restricted administration, protected storage, and monitoring of access or deletion attempts.
Use: Searchable evidence, incident investigation, control testing, and documented follow-up.
Retention: Applicable legal, contractual, investigative, and business requirements for each record type, including deletion and legal holds where relevant.
An isolated central logging account can reduce the ability of a compromised workload administrator to erase evidence. Test the actual permissions and delivery path. “Central” does not automatically mean secure, and a deny policy alone is not a guarantee against every privileged action.
Write once, read many (WORM) or retention-lock features can support preservation. Their guarantees depend on the provider, feature mode, configuration, permissions, and record scope. Do not describe all products as tamper-proof or assume identical root-user and legal-hold behaviour. Select a retention period through the applicable requirements; neither CCM nor the word “audit” creates one universal seven-year storage period.
Worked Governance Scenario
Consider a hypothetical enterprise with 450 cloud accounts across two providers. Its CCoE maintains approved identity integration, infrastructure templates, and logging exports. Workload teams deploy within these boundaries and remain accountable for their assigned configurations. The 450-account scale is an example input, not a threshold at which federation becomes mandatory.
The enterprise maps its classification process to DSP-04, records tenant-access responsibilities, and tests whether logs actually reach the protected repository. It chooses seven years for a particular archive only after its own retention assessment; other records can have different periods. Assurance staff sample evidence and investigate export failures instead of treating a dashboard's green status as sufficient proof.
An acquired dispatch system still uses HTTP on a backend link. Under its policy, the designated risk authority considers a proposed 90-day exception , segmentation, restricted access, monitoring, and a migration plan. A TLS-terminating load balancer can protect the client-to-balancer connection, but it does not encrypt an HTTP balancer-to-backend connection. Identify that residual exposure and assess whether further encryption or isolation is needed; do not describe the proxy alone as solving end-to-end confidentiality.
At review, the team demonstrates the safeguards, records remaining risks, and either remediates or seeks a new decision under policy. An auditor can use the retained evidence and exception history while still assessing scope and control effectiveness. No operating-model choice, spreadsheet mapping, or retention setting guarantees a favourable audit outcome.
Exam Checks
Distinguish an organisation's policy from a framework requirement. Ask who approves a risk decision, who performs a task, and which current evidence supports it. Check the exact control identifier and version before attaching a technical claim. Above all, treat shared responsibility as a specific allocation of activities, not a slogan that one party always performs all data, identity, or application security.
Official implementation references: CSA CCM v4.1 download , CCSK curriculum , and CSA STAR levels .