The cloud shared responsibility model is one of the most important concepts in cloud security, and one of the most consistently misunderstood. The misunderstanding follows a specific pattern: organizations assume that moving to the cloud transfers more security responsibility to the provider than it actually does. This assumption produces security gaps that attackers actively exploit.
Gartner estimates that through 2026, 99% of cloud security failures will be the customer’s fault, primarily due to misconfiguration. That figure is not an indictment of cloud security. It is a statement about where the accountability boundary sits. The cloud provider’s infrastructure is generally well-secured. The misconfigurations, the exposed storage buckets, the over-permissioned IAM roles, the unpatched VMs, are almost all on the customer side of the line.
This guide clarifies exactly what cloud providers are responsible for, what customers and their MSPs are responsible for, and how the boundary changes across different cloud service models. Kaseya’s platform covers the customer side of the shared responsibility model for more than 50,000 MSPs and IT teams worldwide.
The core principle
Every major cloud provider, AWS, Microsoft Azure, and Google Cloud, publishes a shared responsibility model that defines the security division of labor. The principle is consistent across all of them: the provider secures the cloud; the customer secures what is in the cloud.
The provider’s responsibilities cover the physical infrastructure (data centers, servers, network hardware), the hypervisor layer, the network fabric, and the availability and reliability of the managed services they offer. Everything a customer deploys within the cloud environment, operating systems, applications, data, identity configuration, network access controls, is the customer’s responsibility, or their MSP’s.
The practical implication: a cloud environment is not secure by default. It is secure to the extent that the customer configures it correctly. An EC2 instance with an unpatched OS is the customer’s problem. An S3 bucket with public access enabled is the customer’s problem. An IAM role with Administrator permissions attached to a service that needs read-only access is the customer’s problem. The cloud provider will not identify or fix any of these.
How responsibility changes by service model
The exact boundary shifts depending on the cloud service model in use. The further up the stack the service sits, the more the provider takes on, and the less the customer manages at the infrastructure level. But data, identity, and access control remain the customer’s responsibility in every model.
Infrastructure as a Service (IaaS)
The provider manages physical infrastructure and the virtualization layer. The customer manages everything above: operating system, middleware, runtime, applications, data, and network configuration. This is the model for cloud-hosted virtual machines, AWS EC2, Azure VMs, and Google Compute Engine.
IaaS carries the most customer responsibility of any service model. An MSP managing a client’s IaaS environment owns the full security stack above the hypervisor. That includes OS patching, application patching, firewall rules and security group configuration, encryption at rest and in transit, IAM configuration, and logging. None of this is handled by the provider.
Platform as a Service (PaaS)
The provider also manages the operating system, middleware, and runtime. The customer is responsible for applications and data. Managed database services, Azure SQL Database, AWS RDS, and application hosting platforms operate on this model.
PaaS reduces management burden significantly. Customers do not need to patch the underlying OS or manage the database engine. They do still own data security, access control, application-level configuration, and application code security.
Software as a Service (SaaS)
The provider manages the full stack, from infrastructure through application. The customer is responsible for data, access management, and configuration of the application’s security controls.
Microsoft 365, Google Workspace, and Salesforce are all SaaS. The most widespread misconception here: because the provider manages the application, customers assume the provider also protects the data. They do not. Microsoft is responsible for the availability and reliability of the Microsoft 365 platform. The data inside each tenant, and its recoverability, is the customer’s responsibility.
An organization that loses Microsoft 365 data to accidental bulk deletion, a malicious admin, or ransomware encrypting synced OneDrive files cannot rely on Microsoft’s retention tools to recover it. Those tools are compliance-oriented, with short retention windows, not designed for point-in-time operational recovery.
The most common shared responsibility gaps
Understanding the principle is one thing. The gaps that appear in real-world environments are specific and predictable. These five appear in almost every cloud environment that has not been formally assessed.
SaaS backup. The most widespread misunderstanding across all service models. Microsoft and Google do not back up Microsoft 365 or Google Workspace data in a way that provides operational recovery from accidental deletion, ransomware, or account compromise. Datto SaaS Protection addresses this directly, backing up Microsoft 365 and Google Workspace data three times daily to an independent, immutable Datto Cloud repository with unlimited retention and granular restore.
IAM configuration. Identity and access management, who has what permissions across cloud environments, is always the customer’s responsibility regardless of service model. IAM misconfiguration is the leading cause of cloud data breaches. A small MSP taking on a new client’s AWS environment will typically find IAM roles with permissions far broader than the services they cover. Remediating this is unglamorous, time-consuming work that almost every environment needs.
OS and application patching for IaaS workloads. Cloud VMs do not patch themselves. An AWS EC2 instance or Azure VM running an unpatched operating system is just as vulnerable as an on-premises server in the same state. VSA and Datto RMM extend automated patch management to cloud-hosted endpoints using the same agent-based deployment and policy-driven automation used for on-premises servers.
Network security configuration. Security groups, network access control lists, and VPC/VNet configuration are customer responsibilities in IaaS environments. Security groups that permit unrestricted inbound access on ports 22 or 3389 are consistently found in cloud environment assessments and are consistently present because they were set open for troubleshooting and never closed. These are straightforward to remediate and high-priority to address.
Logging and monitoring. Cloud providers make audit logs available, AWS CloudTrail, Azure Monitor Activity Logs, Google Cloud Audit Logs, but enabling logging, storing it correctly, and monitoring it for security events is the customer’s responsibility. A cloud environment with no logging enabled is an incident investigation dead end. Kaseya SIEM ingests cloud platform logs alongside endpoint and email telemetry, normalizing security events across providers into a single detection layer.
What this means for MSP service design
The shared responsibility model is not just a security concept. It is a service design framework. MSPs who build service offerings explicitly around the responsibility categories they cover can articulate value to clients with precision. MSPs who do not understand the model are likely to have undocumented gaps in their coverage and difficult conversations when an incident exposes them.
A practical onboarding checklist for any new client cloud environment, structured around the shared responsibility model:
For IaaS workloads:
- Deploy VSA or Datto RMM agent on all cloud VMs and enroll in existing patch management policies
- Audit IAM roles and service accounts; document and remediate excessive permissions
- Review security group and network ACL configurations; close any unrestricted management port access
- Confirm audit logging is enabled in all regions and logs are routed to an independent, monitored destination
- Verify backup is configured independently of the cloud account and test a recovery
For SaaS environments:
- Deploy Datto SaaS Protection for Microsoft 365 and Google Workspace
- Review admin account permissions and enforce MFA on all privileged accounts via Kaseya 365 User
- Document what data lives in which SaaS platform and what the recovery path is for each
For all cloud environments:
- Define and document which responsibilities the MSP covers in the service agreement
- Confirm compliance requirements (HIPAA, PCI DSS, CMMC, CCPA) that apply to cloud-hosted data and map them to the controls in place
- Add cloud environment architecture and IAM structure to IT Glue for the client
The documentation step matters beyond operational value. When a client faces a cyber insurance claim or a compliance audit, the MSP’s ability to produce evidence of what security controls were in place, and when, is often what determines the outcome.
How Kaseya 365 covers the customer side
The Kaseya 365 platform provides tooling that addresses each layer of customer responsibility across IaaS, PaaS, and SaaS.
VSA and Datto RMM automate OS and application patch management for cloud-hosted VMs alongside on-premises endpoints, covering the IaaS patching responsibility from a single console.
Datto SaaS Protection covers the SaaS data protection responsibility for Microsoft 365 and Google Workspace, with three-times-daily backup, unlimited retention, and independent immutable storage.
Kaseya 365 User addresses the identity and access management responsibility across Microsoft 365 and connected cloud environments, including MFA enforcement and Dark Web ID credential monitoring.
Kaseya SIEM covers the logging and monitoring responsibility, ingesting cloud platform audit logs alongside endpoint and email telemetry into a unified security detection layer.
IT Glue covers the documentation responsibility, storing cloud environment architecture, IAM structure, and recovery runbooks with per-client isolation and controlled access.
Kaseya Intelligence applies automated pattern recognition and response across managed cloud environments, detecting configuration drift on the customer side of the shared responsibility boundary and executing remediation without waiting for manual review.
