The shared responsibility model is simple in principle and easy to misunderstand in practice. AWS, Azure, and Google Cloud all secure the underlying cloud, but customers still own a large part of the risk: identities, data, configuration, application behavior, and response readiness. This comparison explains what stays with the provider, what remains with you across IaaS, PaaS, and SaaS, and how to turn that distinction into a usable checklist for cloud security responsibilities, privacy compliance, and day-to-day operations.
Overview
If your team works in AWS, Azure, or Google Cloud, the shared responsibility model is not a legal footnote. It is the operating rule that determines who patches what, who configures what, and who is accountable when something goes wrong.
The safest evergreen way to understand the model is this: the provider is responsible for the security of the cloud, while the customer is responsible for security in the cloud. The exact boundary moves depending on the service type. In traditional infrastructure services, the customer owns much more. In managed platform services, some operating system and lower-level runtime work shifts to the provider. In SaaS, the provider operates most of the application stack, but the customer still owns data governance, identities, access rules, and configuration choices.
Microsoft’s current Azure guidance makes one point especially clear: regardless of service model, customers still own their data and identities. Azure also frames configurations and settings as a customer responsibility across service types, with network controls, applications, and client devices sometimes becoming shared or provider-managed depending on whether the service is IaaS, PaaS, or SaaS. That framing is useful beyond Azure because it reflects the broad pattern across major clouds.
For security teams, the practical takeaway is that there is no such thing as “the provider handles security” in a complete sense. There is only a changing split of duties. For privacy and compliance teams, the same is true: hosting regulated data in a major cloud does not transfer your obligations around access control, retention, lawful processing, breach response, or vendor oversight.
This matters for cloud privacy compliance because many failures do not come from a weakness in the provider’s physical infrastructure. They come from customer-controlled mistakes: over-permissive IAM roles, public storage exposure, unmanaged secrets, weak tenant settings, stale service accounts, unreviewed subprocessors, or missing incident procedures. The cloud can reduce infrastructure burden without reducing accountability.
How to compare options
The most useful way to compare AWS, Azure, and Google Cloud is not by asking which vendor is “most secure.” All three operate large-scale security programs. The better question is: for the services we actually use, what security work still sits with us?
Use five lenses when comparing providers and service choices.
1. Start with the service model, not the brand
A virtual machine, a managed database, and a SaaS collaboration suite have very different responsibility boundaries even if they come from the same vendor. Compare like with like:
- IaaS: virtual machines, block storage, virtual networks, load balancers.
- PaaS: managed databases, application hosting platforms, serverless functions, object storage, container platforms with managed control planes.
- SaaS: email, CRM, collaboration tools, analytics suites, productivity apps.
As you move from IaaS toward SaaS, the provider typically takes over more of the underlying stack. But your ownership of data, users, permissions, retention, and business logic does not disappear.
2. Separate control from accountability
One of the most common mistakes in vendor risk assessment is assuming that if the provider controls a layer, the customer has no remaining accountability. In practice, you may still need to prove that appropriate controls exist, configure the service correctly, and monitor how it is used. This is especially important for data protection compliance and SaaS security compliance reviews.
For example, a provider may manage the operating system for a database service. You may still be accountable for database authentication, network exposure, encryption settings, logging retention, user lifecycle controls, and whether personal data is stored there at all.
3. Compare default posture versus secure posture
Providers offer secure features, but those features are not always enabled by default, consistently deployed, or enforced across all projects and subscriptions. Compare:
- Identity defaults
- Logging coverage
- Encryption options and key management choices
- Network exposure controls
- Policy enforcement and guardrail tooling
- Multi-account or multi-project governance support
This is where a cloud misconfiguration checklist becomes more valuable than a marketing comparison sheet.
4. Map responsibilities by workload, not by platform
Most organizations are multi-cloud in practice, and many use a mix of IaaS, PaaS, and SaaS within each provider. Your responsibility matrix should be built around workloads such as customer web apps, analytics pipelines, employee productivity tools, AI systems, and backup platforms. This exposes hidden gaps. A team may have strong controls for EC2 or Compute Engine but weak controls around SaaS admin settings or serverless secrets management.
5. Include privacy and incident duties in the comparison
Shared responsibility is not only about patching and perimeter controls. It should also cover:
- Data classification and minimization
- Cross-border data transfer compliance
- Retention and deletion settings
- Breach notification requirements
- Access logging and audit readiness
- Subprocessor due diligence
- DPA and contractual alignment
If a service stores personal data, your cloud security comparison should also support your privacy by design checklist.
Feature-by-feature breakdown
The broad pattern across AWS, Azure, and Google Cloud is similar, but teams still need a practical matrix. The comparison below focuses on the most durable responsibilities rather than service-specific branding.
Identity and access management
Customer responsibility across all major clouds: define users, roles, service accounts, privileged access paths, MFA requirements, federation, break-glass accounts, and access reviews.
This is one of the least transferable parts of cloud security responsibilities. Even in SaaS-heavy environments, customers usually control user provisioning, group design, role scope, device trust conditions, and offboarding. If an attacker gains access through a weak admin account, the provider’s infrastructure security does not prevent the incident.
What to verify: centralized identity, least privilege, temporary elevation, separation of duties, and disabled long-lived credentials where possible.
Data security and privacy controls
Customer responsibility across all major clouds: classify data, decide what data enters the service, configure retention, restrict sharing, manage deletion workflows, and align storage choices with legal and contractual obligations.
The provider may supply encryption, regional hosting options, audit logs, and backup features. You still decide who can access data, how long it remains, whether test environments contain production data, and whether regulated records are copied into unmanaged tools.
For cloud privacy compliance, this is the layer that most often intersects with GDPR checklist work: lawful access, deletion handling, records of processing, transfer review, and vendor documentation.
Configuration and settings
Azure’s responsibility matrix explicitly places configurations and settings on the customer side across service types, and that is a sound baseline for AWS and Google Cloud as well. Managed service does not mean self-securing service.
Customer responsibility: storage bucket policies, firewall rules, private endpoint settings, backup retention, public exposure controls, logging destinations, API restrictions, admin center settings, and service-level security features.
A practical rule: if your console, CLI, IaC template, or admin portal can change it, assume you own it unless the provider clearly documents otherwise.
Operating systems and patching
IaaS: customers generally own guest operating system hardening, patching cadence, endpoint protection, and baseline images.
PaaS: providers usually manage the underlying operating system and part of the runtime stack, while customers still own application dependencies, secret handling, access paths, and insecure code.
SaaS: the provider typically handles the operating system and application hosting stack, but the customer still owns tenant-level security decisions and account hygiene.
This is one of the clearest differences between AWS shared responsibility model, Azure shared responsibility model, and Google Cloud shared responsibility at the service level: the more abstracted the service, the less OS work remains with you. The safe interpretation, though, is not “managed service equals no patching risk.” Your risk moves upward into packages, application logic, API permissions, and integrations.
Network controls
Network responsibility varies more by service type than by provider. In IaaS, customers usually design and maintain virtual network segmentation, security groups or firewall policies, routing choices, ingress restrictions, and private connectivity. In PaaS, some network controls become shared because the provider runs more of the service fabric. In SaaS, the provider often operates the core network layer, while customers retain access restrictions, IP allowlisting options, session controls, and integration boundaries where available.
Common customer gap: assuming that because a managed service is not on a VM, it cannot be internet-exposed or misrouted. In reality, public endpoints, weak peering design, and broad egress paths still create preventable risk.
Applications and code
IaaS: customers own the application stack.
PaaS: application responsibility is often shared in the sense that the provider runs the platform while the customer writes, deploys, and secures the code and its data flows.
SaaS: the provider runs the application, but customers still own the way the application is configured, integrated, and used.
For engineering teams, this is where cloud security best practices meet secure development. Secrets in code, unsafe deserialization, missing authorization checks, unreviewed webhooks, and excessive API tokens remain customer problems even when everything runs on a managed platform.
If your team is building AI-enabled features in cloud platforms, the line becomes even more important. Model hosting, prompt storage, training data access, plugin connections, and generated output handling often create new shared responsibility questions. For related privacy and control design patterns, see Technical Controls to Enforce Legal Compliance Without Sacrificing User Privacy in Generative AI.
Endpoints and client devices
Customers continue to own endpoint hygiene for employee and admin devices, even in SaaS-heavy environments. Azure’s guidance treats client devices as customer responsibility in most cases and shared in SaaS scenarios, which is a useful reminder that the service can add controls but cannot replace device management.
If a privileged user administers your tenant from an unmanaged laptop, the strongest cloud platform features may still be bypassed by session theft, malware, or browser compromise. Browser extensions and local agents are an overlooked part of shared responsibility; for a concrete example, see Hardening Chrome’s AI Features and Extension Ecosystem Against Malicious Plugins.
Logging, monitoring, and incident response
Providers operate platform telemetry, but customers generally decide what logs to enable, how long to retain them, what detections to run, and who responds to alerts. Shared responsibility fails in practice when teams rely on available logs without confirming that they are turned on, exported, protected, and regularly reviewed.
Customer responsibility: alerting thresholds, use-case coverage, incident runbooks, forensic access planning, evidence retention, and breach notification decision paths.
If your cloud incident may become a legal or communications event, planning cannot stop at technical containment. Two useful follow-ups are Automating Incident Communications Without Sacrificing Accuracy and The CISO-Comms Playbook.
Best fit by scenario
No single provider “wins” the shared responsibility model. The better fit depends on how much control your team wants and how much security work it can reliably perform.
Scenario 1: Small team, limited ops capacity
Favor managed services over raw infrastructure. The more you can move from IaaS to well-governed PaaS or SaaS, the fewer lower-layer patching and host-hardening duties remain. But do not mistake this for reduced need in IAM, tenant security settings, data lifecycle policy, or vendor risk review.
Best approach: use managed databases, managed identity, policy guardrails, and strong admin separation from day one.
Scenario 2: Regulated workload with sensitive personal data
Choose the provider and service combination that gives you clear region controls, detailed logging, fine-grained access management, and contract support for your compliance needs. The key question is not only what the platform secures, but whether you can prove your own controls and limit data sprawl.
Best approach: document a workload-level responsibility matrix, verify DPA terms, restrict test data, review subprocessors, and map retention settings to policy.
Scenario 3: Engineering-heavy platform team
If your team has strong automation maturity, IaaS and flexible managed platforms can be reasonable, but only if infrastructure as code, policy-as-code, image hardening, secret scanning, and continuous review are real operating capabilities rather than aspirations.
Best approach: standardize golden templates, enforce guardrails in CI/CD, and treat exceptions as time-limited.
Scenario 4: SaaS-first business with many integrations
Your largest risks may not sit in AWS, Azure, or Google Cloud infrastructure at all. They may sit in identity federation, admin consoles, OAuth grants, third-party connectors, and shadow data copies. The shared responsibility model still applies; it has simply shifted into tenant administration and vendor governance.
Best approach: review app integrations quarterly, minimize scopes, monitor admin changes, and run a lightweight vendor risk assessment on business-critical services.
When to revisit
The shared responsibility model is stable in concept but not static in application. Teams should revisit their assumptions whenever services, defaults, or business use cases change.
Review your responsibility map when:
- You adopt a new cloud service or move from IaaS to PaaS or SaaS
- The provider changes default security features, admin controls, or logging behavior
- You begin storing new categories of personal, financial, or regulated data
- You add AI services, copilots, plugins, or model integrations
- You expand to new regions or need cross-border data transfer compliance review
- You undergo SOC 2, ISO 27001, customer audit, or procurement review
- You have an incident, near miss, or repeated configuration drift
A practical quarterly review can be simple:
- List your top ten cloud and SaaS services.
- Mark each one as IaaS, PaaS, or SaaS.
- For each service, confirm ownership for identities, data, settings, logs, network exposure, application code, and incident response.
- Note any control that is assumed rather than verified.
- Assign one owner and one review date for each gap.
If you want one evergreen rule to keep, make it this: always verify the boundary at the service level, and always assume data, identity, and configuration remain your problem until proven otherwise.
That mindset will keep your team closer to reality than any provider comparison graphic. It also creates a more useful bridge between cloud operations, privacy compliance tools, and vendor due diligence. The provider secures the platform it runs. You secure the way your organization uses it.
