Episode 17 — Shared Responsibility: Who Does What
Welcome to Episode 17, Shared Responsibility: Who Does What, where we clarify how duties divide between cloud providers and customers. The shared responsibility model defines the boundaries of accountability—who secures which parts of the stack, who maintains compliance, and who responds when incidents occur. Understanding these boundaries prevents costly assumptions. Many organizations mistakenly believe that outsourcing infrastructure means outsourcing risk entirely. In truth, while providers safeguard the foundation, customers remain responsible for the configurations, data, and access that sit atop it. The cloud is a partnership, and clarity within that partnership determines resilience, trust, and compliance.
Provider responsibilities form the bedrock of this arrangement. Cloud vendors such as Google, Amazon, and Microsoft handle the physical facilities where data centers operate. They secure buildings, control hardware access, and manage the power, cooling, and network backbone. Providers also maintain the hypervisor layer—the virtualization software that separates tenants and ensures isolation between workloads. These layers are invisible to the customer yet vital to reliability. When a provider signs an uptime or security commitment, it covers this infrastructure stack. The customer inherits these protections automatically, freeing them from the logistical burden of maintaining physical assets.
Customer responsibilities sit at the top of the stack and focus on what is deployed inside the provider’s environment. These include managing identity and access controls, configuring security groups, encrypting sensitive data, and ensuring compliance with applicable laws. Misconfigurations—like open storage buckets or over-permissive roles—remain the customer’s liability, even if the provider’s infrastructure is flawless. Customers must also handle data classification, lifecycle management, and application patching within their scope of control. In short, the cloud provider secures the cloud, but the customer secures what they place in it. Awareness and proactive configuration define success in this model.
The shared model changes subtly across service types. In Infrastructure as a Service, customers retain the broadest responsibility, managing everything above the virtualization layer. In Platform as a Service, the provider assumes more—handling runtime environments and scaling automatically—while customers focus on application code and data. In Software as a Service, responsibility narrows further to user behavior, permissions, and data integrity. Each model shifts the dividing line, but the principle remains: responsibilities never disappear; they simply relocate. Knowing where that line sits for each service is the foundation of secure and compliant cloud adoption.
In the IaaS model, the division extends from the operating system upward. The provider manages compute, storage, and networking infrastructure, while the customer controls the operating system, applications, and configurations. Patch management, intrusion detection, and key rotation remain within customer scope. For example, when deploying virtual machines on Google Compute Engine, the provider ensures hardware isolation, but the customer must apply OS updates and configure firewalls. Misunderstanding this boundary leads to avoidable exposure. IaaS offers freedom but demands vigilance; every layer of control requires deliberate attention to security hygiene and operational discipline.
In PaaS environments, the responsibility shifts again. The provider manages the runtime, frameworks, and system libraries, while the customer focuses on application logic and data protection. You don’t patch servers or manage dependencies—the platform does. Yet customers still define who can access applications, how data is encrypted, and what input validation or error handling occurs. For instance, when deploying code to App Engine, developers control application security, but Google manages the runtime environment. PaaS simplifies operations but does not eliminate oversight. Customers must secure their portion of the stack—the part that interacts directly with users and data.
SaaS introduces the most contained model of shared responsibility. The provider maintains the entire infrastructure, runtime, and application, while customers manage usage, permissions, and data quality. For example, in Google Workspace, encryption, availability, and patching fall to Google, but data governance and role management remain with the customer. Misuse—like weak passwords or improper sharing—is still customer-driven risk. SaaS success depends on administrative rigor: enforcing multi-factor authentication, role-based access, and clear data retention policies. Providers deliver the service securely; customers ensure that users interact with it responsibly.
Serverless computing introduces unique nuances within this framework. Here, the provider manages infrastructure, runtime, and scaling entirely, while customers handle event triggers, permissions, and observability. In Google Cloud Functions, for example, code executes only when events occur, and the platform scales automatically. Yet security context—identity roles, access scopes, and logging—remains a customer concern. Misconfigured permissions can allow unintended access or data leakage. Observability tools must still capture logs and metrics for accountability. Serverless simplifies execution but amplifies the importance of governance at the edges, where automation meets human intent.
Network layers also carry shared responsibility. Providers secure the physical network and backbone, ensuring segmentation and anti-DDoS protection. Customers manage logical segmentation—defining subnets, firewalls, routing, and egress rules. Neglecting egress controls can expose systems unintentionally to the public internet. A well-architected Virtual Private Cloud isolates workloads with minimal exposure while allowing authorized communication. The partnership works like a dual lock—providers guard the infrastructure perimeter, and customers lock the virtual doors inside. Together, these boundaries protect data in motion, ensuring confidentiality and integrity across distributed systems.
Identity and access management remains the control most prone to error yet most crucial to protection. Providers offer the tools—directory services, role hierarchies, and policies—but customers define least privilege. Every user, system, and service account must receive only the permissions necessary for its role. Excess privilege compounds risk: a single compromised account can cascade across environments. Periodic audits, just-in-time access, and automation of role reviews help maintain discipline. Identity is the new perimeter in cloud environments; managing it responsibly ensures that flexibility does not evolve into vulnerability.
Compliance mapping connects shared responsibility to external requirements. Frameworks like ISO, SOC, and GDPR define controls that must be evidenced. Providers supply attestations and documentation proving their portion of compliance, but customers must implement controls for their own domain. For example, encryption in transit may be verified by the provider, but key management policy remains under customer control. Clear mapping ensures no control gaps exist. Successful organizations maintain compliance matrices that specify responsibility per control—provider, customer, or shared. This structured clarity converts compliance from a checklist into an ongoing assurance process.
Incident response operates under shared expectations defined by contracts and playbooks. When infrastructure issues occur—such as data center outages—the provider leads response and communication. When incidents involve misconfiguration, data leakage, or account compromise, the customer leads. Joint protocols define escalation paths, timelines, and evidence requirements. The most mature organizations rehearse these scenarios before crises occur, ensuring smooth collaboration under pressure. In cloud environments, response readiness depends on knowing who calls whom, for what, and when. Documentation and testing turn shared responsibility into shared resilience.
Tooling alignment strengthens coordination across shared domains. Cloud Security Posture Management, or C S P M, automates configuration monitoring. Cloud Infrastructure Entitlement Management, or C I E M, governs identity and access risks. Security Information and Event Management, or S I E M, aggregates and analyzes alerts from all layers. Together, these systems create continuous oversight. The provider offers data feeds and integration points; the customer configures and interprets them. Automation reduces blind spots, but understanding remains human. Tools translate responsibility into visibility—turning shared accountability into measurable security posture.
Documenting, educating, and enforcing expectations complete the shared responsibility model. Clarity must live in policy, onboarding, and everyday practice. Every stakeholder—executive, developer, auditor, and operator—needs to understand their portion of the model. Documentation codifies boundaries; education reinforces them; enforcement ensures adherence. Shared responsibility is not static; as services evolve, so must agreements. The goal is partnership built on transparency and trust. When both provider and customer honor their roles, the cloud becomes not a risk shift but a resilience multiplier—a secure foundation for innovation that endures.
