Cloud Asset Security and the Shared Responsibility Model: Who Owns What in the Cloud

Hook / Why This Matters

CISSP Lens: Pick answers that align business risk, governance intent, and practical control execution.

"We moved to the cloud, so security is the provider's problem now." This statement has preceded more breaches than any exploit. The shared responsibility model means your cloud provider secures the infrastructure, but you still own your data, your configurations, and your access controls. Misunderstanding this split is the number one cause of cloud security failures.

Core Concept Explained Simply

The shared responsibility model defines which security tasks belong to the cloud provider and which belong to the customer. The split changes depending on the service model you use.

Responsibility by Service Model

Infrastructure as a Service (IaaS) gives the customer the most control and the most responsibility. The provider handles physical security, the network backbone, and the hypervisor. The customer handles everything above that: operating systems, middleware, applications, data, and access controls.

Platform as a Service (PaaS) shifts more responsibility to the provider. The provider manages the OS, runtime environment, and middleware in addition to physical infrastructure. The customer is responsible for applications, data, and user access.

Software as a Service (SaaS) places the most responsibility on the provider. The provider manages the application, the platform, and the infrastructure. The customer is responsible for data classification, user access management, and configuration of the application's security settings.

What Never Transfers

Regardless of the service model, these responsibilities always remain with the customer:

• Data classification. Your provider does not know which of your data is public and which is restricted. That is your job.
• Access management. Who can access your data and systems is always your decision.
• Compliance. Regulatory obligations follow your data, not your infrastructure. Moving to the cloud does not shift your compliance burden.
• User behavior. Training your people, enforcing acceptable use, and managing insider risk stay with you.

The Gray Areas

Several responsibilities sit in the overlap zone and depend on your specific configuration and contract:

• Patching: In IaaS, you patch the OS. In PaaS, the provider patches the OS but you may patch your application dependencies. In SaaS, the provider patches everything.
• Logging and monitoring: The provider generates infrastructure logs, but you must configure, collect, and analyze them.
• Encryption key management: The provider may offer encryption, but who manages the keys (provider-managed vs. customer-managed) changes the risk profile significantly.

CISSP Lens

The CISSP exam tests cloud shared responsibility frequently. Key points:

• Know the responsibility split for each service model (IaaS, PaaS, SaaS) and be able to identify which party handles a specific control.
• Data ownership and classification remain with the customer in every model. This is the most commonly tested concept.
• Cloud-specific risks include data commingling (your data on shared infrastructure), vendor lock-in, and jurisdictional issues (data stored in a different country).
• The exam tests "should" behavior. The correct answer is always that the customer is responsible for their data, even if many real organizations fail to act on this.

When faced with an exam question about a cloud breach caused by misconfiguration, the answer will point to the customer's responsibility, not the provider's.

Real-World Scenario

A fast-growing startup stored customer personally identifiable information (PII) in Amazon S3 buckets. When they created the buckets, they left the default access settings in place. At the time, S3 default settings allowed public access. Customer records were exposed to the internet for four months before a security researcher discovered the open bucket and reported it.

The startup publicly blamed AWS. AWS responded by pointing to the shared responsibility model documentation, which clearly states that S3 bucket configuration is the customer's responsibility. AWS provides the infrastructure; the customer configures it.

The startup's remediation included three key changes. First, they implemented AWS Config rules to detect and auto-remediate any S3 bucket with public access. Second, they deployed a Cloud Security Posture Management (CSPM) tool that continuously scanned their entire AWS environment for misconfigurations. Third, they created a cloud security baseline document that defined required configurations for every AWS service they used, reviewed during each new deployment.

The core lesson: your provider builds the locks. You have to actually lock the doors.

Common Mistakes and Misconceptions

• Provider handles everything. Even in SaaS, the customer is responsible for data, access, and configuration. The provider never takes full responsibility for your security.
• Not reading the documentation. Each provider publishes detailed shared responsibility documentation. Not reading it is not a defense when something goes wrong.
• No pre-migration classification. Moving unclassified data to the cloud does not classify it. Data should be classified before migration so that appropriate cloud controls can be applied.
• Ignoring service model differences. The controls you need for an IaaS virtual machine are vastly different from those you need for a SaaS application. Treating all cloud services the same creates gaps.
• No configuration monitoring. Cloud configurations drift over time as teams make changes. Without continuous monitoring, secure configurations degrade.

Actionable Checklist

• Document your shared responsibility split for each cloud provider and service model you use
• Classify all data before migrating it to cloud environments
• Deploy Cloud Security Posture Management (CSPM) tooling for continuous configuration monitoring
• Review default configurations for every cloud service before putting it into production
• Include cloud-specific responsibilities in your contracts and SLAs
• Train your teams on exactly what the provider handles and what they do not
• Implement customer-managed encryption keys for your most sensitive data
• Establish a cloud security baseline with required configurations for each service

Key Takeaways

• You can outsource operations but not accountability
• The responsibility split changes significantly between IaaS, PaaS, and SaaS
• Data classification and access control are always the customer's job
• Default cloud configurations are often not secure enough for production use
• CSPM tools are essential for detecting misconfigurations at scale

Exam-Style Reflection Question

In a SaaS model, which of the following remains the customer's responsibility: application patching, data classification, physical security, or network infrastructure?

Data classification remains the customer's responsibility in all service models, including SaaS. The provider handles application patching, physical security, and network infrastructure in a SaaS model. The customer is always responsible for their data, user access management, and compliance with applicable regulations.