Introduction
Cloud security remains one of the most debated topics in modern IT. As organizations continue their migration to cloud platforms, the question of "Who is responsible for what?" grows increasingly complex. In our latest Passwork webinar, cybersecurity lecturer David Gordon joined host Turpal to unpack the realities behind the shared responsibility model and why clear boundaries are still elusive for many teams.
"The shared responsibility model is a fundamental concept in cloud security that delineates where the cloud provider’s responsibilities begin and end, and where the client’s responsibilities begin and end" — David Gordon
The session explored practical examples, common pitfalls, and actionable strategies for CISOs and IT leaders navigating the blurred lines between cloud provider and client responsibilities.
The shared responsibility model: Theory vs practice
At its core, the shared responsibility model defines the security obligations of both the cloud provider (e.g., AWS, Azure) and the client. The provider is responsible for securing the infrastructure and network, while the client manages data, applications, and configuration within the cloud environment.
However, these boundaries shift depending on the service model:
- Infrastructure as a service (IaaS). Clients carry most of the security burden, from OS patches to identity management.
- Platform as a service (PaaS). Responsibility is more balanced, with providers handling the platform and clients managing data and application logic.
- Software as a service (SaaS). Providers handle most security aspects, but clients must still manage user access and data governance.
While the model is theoretically clear, David highlighted that practical applications can sometimes be a little complex due to the dynamic nature of cloud services.
Where ambiguity leads to risk
Ambiguity in the shared responsibility model has been the root cause of several high-profile breaches. One of the most cited examples is the misconfiguration of AWS S3 buckets. Despite AWS securing the underlying infrastructure, clients failed to set proper permissions, resulting in sensitive data exposure.
"Some overly permissive permissions were granted to these S3 buckets, and that led to sensitive data being exposed to the public. That type of scenario is unfortunately not uncommon." — David Gordon
Other common missteps include:
- Misconfigured identity and access management (IAM) rules
- Failure to implement multi-factor authentication (MFA) on critical accounts
- Assuming implicit security without verifying configurations
The lesson: never assume security is "built-in" by default. Clients must proactively manage their configurations and understand the nuances of each cloud service model.
Contracts, fine print, and operational realities
Cloud provider contracts aim to define shared security responsibilities, but operational realities often diverge from contractual language. CISOs and IT leaders must scrutinize the fine print, looking for:
- Clear delineation of responsibilities. Understand exactly what the provider covers and what is left to the client.
- Incident response procedures. Who is responsible for breach notification, investigation, and remediation?
- Audit rights and transparency. Can you validate the provider’s controls and monitor their compliance?
- Service-level agreements (SLAs). Are uptime, recovery, and security guarantees realistic and enforceable?
David cautioned that the detailed operational implications are sometimes not as clear as the contract language suggests, underscoring the need for ongoing review and negotiation.
Lessons learned: Avoiding misconfiguration
A recurring theme in the discussion was that most cloud-related incidents are not caused by flaws in the provider’s infrastructure, but rather by preventable mistakes made by clients. The biggest culprits are misconfigured permissions, lack of monitoring, and weak identity practices. These errors underscore the importance of treating configuration management as an ongoing discipline rather than a one-time setup. Training teams, conducting regular checks, and utilizing automated tools can significantly mitigate these risks.
"Just never assume implicit security. Yes, the cloud provider is responsible for the infrastructure, but you, the client, are 100% responsible for how you configure permissions on the cloud." — David Gordon
The webinar highlighted real-world strategies for minimizing risk and confusion:
- Continuous education. Train teams to understand their responsibilities and the specifics of each cloud service model.
- Regular audits. Periodically review configurations, permissions, and access controls.
- Automated monitoring. Leverage tools to detect misconfigurations and anomalous activity in real time.
- Collaborative planning. Foster open communication among security, IT, and business units to ensure a shared understanding.
Conclusion
Cloud security is not a static checklist — it is an ongoing partnership between provider and client. As David Gordon emphasized, "never assume implicit security." Success requires vigilance, clear communication, and a willingness to adapt as cloud services evolve.
- The shared responsibility model is clear in theory, but ambiguous in practice
- Misconfiguration, especially of storage and access controls, remains a leading cause of cloud breaches
- Contracts should be reviewed for operational clarity, not just legal protection
- Ongoing education, monitoring, and cross-team collaboration are essential for effective cloud security
At Passwork, we help organizations navigate the complexities of cloud security with tools that empower proactive management, robust access controls, and real-time monitoring. By understanding your responsibilities and building resilient processes, you can turn shared confusion into shared success.
Further reading
Turpal Mahaev
Turpal Mahaev
Eirik Salmi