The cloud fundamentally changed security governance. Controls that your organization owned completely are now shared with a cloud provider — and misunderstanding that boundary is the source of most major cloud breaches. This module builds your cloud governance architecture from first principles.
In cloud computing, security responsibility is shared between the cloud provider and the customer. The boundary shifts based on deployment model: In IaaS (e.g., AWS EC2), the provider secures physical infrastructure; the customer secures everything else (OS, network, applications, data). In PaaS (e.g., AWS RDS), the provider also secures the OS and runtime; the customer secures the application and data. In SaaS (e.g., Salesforce), the provider secures almost everything; the customer secures their data, access configuration, and authorized use.
Every major cloud breach — exposed S3 buckets, public databases, overpermissioned roles — shares a root cause: the customer misunderstood their responsibility in the shared model. AWS secures the S3 service. AWS customers are responsible for configuring bucket access controls. An S3 bucket left publicly accessible is not an AWS failure — it is a customer governance failure. Organizations need systematic controls (CSPM tools, cloud governance policies, automated guardrails) to prevent configuration drift.
Top cloud governance risks: (1) Misconfigured storage (public S3 buckets, exposed databases). (2) Overprivileged identities (cloud roles with admin permissions to everything). (3) Shadow IT — business units creating cloud resources outside IT/security governance. (4) Data sovereignty — sensitive data stored in non-compliant geographic regions. (5) Dependency on a single cloud provider for critical systems (concentration risk).
Understanding precisely what each party is responsible for prevents the most common cloud governance failures:
| Security Dimension | IaaS (EC2) | PaaS (RDS) | SaaS (Salesforce) |
|---|---|---|---|
| Physical data center | Provider | Provider | Provider |
| Hypervisor | Provider | Provider | Provider |
| Operating System | Customer | Provider | Provider |
| Network controls (VPC) | Customer | Shared | Provider |
| Application security | Customer | Customer | Shared |
| Data encryption | Customer | Customer | Shared |
| Identity & access management | Customer | Customer | Customer |
| Data classification | Customer | Customer | Customer |
Identity and access management (IAM) is ALWAYS the customer's responsibility in every cloud model. Misconfigured cloud IAM — overprivileged roles, unused admin accounts, lack of MFA — is the most common enterprise cloud governance failure.
CSA CCM v4 is the most comprehensive security controls framework specifically designed for cloud environments. It includes 197 control specifications across 17 domains:
Secure development, API security, application vulnerability testing. Addresses cloud-specific risks of shared APIs and multi-tenant application interfaces.
Independent audits, information system regulatory mapping, third-party audits. Maps cloud controls to regulatory requirements (GDPR, HIPAA, PCI-DSS).
Credential management, least privilege, multi-factor authentication, privileged access management. The most critical domain given shared responsibility for IAM.
Network security, virtual machine security, hypervisor security, container security. Addresses the unique security challenges of virtualized cloud infrastructure.
Cloud provider due diligence, sub-processor management, supply chain risk assessment. Applies TPRM principles specifically to cloud providers.
Data classification in cloud environments, data retention, secure deletion, cross-border transfers, privacy in multi-tenant environments.
Manual governance of cloud environments is impossible at scale. CSPM tools automate cloud security governance:
CSPM tools continuously scan cloud environments for misconfigurations — comparing configurations against security benchmarks (CIS Benchmarks, NIST 800-53) and flagging violations in real time. Examples: Prisma Cloud, Wiz, Lacework, AWS Security Hub.
Cloud governance policies expressed as code that are automatically enforced. Example: AWS Service Control Policies (SCPs) that prevent creation of public S3 buckets regardless of individual user permissions — a guardrail that cannot be bypassed.
Automatically discovers and inventories all cloud resources — preventing shadow IT assets from existing outside governance visibility. Integrates with CMDB for complete asset management.
Continuous compliance scoring against frameworks (CIS, SOC 2, GDPR, HIPAA). Real-time visibility into compliance posture across all cloud environments. Reduces audit preparation from weeks to hours.
Beyond technical controls, cloud governance requires organizational structures:
Cross-functional team (security, architecture, operations, finance) that sets cloud governance standards, reviews exceptions, and enables secure cloud adoption at speed.
Pre-defined, pre-hardened cloud environment templates. New AWS accounts or Azure subscriptions are deployed from Landing Zone blueprints that include security controls by default.
Policies specific to cloud: data classification requirements for cloud storage, approved cloud regions, prohibited services list, cloud IAM governance, and personal cloud account prohibition for work data.
Cloud cost anomalies can indicate security issues (unexpected resource creation = potential cryptomining, compromised account). Integrating FinOps and security monitoring creates additional detection signals.
You are the Cloud Security GRC lead for a company migrating to AWS. Complete each shared responsibility mapping task — documenting what AWS owns, what you own, and which GRC controls must be applied in your cloud environment to satisfy ISO 27001 and PCI-DSS.