The shared responsibility model, in one explanation
The shared responsibility model defines who — the cloud provider or the customer — is responsible for securing each layer of the technical stack. AWS summarizes this split with a formula that has become an industry reference: 'security OF the cloud' is the provider's job, 'security IN the cloud' is the customer's.
This model isn't just a contractual precaution: it's the foundation of any coherent cloud security strategy. Ignoring or underestimating your share of responsibility is the most common cause of cloud security incidents today.
What's always the provider's responsibility
Regardless of the service model used, the provider remains responsible for the physical security of data centers, the physical network (routers, cabling, backbone infrastructure), and the virtualization layer that isolates customers from each other.
What's always the customer's responsibility
Conversely, four responsibilities remain yours regardless of the service model: your data, identity and access management (IAM), the configuration of your resources, and the classification of your information's sensitivity.
What varies: the middle zone
Between these two extremes sits a zone whose split depends on the service model chosen: the operating system, the virtual network, the application runtime, and encryption. This zone generates the most confusion — and therefore the most mistakes.
Encryption illustrates this ambiguity well: the provider almost always offers encryption-at-rest and encryption-in-transit mechanisms, but enabling those mechanisms, managing the encryption keys, and ensuring they cover all relevant resources remains, in the vast majority of cases, an action the customer must explicitly take — it isn't automatic by default on every service.
How Azure, AWS and Google Cloud present this model
All three major providers adhere to the same general principle, but phrase it differently — a nuance that matters in how each one supports (or doesn't) its customers.
AWS: a clear-cut dividing line
AWS states the model in the most direct way: 'security of the cloud' (AWS) versus 'security in the cloud' (the customer). This phrasing draws a clear line, but leaves the customer with the full responsibility of understanding exactly where it sits for each service used.
Azure: a breakdown documented by responsibility category
Azure documents the model by explicit category (identity, application, operating system, network, host, physical infrastructure) and by service model, with detailed tables showing who manages what for each category, in IaaS, PaaS and SaaS.
Google Cloud: the 'shared fate' model
Google Cloud goes further with the concept of 'shared fate': rather than simply drawing a responsibility boundary, Google commits to providing additional guardrails and tools to actively help customers achieve secure outcomes, instead of just saying 'this is your problem.'
'Shared responsibility' and 'shared fate' aren't just different marketing choices: the latter implies more active support from the provider (secure-by-default configurations, built-in tooling), rather than a purely theoretical division of tasks on paper.
The boundary varies across IaaS, PaaS and SaaS
The precise split of responsibilities directly depends on the service model used — this is the direct link between this topic and the IaaS/PaaS/SaaS models covered in our dedicated article.
- In IaaS, you manage the operating system and everything running on it — the widest customer responsibility zone.
- In PaaS, the provider manages the OS and runtime — you manage your code, its configuration, and the data flowing through it.
- In SaaS, the provider manages the entire application — all that's left to you is your data and the configuration of access to that data.
Our IaaS, PaaS, SaaS article breaks this split down layer by layer, with the pizza analogy to visualize it simply.
Why most cloud breaches come from the customer, not the provider
This isn't a theoretical claim: it's a trend repeatedly measured by cloud security analysts over several years, and it's growing rather than shrinking.
Most incidents come from configuration errors
Gartner estimates that, through 2026, nearly all cloud security failures will be attributable to the customer, primarily due to misconfiguration — not a technical flaw at the provider's end. A Check Point study points the same way: 82% of enterprises have experienced a security incident linked to a cloud misconfiguration.
Breaches that stay invisible for a long time
The average time to detect a breach exceeds 180 days — plenty of time for an attacker to operate undetected. A significant share of cloud assets (roughly a third) remains insufficiently monitored, each one hiding an average of over a hundred unaddressed vulnerabilities.
Gartner forecasts that nearly all cloud security failures through 2026 will be due to customer error. Check Point reports that 82% of enterprises have suffered an incident linked to cloud misconfiguration. The average time to detect a breach exceeds 180 days.
Gartner · Check Point Research, 2026The most frequent customer-side configuration errors
Four families of mistakes consistently show up in cloud incident analyses, all directly tied to responsibilities that fall on the customer under the shared model.
Publicly exposed storage
Cloud storage spaces (buckets, containers) mistakenly configured for public access remain one of the most frequent causes of data leaks — an emblematic, recurring example of a poorly handled customer responsibility: the provider never configures storage as public on your behalf.
Excessive IAM permissions
Identity and access management is the most frequent cause of customer-side data breaches. The principle of least privilege — granting only the access strictly needed — is simple to state but rarely applied rigorously over time, since permissions tend to accumulate as projects evolve, without ever being scaled back.
- Users and service accounts with broader access than their actual use requires
- Inactive accounts never disabled after an employee leaves or a project ends
- A significant share of AWS IAM users, Google Cloud service accounts, and Microsoft Entra ID applications carry an access key older than a year — a risk window the provider can't close on your behalf
Missing multi-factor authentication on privileged accounts
Multi-factor authentication (MFA) remains one of the most effective measures to limit the impact of a compromised password, and it's offered natively by all three major providers. Yet its absence on high-privilege accounts — administrators, critical service accounts — remains common, usually due to a simple oversight during account creation rather than a deliberate choice.
None of these mistakes is a cloud provider failure. All of them fall directly under the customer's share of the shared responsibility model — which means they're all avoidable with the right internal processes, regardless of which provider you choose.
Shared responsibility and compliance
Misunderstanding the shared responsibility model isn't just a security risk: it's increasingly a compliance risk too, with direct financial consequences.
A direct link between configuration and non-compliance
A significant share of organizations report being out of compliance with at least one regulatory framework due to cloud-related issues, and a substantial proportion of compliance audit failures is directly tied to configuration problems that fall under the customer's responsibility — not the provider's.
The DORA regulation, a strong signal in Europe
The European DORA regulation (Digital Operational Resilience Act), fully applicable since January 2025, requires financial entities to demonstrate their ability to withstand, respond to, and recover from ICT-related incidents — including those resulting from poor management of their share of cloud responsibility. It's a concrete example of regulation that makes this topic non-negotiable for an entire sector.
A topic that goes beyond a single regulation
DORA is just one example among several frameworks that make shared responsibility explicit: GDPR requires the data controller (often the customer, not the provider) to guarantee the protection of personal data, while certification frameworks like ISO 27001 or SOC 2 require documented evidence that each party actually fulfills its scope — not just that it's defined on paper.
How to properly own your share of responsibility
Properly owning your share of the model doesn't require top-tier security expertise: three structuring habits cover most of the risk.
Precisely map what falls to you
For each cloud service used, explicitly identifying what falls under your responsibility (often documented by the provider itself) avoids the blind spots that appear when responsibility is assumed rather than verified.
Automate controls rather than relying on individual vigilance
Cloud security posture tools (often offered natively by providers) automatically detect risky configurations — public storage, excessive permissions, missing MFA — far more effectively than an occasional manual review.
Train the teams who deploy, not just the security team
Most configuration mistakes don't come from deliberate negligence, but from a lack of understanding of the model among the teams deploying day to day. A solid understanding of the shared responsibility model, spread beyond the security team alone, mechanically reduces risk — cloud security isn't just an expert's job, it's a cross-cutting skill.
Review periodically, not just at initial deployment
A secure configuration at deployment time doesn't stay secure indefinitely: new services get added, temporary permissions become permanent by oversight, accounts change roles without their access being adjusted accordingly. A periodic review — quarterly at minimum for critical environments — helps catch this drift before it becomes an exploited entry point.
A dedicated domain in entry-level certifications
The shared responsibility model is generally an explicit domain of entry-level cloud certifications — Azure Fundamentals, Google Cloud Digital Leader and AWS Cloud Practitioner all cover it in detail, alongside security, compliance and governance concepts.
That's no coincidence: it's one of the few cloud concepts directly actionable day to day, regardless of technical seniority — understanding your share of responsibility is useful for a developer just as much as for a business decision-maker approving a provider choice.
Further reading
Frequently asked questions
What is the shared responsibility model, in one sentence?
It's the framework that defines who — the cloud provider or the customer — is responsible for securing each layer of the technical stack. The provider always secures the physical infrastructure; the customer always remains responsible for their data and access.
Is the cloud provider responsible if my data leaks?
It depends on the cause. If the leak comes from a flaw in the provider's infrastructure (rare), it's their responsibility. If it comes from a misconfiguration on your end (public storage, excessive permissions), it's yours — even if the data was hosted with a major provider known for its security.
Why does the model differ across IaaS, PaaS and SaaS?
Because the level of technical abstraction changes what the provider manages on your behalf. In IaaS, they only manage hardware and virtualization; in SaaS, they also manage the entire application. The more layers they manage, the smaller your responsibility zone becomes.
What is Google Cloud's 'shared fate' model?
It's an evolution of the shared responsibility model where the provider doesn't just define a theoretical boundary, but actively commits to helping the customer achieve a secure outcome — through secure-by-default configurations and built-in tools, rather than simply documenting who does what.
Is IAM security really always my responsibility?
Yes, across all three service models (IaaS, PaaS, SaaS), without exception. The provider may offer robust IAM tools, but configuring those tools — who has access to what, with which permissions, with or without MFA — remains entirely your responsibility.
Why does detecting cloud breaches take so long?
Because many cloud resources remain insufficiently monitored, and configuration errors don't always trigger an immediate alert — they create a silent exposure that's only detected during an audit, a security scan, or active exploitation by an attacker.
Does the DORA regulation apply to all businesses?
No, DORA specifically targets financial entities operating in the European Union (banks, insurers, asset managers, etc.) and their critical IT service providers. It nonetheless illustrates a broader regulatory trend: poorly managed cloud responsibility becomes a compliance risk, not just a technical one.
Is a cloud security audit enough to cover my share of responsibility?
A one-off audit captures a snapshot in time, but cloud configuration evolves continuously (new deployments, new access grants). Best practice combines an initial audit with permanent automated controls, not an isolated audit followed by no ongoing monitoring.
How do I know exactly what falls under my responsibility for a given service?
All three major providers publish dedicated documentation on the shared responsibility model, usually broken down service by service. That's the most reliable starting point, better than generic assumptions that vary from one service to another.
Do you need to know this model for a cloud certification?
Yes, it's a central concept in the Azure Fundamentals, Google Cloud Digital Leader and AWS Cloud Practitioner entry-level certifications, usually covered in the domain dedicated to security and governance.