Shared Responsibility Model

You’ve just deployed your first cloud workload, and the security checklist is piling up. Who’s responsible for patching the OS? Who watches the network firewall? And if a database is exposed, is it your fault or the cloud provider’s? Without a clear answer, security gaps hide in the gray area between provider and customer—and that’s exactly where breaches happen. The shared responsibility model is the mental map that draws the line between what your cloud provider secures and what you own, and mastering it is the first real step toward building secure cloud systems.

The problem this lesson solves

When you move to the cloud, you don’t hand over security—you split it. If you assume the provider handles everything, you might leave your data unprotected. If you assume you must secure everything, you waste effort duplicating what’s already managed. The shared responsibility model solves this by defining exactly who controls what, based on the service type you use (IaaS, PaaS, SaaS).

Without a clear model, you face:

• Confusion during audits — you can’t articulate what you’re accountable for.
• Misconfigured resources — you think the provider blocks public access, but you forgot to set permissions.
• Unexpected costs — you over-engineer security for services the provider already manages.

Pro tip: The shared responsibility model isn’t a single document—it’s a contract. Every major provider (AWS, Azure, GCP) publishes its own version. Know where to find yours.

Core concept / mental model

Think of the cloud as a managed apartment building. The provider is the landlord: they own the building structure, the elevators, the plumbing, and the perimeter security. You are the tenant: you own what’s inside your unit—your furniture, your data, and who you let in.

• Provider responsibilities (the landlord): physical security of data centers, hardware health, network infrastructure, virtualization layers.
• Customer responsibilities (the tenant): access management, data encryption in transit and at rest, application security, and compliance with internal policies.

Another useful analogy: a transportation service. - The bus company keeps the bus safe and insured. - You choose your destination and lock your belongings. - If you leave your laptop on the seat, that’s on you.

This division shifts depending on the service model:

• IaaS (Infrastructure as a Service): You manage everything above the hypervisor—OS, runtime, app, data.
• PaaS (Platform as a Service): Provider manages the OS and runtime; you manage your app and data.
• SaaS (Software as a Service): Provider manages almost everything; you manage data and access.

Core phrase to remember: The provider secures the cloud, you secure what’s in the cloud.

How it works step by step

Let’s walk through how the responsibility splits in practice, based on the service model you choose.

1. Choose a service model — IaaS gives you control but more work. PaaS reduces management but locks you into platform constraints. SaaS is turnkey but less customizable.
2. Identify provider-managed layers — Physical, network, hypervisor, and host OS (for PaaS/SaaS).
3. Identify customer-managed layers — Access policies, data classification, encryption keys, application code, and compliance.
4. Document your boundaries — Create a responsibility matrix (see below) for your organization.
5. Monitor and audit — Use cloud-native tools to verify your side of the contract.

Here’s a responsibility comparison for a typical web app on AWS:

Key takeaway: Your responsibilities shrink as you move from IaaS to SaaS, but you never lose ownership of your data and access.

Hands-on walkthrough

Let’s apply the model with a simple scenario: deploying a web app on a cloud VM (IaaS). We’ll use Python and a generic cloud CLI to see what you must secure versus what the provider handles.

Example 1: Checking your security responsibilities with Python

Create a responsibility_checker.py that lists your security tasks for a given service model.

# responsibility_checker.py

def check_responsibilities(service_model):
    provider_manages = {
        "IaaS": ["Physical security", "Network infrastructure", "Hypervisor"],
        "PaaS": ["Physical security", "Network infrastructure", "Hypervisor", "Operating system", "Runtime"],
        "SaaS": ["Physical security", "Network infrastructure", "Hypervisor", "Operating system", "Runtime", "Application"]
    }

    customer_manages = ["Data", "Access management", "Encryption keys"]
    if service_model == "IaaS":
        customer_manages.extend(["Operating system", "Runtime", "Application"])
    elif service_model == "PaaS":
        customer_manages.append("Application")

    print(f"For {service_model}:")
    print("Provider manages:", ", ".join(provider_manages[service_model]))
    print("You manage:", ", ".join(customer_manages))

if __name__ == "__main__":
    check_responsibilities("IaaS")
    check_responsibilities("PaaS")
    check_responsibilities("SaaS")

Expected output:

For IaaS:
Provider manages: Physical security, Network infrastructure, Hypervisor
You manage: Data, Access management, Encryption keys, Operating system, Runtime, Application

For PaaS:
Provider manages: Physical security, Network infrastructure, Hypervisor, Operating system, Runtime
You manage: Data, Access management, Encryption keys, Application

For SaaS:
Provider manages: Physical security, Network infrastructure, Hypervisor, Operating system, Runtime, Application
You manage: Data, Access management, Encryption keys

Example 2: Mapping real AWS resources to responsibilities

Use the AWS CLI (or boto3 for Python) to see what you control:

# List your EC2 instances (IaaS)
aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId'

# Check network ACLs (provider-managed firewall)
aws ec2 describe-network-acls

# List your S3 buckets (data + permissions)
aws s3api list-buckets

In Python with boto3:

import boto3

# IAM is customer-managed — you control access
iam = boto3.client('iam')
print("Your IAM roles:", iam.list_roles()['Roles'])

# S3 data encryption is your responsibility
s3 = boto3.client('s3')
print("Your buckets:", s3.list_buckets()['Buckets'])

This illustrates: the provider gives you the key, but you decide who uses it.

Example 3: Verifying your responsibility with a cloud security scan

Run a quick check to see if your buckets are public (a common customer mistake):

import boto3

def check_public_buckets():
    s3 = boto3.client('s3')
    response = s3.list_buckets()
    for bucket in response['Buckets']:
        policy_status = s3.get_bucket_policy_status(Bucket=bucket['Name'])
        if policy_status['PolicyStatus']['IsPublic']:
            print(f"WARNING: Bucket {bucket['Name']} is PUBLIC!")
        else:
            print(f"OK: Bucket {bucket['Name']} is private.")

check_public_buckets()

Expected output:

OK: Bucket my-private-bucket is private.
WARNING: Bucket my-public-bucket is PUBLIC!

This script highlights that data permissions are your job—the provider doesn’t know your bucket shouldn’t be public.

Compare options / when to choose what

The shared responsibility model looks different depending on the service model. Here’s how to choose:

Decision matrix for your organization:

• If your team has strong DevOps/security skills, IaaS gives you maximum control.
• If you’re a small team shipping a product fast, PaaS reduces security overhead.
• If you need a specific business tool, SaaS offloads almost all security.

Pro tip: Even with SaaS, you must configure user permissions and enable MFA. The provider doesn’t know who on your team is a threat.

Troubleshooting & edge cases

Symptom: You think the provider patched your VM, but it’s vulnerable. - Cause: On IaaS, patching is your job. The provider only patches the hypervisor. - Fix: Implement a patch management process—use tools like AWS Systems Manager Patch Manager.

Symptom: A database is publicly accessible. - Cause: You created a security group with a rule allowing 0.0.0.0/0, but you thought the provider’s firewall was enough. - Fix: Follow the principle of least privilege. Use IAM and network ACLs correctly.

Symptom: You’re using PaaS, and you can’t update the OS. - Cause: That’s expected—the provider manages it. But you still must keep your app dependencies updated. - Fix: Use dependency scanners (e.g., pip-audit) and update your code regularly.

Edge case: Serverless (Function as a Service) - The provider manages the runtime entirely, but you manage function permissions and encryption. Misconfigurations often happen in IAM policies for Lambda.

Edge case: Container platforms (EKS/GKE) - You manage the worker nodes—even on managed Kubernetes, you’re responsible for OS patching and container security.

Pro tip: Always read the provider’s shared responsibility model page. It’s a living document that changes with new services.

What you learned & what's next

You now understand the shared responsibility model explained: the provider secures the cloud, you secure what’s in it. You can:

• Identify provider vs. customer responsibilities across IaaS, PaaS, and SaaS.
• Apply the model to real cloud resources (VMs, buckets, IAM).
• Avoid common pitfalls like assuming the provider handles OS patching or bucket permissions.

What’s next: In the next lesson, we’ll dive into IAM blast-radius reduction—how to minimize what an attacker can do if a credential is compromised, building on your responsibility understanding.

Keep this model as your foundation: every security decision you make in the cloud should start with “who owns this layer?”