Study guide
11.4 Cloud Service Provider Governance & Shared Responsibility
Certified in Risk and Information Systems Control CRISC
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Risk Foundations
1.1 About the CRISC Exam 1.2 Exam Day Strategy & Question Analysis
2 Chapter 2: Enterprise Governance & Organizational Strategy
2.1 Enterprise Governance of IT & Strategic Alignment 2.2 Organizational Structures, Roles & RACI Matrix 2.3 The Three Lines Model & Assurance Coordination 2.4 Legal, Regulatory & Contractual Compliance
3 Chapter 3: Risk Governance Frameworks & ERM
3.1 Enterprise Risk Management Frameworks 3.2 Risk Appetite, Tolerance & Capacity 3.3 IT Risk Strategy Alignment with Business Objectives
4 Chapter 4: Risk Culture, Ethics & Policy Architecture
4.1 Risk Culture, Tone at the Top & Accountability 4.2 Ethics, Integrity & ISACA Code of Professional Ethics 4.3 Risk Policy, Standards, Guidelines & Procedures Architecture
5 Chapter 5: Asset Management & Business Resilience Governance
5.1 Asset Identification, Valuation & Data Classification 5.2 Data Ownership, Custodianship & Governance Roles 5.3 Business Resilience Governance & Strategic Alignment 5.4 Data Privacy Governance & Global Mandates
6 Chapter 6: IT Risk Identification & Threat Modeling
6.1 Risk Identification Techniques 6.2 Threat Landscape Analysis, Threat Actors & Attack Vectors 6.3 Vulnerability Assessment & Exposure Analysis 6.4 Risk Scenario Development & Threat Modeling
7 Chapter 7: Risk Analysis Methodologies & Evaluation
7.1 Qualitative Risk Analysis & Risk Matrices 7.2 Quantitative Risk Analysis & FAIR Framework 7.3 Semi-Quantitative Analysis & Monte Carlo Simulation 7.4 Risk Evaluation, Ranking & Prioritization Criteria
8 Chapter 8: Risk Register, Aggregation & BIA Integration
8.1 Risk Register Architecture, Maintenance & Lifecycle 8.2 Risk Aggregation, Correlation & Interdependencies 8.3 Business Impact Analysis (BIA) Integration
9 Chapter 9: Risk Treatment Strategies & Cost-Benefit Analysis
9.1 Risk Response Options 9.2 Cost-Benefit Analysis & Return on Security Investment (ROSI) 9.3 Developing & Implementing Risk Action Plans 9.4 Managing Residual Risk & Secondary Risk
10 Chapter 10: Control Design, Selection & Assessment
10.1 Control Types & Categories 10.2 Control Design Principles & Defense-in-Depth 10.3 Testing Control Design & Operating Effectiveness 10.4 Remediation of Control Deficiencies & Exceptions
11 Chapter 11: Third-Party & Supply Chain Risk Management
11.1 Third-Party Risk Management Lifecycle & Due Diligence 11.2 Vendor Contracts, SLAs & Right-to-Audit Clauses 11.3 Supply Chain Risk Management & Software Bill of Materials (SBOM) 11.4 Cloud Service Provider Governance & Shared Responsibility
12 Chapter 12: Risk Monitoring, KRIs & Executive Reporting
12.1 Key Risk Indicators (KRIs), Thresholds & Triggers 12.2 Aligning KRIs with KPIs & Business Performance Metrics 12.3 Stakeholder Risk Reporting & Governance Communication 12.4 Continuous Risk Monitoring & Automated Telemetry
13 Chapter 13: Enterprise IT Architecture & Operations
13.1 Enterprise Architecture & IT Governance Alignment 13.2 Cloud Computing & Virtualization Architecture Risk 13.3 Systems Resilience, High Availability & Infrastructure Redundancy 13.4 Technology Roadmaps, IT Portfolio & Project Risk Governance
14 Chapter 14: Information Security Principles, IAM & SSDLC
14.1 Information Security Principles & The CIA Triad 14.2 Identity & Access Management (IAM), PAM & RBAC 14.3 Cryptography, Encryption & Key Management (KMS) 14.4 Secure Software Development Lifecycle (SSDLC) & DevSecOps
15 Chapter 15: Incident Response, Resilience & Emerging Tech Risk
15.1 Incident Response Lifecycle & Containment Strategies 15.2 Business Continuity & Disaster Recovery Planning and Testing 15.3 Emerging Technologies Risk (AI/LLM, Quantum, IoT/OT) 15.4 Risk Program Maturity Assessment & Continuous Improvement
11.4 Cloud Service Provider Governance & Shared Responsibility
Key Takeaways Explain This Topic AI
The Cloud Shared Responsibility Model establishes that the Cloud Service Provider (CSP) is responsible for 'Security OF the Cloud,' while the customer is strictly responsible for 'Security IN the Cloud.'
In Infrastructure as a Service (IaaS), the customer controls the OS, middleware, runtime, and applications; in PaaS, the customer manages applications and data; in SaaS, the customer controls data, identity, and access configurations.
Regardless of the cloud deployment model (IaaS, PaaS, SaaS) or service architecture, the customer ALWAYS retains 100% legal accountability for data classification, governance, and access control.
Cloud Security Posture Management (CSPM) and Cloud Access Security Brokers (CASB) provide automated visibility, configuration drift detection, and data loss prevention across multi-cloud environments.
Proactive cloud exit strategies mitigate vendor lock-in risk through containerization (Kubernetes), open APIs, infrastructure-as-code (IaC), and validated data extraction protocols.
Last updated: August 2026
11.4 Cloud Service Provider Governance & Shared Responsibility
Cloud computing has fundamentally revolutionized enterprise IT by replacing capital-intensive physical data centers with scalable, elastic, on-demand compute, storage, and software services. However, transitioning workloads to the cloud does not eliminate IT risk—it transforms the nature and distribution of that risk.
According to NIST SP 800-145 ( The NIST Definition of Cloud Computing ), cloud computing is characterized by five essential characteristics: on-demand self-service , broad network access , resource pooling , rapid elasticity , and measured service . While these capabilities provide unmatched operational agility, they introduce complex multi-tenant governance, configuration drift, and shared security responsibilities that risk practitioners must master. +-----------------------------------------------------------------------------+
- | THE CLOUD SHARED RESPONSIBILITY MATRIX |
- | |
- | Layer / Component IaaS PaaS SaaS |
- | ------------------------- ---------------- -------------- -------- |
- | Data Classification & Gov [ CUSTOMER ] [ CUSTOMER ] [CUSTOMER]|
- | Identity & Access (IAM) [ CUSTOMER ] [ CUSTOMER ] [CUSTOMER]|
- | Application Logic & Code [ CUSTOMER ] [ CUSTOMER ] [ CSP ] |
- | Middleware & Database Engine[ CUSTOMER ] [ CSP ] [ CSP ] |
- | Operating System & Patching [ CUSTOMER ] [ CSP ] [ CSP ] |
- | Hypervisor & Virtualization [ CSP ] [ CSP ] [ CSP ] |
- | Physical Compute & Storage [ CSP ] [ CSP ] [ CSP ] |
- | Physical Facilities/Power [ CSP ] [ CSP ] [ CSP ] |
- | |
- | *UNIVERSAL GOVERNANCE RULE: The CUSTOMER is ALWAYS 100% responsible for |
- | Data Governance, Information Classification, and Access Management! |
- +-----------------------------------------------------------------------------+
- 1. Cloud Service Models: Control vs. Delegation
The boundary of security responsibility shifts dramatically depending on the cloud service delivery model:
A. Infrastructure as a Service (IaaS)
Architecture: The CSP provides virtualized hardware resources—compute (virtual machines), block/object storage, and software-defined networking.
Customer Responsibility: The customer exercises extensive control and bears substantial security responsibility. The customer must configure, harden, and patch the guest Operating System (OS) , configure firewall rules (Security Groups / Network Access Control Lists), manage database engines, install middleware, secure application code, and configure IAM policies.
CSP Responsibility: Physical data center security, environmental controls, physical server hardware, power, cooling, and the virtualization hypervisor layer.
Examples: Amazon Web Services (EC2/EBS), Microsoft Azure (Virtual Machines), Google Cloud Platform (Compute Engine).
B. Platform as a Service (PaaS)
Architecture: The CSP abstracts away the underlying operating system, server hardware, and runtime environment, providing a turnkey platform for developers to deploy code and manage databases.
Customer Responsibility: Developing, securing, and maintaining the application code , configuring database schemas and queries, and managing user authentication and access controls.
CSP Responsibility: Patching and maintaining the underlying OS, runtime environment (e.g., Node.js, Python, Java runtime), database management engine, hypervisor, physical infrastructure, and network routing.
Examples: AWS Elastic Beanstalk, Google App Engine, Azure App Services, Snowflake, Amazon RDS.
C. Software as a Service (SaaS)
Architecture: The CSP delivers a complete, fully managed software application accessed over the internet (typically via web browser or API).
Customer Responsibility: Data governance , data classification, configuring user access rights (IAM / Single Sign-On / MFA), setting organizational security policies within the tenant, and preventing data loss.
CSP Responsibility: Everything else—application development, vulnerability remediation, patching, backend database administration, infrastructure scaling, uptime, and physical data center security.
Examples: Microsoft 365, Salesforce, Workday, ServiceNow, Google Workspace.
2. Cloud Deployment Models & Governance Implications +-----------------------------------------------------------------------------+
- | CLOUD DEPLOYMENT TOPOLOGIES |
- | |
- | Deployment Model Infrastructure Ownership Multi-Tenancy / Isolation |
- | ---------------- --------------------------- ------------------------- |
- | Public Cloud Owned & operated by CSP Multi-tenant; shared |
- | (AWS, Azure, GCP) physical infrastructure |
- | ------------------------------------------------------------------------- |
- | Private Cloud Operated exclusively for a Single-tenant; dedicated |
- | single enterprise isolated infrastructure |
- | ------------------------------------------------------------------------- |
- | Hybrid Cloud Composition of two or more Bound by standardized |
- | distinct clouds (Priv/Pub) technology (APIs / VPN) |
- | ------------------------------------------------------------------------- |
- | Community Cloud Shared by organizations with Multi-tenant across a |
- | common mission / compliance restricted trusted group |
- +-----------------------------------------------------------------------------+
- 3. Automated Cloud Governance & Security Tooling
Because cloud environments are dynamic, API-driven, and subject to rapid continuous deployment, traditional static security audits are insufficient. Organizations deploy automated cloud governance tooling: +-----------------------------------------------------------------------------+
- | CLOUD SECURITY TOOLING ECOSYSTEM |
- | |
- | [CSPM: Cloud Security Posture Management] |
- | - Continuously scans cloud infrastructure (IaaS/PaaS) for misconfiguration|
- | - Identifies open S3 buckets, overly permissive IAM roles, unencrypted db|
- | - Benchmarks configurations against CIS Foundations & NIST frameworks |
- | |
- | [CWPP: Cloud Workload Protection Platform] |
- | - Protects workloads (VMs, containers, Kubernetes, serverless functions) |
- | - Runtime threat detection, container image scanning, eBPF telemetry |
- | |
- | [CASB: Cloud Access Security Broker] |
- | - Sits between enterprise users and SaaS cloud applications (inline / API)|
- | - Enforces Data Loss Prevention (DLP), detects Shadow IT, mandates MFA |
- | |
- | [CIEM: Cloud Infrastructure Entitlement Management] |
- | - Enforces least privilege across complex multi-cloud IAM permissions |
- | - Identifies over-permissioned service accounts & inactive roles |
- +-----------------------------------------------------------------------------+
The Anatomy of a Cloud Misconfiguration Breach:
Industry data indicates that over 95% of cloud security breaches are caused by customer misconfigurations , not vulnerabilities in the underlying CSP hypervisor. Common catastrophic failures include:
Publicly Exposed Object Storage: Leaving cloud storage buckets (e.g., AWS S3, Azure Blob) set to public read access without authentication.
Overly Permissive IAM Roles: Granting administrative ( *:* ) wildcard privileges to compute instances or lambda functions, allowing Server-Side Request Forgery (SSRF) attacks to steal temporary security credentials via the Instance Metadata Service (IMDS).
Unrestricted Ingress Ports: Exposing database ports (e.g., MySQL 3306, PostgreSQL 5432) or management ports (RDP 3389, SSH 22) directly to 0.0.0.0/0 (the entire internet).
4. Vendor Lock-In & Cloud Exit Strategies
A critical risk in long-term cloud governance is vendor lock-in —a situation where an enterprise becomes so technologically and financially dependent on a specific cloud provider that transitioning to another provider or repatriating workloads on-premises is cost-prohibitive or technically infeasible. +-----------------------------------------------------------------------------+
- | CLOUD LOCK-IN & EXIT STRATEGY MODEL |
- | |
- | Lock-In Drivers / Traps Exit Strategy Architectural Controls |
- | ---------------------------------- ------------------------------------ |
- | Proprietary APIs & Specialized Adopt Containerization (Docker, OCI) |
- | Services (e.g., DynamoDB, BigQuery) and Orchestration (Kubernetes / K8s) |
- | ------------------------------------------------------------------------- |
- | High Egress Bandwidth Fees Architect open, non-proprietary data |
- | (Financial barriers to moving data) formats (Parquet, JSON) & multi-CDN |
- | ------------------------------------------------------------------------- |
- | Proprietary Infrastructure Scripts Use Multi-Cloud Infrastructure as |
- | (e.g., AWS CloudFormation) Code (IaC: Terraform / OpenTofu) |
- | ------------------------------------------------------------------------- |
- | Untested Migration Playbooks Mandate annual dry-run exit drills & |
- | contractual data extraction SLAs |
- +-----------------------------------------------------------------------------+
Essential Elements of a Defensible Cloud Exit Plan:
Data Portability: Ensure all enterprise data is stored in standard, non-proprietary formats that can be exported without vendor transformation tools.
Infrastructure-as-Code (IaC) Portability: Avoid proprietary CSP orchestration templates; standardize on open-source, multi-cloud declarative tools (such as Terraform or OpenTofu).
Decoupled Architecture: Encapsulate application logic in standardized Open Container Initiative (OCI) containers and deploy across managed Kubernetes environments.
Contractual Exit Assistance: Mandate that the CSP contractually commit to providing operational and technical data extraction assistance at predefined hourly rates upon contract termination.
5. CSP Assurance & Certification Frameworks
To validate that a CSP operates defensible controls over its physical and hypervisor infrastructure, risk practitioners evaluate recognized cloud assurance artifacts:
ISO/IEC 27017: Code of practice for information security controls based on ISO/IEC 27002 specifically for cloud services.
ISO/IEC 27018: Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors.
FedRAMP (Federal Risk and Authorization Management Program): Rigorous U.S. government standard assessing CSP security across Low, Moderate, and High impact baselines based on NIST SP 800-53.
CSA STAR Level 2: Independent third-party attestation combining SOC 2 Type II audits with the CSA Cloud Controls Matrix (CCM).
- 6. CRISC Exam Traps & Real-World Scenarios
- Exam Trap 1: Believing SaaS Outsources Data Governance and Privacy Liability
The Trap: An organization transitions to a SaaS CRM platform and assumes that because the CSP manages the software, the CSP is legally responsible for customer data breaches.
The Reality: Under the Shared Responsibility Model and statutory data protection laws (GDPR, HIPAA, CCPA), the data owner (customer) ALWAYS retains 100% legal accountability for data classification, authorized user access, and privacy compliance.
Exam Trap 2: Confusing IaaS Operating System Patching with PaaS
The Trap: A question describes an unpatched vulnerability in the underlying Linux OS of an Amazon EC2 or Azure VM instance that leads to a breach. The candidate assumes the cloud provider failed their patching duty.
The Reality: In IaaS , the customer is strictly responsible for configuring, updating, and patching the guest operating system. In PaaS , the CSP is responsible for OS and runtime patching.
Exam Trap 3: Assuming Cloud Providers Automatically Back Up Customer Data
The Trap: A company loses a critical database due to an administrator error and requests that the IaaS provider restore yesterday's backup. The provider states that no backup exists.
The Reality: IaaS and PaaS providers guarantee infrastructure availability, not automated customer data backup, unless the customer has explicitly configured, scheduled, and funded backup/replication services.