← All articles

The Cloud Shared Responsibility Model: What Are You Actually Responsible For?

31 August 2026

The Cloud Shared Responsibility Model: What Are You Actually Responsible For?

Many teams that move to the cloud operate on a quiet assumption: “the infrastructure is on AWS/Azure/Google, so security is their job.” That assumption is the root cause of most cloud breaches. In reality, cloud security is shared: the provider is responsible for one part, and you for another. Not knowing where that line sits creates a “responsibility gap” that attackers step straight into.

The model: security of the cloud vs in the cloud

The industry distinction is clear:

  • Provider — security of the cloud: Physical data centres, hardware, the network backbone, the virtualisation layer, and keeping the foundational services running and patched.
  • Customer — security in the cloud: Your data, your configuration, identity and access (IAM), application code, and — depending on the service model — the operating system.

The provider gives you a secure foundation; what you place on it and how you configure it is your responsibility.

The line shifts with the service model

  • IaaS (a virtual server): OS, patches, application and data are yours.
  • PaaS (a managed platform): The provider manages the OS and runtime; the app and data stay with you.
  • SaaS (a ready-made product): The provider manages almost everything, but your data, user access and in-app configuration are still yours.

The key point: regardless of the model, data and access management never transfer to the provider.

Common mistakes that fall into the gap

  • Publicly exposed storage buckets: Storage accidentally left “public” means data on the internet.
  • Over-permissive IAM: Full-admin roles granted “for convenience”; if one key leaks, the whole account goes.
  • Unpatched customer OS: On IaaS, OS updates are yours.
  • Leaked access keys: Cloud keys embedded in code bypass authentication entirely.

Managing your share

  1. Know your model — IaaS/PaaS/SaaS and where the line falls.
  2. Least privilege for IAM roles.
  3. Keep storage private by default.
  4. Encrypt data at rest and in transit.
  5. Continuously audit configuration; scan for internet-exposed assets.

Summary

In one sentence: the provider secures the cloud itself; you secure what you do in the cloud. However strong the provider is, a misconfigured storage bucket or an over-permissive IAM role is your responsibility — and most of that share is manageable with a few core disciplines.

Sources: AWS Shared Responsibility Model, Microsoft: Shared responsibility in the cloud, Cloud Security Alliance.

Do you have internet-exposed cloud assets (public storage, admin panels, forgotten services)? CyberTestify’s external surface scan maps the attack surface visible from the internet.