Certified: The GIAC GCLD Audio Course

In this episode, we focus on one of the most practical ideas in cloud security: knowing exactly who secures what, so security gaps do not sneak in and surprise you later. Shared responsibility is not a slogan and it is not a legal disclaimer; it is the operational boundary that determines whether a missed control becomes your incident or your vendor’s problem. When teams are unclear on ownership, they either leave holes because they assume someone else handled it, or they waste effort rebuilding controls that already exist. Both outcomes are dangerous in different ways. The calm way to approach the topic is to treat shared responsibility as a map you can consult when you design, deploy, and troubleshoot cloud systems. If you can articulate the boundaries clearly, you can test them, monitor them, and gather evidence that your assumptions match reality.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Shared responsibility means control boundaries across layers and services, and those boundaries change depending on what service model you are using. A layer is a slice of the system stack where a specific set of controls live, such as physical facilities, hardware, virtualization, operating systems, middleware, applications, identity, and data. A boundary is the point where the provider’s obligations end and the customer’s obligations begin. That boundary is not universal, and it is not the same across all services. The provider generally takes on more responsibility as you move from I A A S to P A A S to S A A S, but you never reach a point where you can ignore security altogether. The reason this matters for the exam and the real world is that many cloud incidents are not caused by exotic exploits. They are caused by a mismatched assumption about who owned a control and who was supposed to verify it.

To compare the models cleanly, start with Infrastructure as a Service (I A A S) and walk the stack from the ground up. In I A A S, the provider typically owns the physical security of the data centers, the facility controls, the hardware lifecycle, and the base virtualization layer that allows you to provision compute and storage on demand. That includes things like building access controls, environmental protection, and the underlying infrastructure that makes availability possible at scale. The customer, however, is commonly responsible for what runs on top of that infrastructure, including the operating system configuration, patching, hardening, host-based controls, and the applications and data. In practice, you are operating your portion of the stack much like you would on-prem, except you no longer touch the racks. The provider removes certain burdens, but you still own the security posture of what you deploy.

The operating system layer in I A A S is where many teams get tripped up because it feels like the provider should handle it, but the reality is that you often still control it. You decide which images to deploy, how they are hardened, how patches are applied, and how security baselines are maintained over time. If you deploy a vulnerable operating system image and never patch it, the provider’s strong facility controls will not save you from a remote compromise. You also own how you segment networks, how you configure host firewalls, and how you manage administrative access paths. Even when the provider offers tools and services to help with those tasks, the responsibility to configure and validate them is still yours. This is why shared responsibility is best understood as ownership of outcomes within your control boundary, not just ownership of technology components. If the boundary includes the operating system, then the operational work of keeping it secure belongs to you.

Platform as a Service (P A A S) shifts the boundary upward by moving more of the platform patching and maintenance onto the provider. In P A A S, you are often consuming a managed runtime, managed database, managed messaging service, or managed application environment where the provider handles the underlying operating system, middleware, and the platform components that would otherwise require constant patching and tuning. This can be a security advantage because patching is centralized and can be performed consistently, but it also creates a temptation to assume the service is secure by default. In reality, you still own how you configure the service, who can access it, and how data is protected in transit and at rest. You also own the security of your code and how your application uses the platform features. The provider may patch the platform quickly, but the provider cannot fix a misconfigured identity policy or insecure application logic you deploy.

One helpful way to think about P A A S is that it reduces the number of layers you directly manage, but it increases the importance of secure configuration. Because the provider manages more components, your most meaningful security decisions are often expressed as settings, policies, and permissions rather than operating system commands. You must understand what the service exposes, what it logs, how it authenticates, and what default behaviors are present. If a platform service allows public network access by default and you forget to restrict it, the provider did not fail. The boundary says you owned that configuration choice. At the same time, you should not try to recreate everything you used to do at the host level, because that can lead to unnecessary complexity and fragile workarounds. The professional approach is to use the platform’s native controls and verify their effectiveness with evidence.

Software as a Service (S A A S) pushes the boundary even higher and changes the nature of your responsibilities. In S A A S, the provider typically operates the application itself, the infrastructure, the platform, and the patching pipeline behind the scenes. You consume a finished service, and you may have limited control over the underlying architecture. Your responsibilities concentrate around identity, data, and configuration choices you are allowed to make. That includes how accounts are provisioned, how authentication and authorization are enforced, how privileged roles are managed, and how data is classified, retained, and shared within the service. You also own the governance decisions about what data is placed in the service and how it is used. If users can share sensitive data externally because of permissive tenant settings, that is often a customer-owned outcome, even though the provider runs the application.

In S A A S, security success often depends on disciplined administration rather than deep technical tuning. You must set strong access control defaults, enforce least privilege, and monitor how identities behave over time. You must manage integrations carefully, because S A A S platforms often connect to many other services and those connections can expand blast radius if mismanaged. You must also evaluate what visibility you have, including what logs are available, what alerts exist, and what administrative events are recorded. The provider may promise high availability and rapid vulnerability management, but that does not eliminate your responsibility to control who can access data and how it is shared. The boundary means you cannot patch the provider’s code, but you can still create significant risk through weak identity practices, inconsistent configuration, and poor data governance. This is why S A A S security frequently looks like identity security plus configuration assurance plus data protection, all tied to audit-friendly evidence.

A quick example helps lock the model in, so map responsibilities across storage, compute, and identity in your head and watch how the boundary shifts. For compute in I A A S, you often own operating system patching and hardening, while the provider owns the physical host and hypervisor layer. For compute in P A A S, the provider is more likely to patch and maintain the runtime and platform, while you own application configuration, secure code, and access controls. For compute in S A A S, the provider runs the application end-to-end, while you own tenant configuration and user access patterns. Now consider storage. In I A A S object storage, the provider runs the service, but you often own access policies, encryption key choices, and data classification decisions. In a P A A S managed database, the provider may handle patching and backups at the platform level, while you own schema decisions, query exposure, network access rules, and who can read or write. In S A A S document storage, you own sharing settings and retention policies, while the provider maintains the platform and its patching.

Identity is often the most consistently customer-owned responsibility across all three models, and that is why identity errors are so common. In I A A S you decide how administrative access occurs, how roles are defined, and how permissions are granted. In P A A S you still decide who can deploy, who can manage service configuration, and which identities can access data. In S A A S you decide user lifecycle processes, privileged admin assignments, and how authentication is enforced. Even when the provider supplies identity tooling, your configuration choices determine whether least privilege is real or just a policy statement. If you treat identity as the always-on center of shared responsibility, you will catch many of the gaps that otherwise appear when teams assume that managed services remove the need for access discipline.

Now name the first common pitfall explicitly: assuming the provider handles every security task. This shows up when teams treat shared responsibility as a transfer of accountability instead of a shift in operational work. They see a managed service and assume that secure operation is included by default, without confirming what settings must be enabled, what access policies must be written, or what logs must be turned on. This pitfall creates the most dangerous type of gap, which is the invisible gap where nobody is working the control because everyone assumed someone else was. When an incident happens, the post-incident analysis reveals that the control was optional, disabled, or misconfigured, and the assumption was never tested. The fix is not just more documentation. The fix is building a habit of explicitly mapping ownership and validating it with evidence during onboarding and before go-live.

The second pitfall is the opposite: ignoring provider responsibilities and duplicating effort. This happens when teams do not trust the cloud model or do not understand what the provider already covers, so they build complicated compensating controls that add cost and reduce reliability. In I A A S, duplication can look like trying to recreate physical controls or assuming you must solve problems the provider already solved at the infrastructure layer. In P A A S, duplication can look like attempting to manage patching for components you do not control, or wrapping a managed service in brittle patterns that undermine its security features. In S A A S, duplication can show up as overengineering external solutions to problems the platform already addresses, while ignoring the simple tenant controls that actually matter. Duplicating effort is not just wasteful, it can introduce new attack surface and operational fragility. A mature cloud security approach uses provider controls where they are strong and focuses customer effort on the boundary areas that truly require your attention.

A quick win to avoid both pitfalls is a simple ownership-clarification checklist during onboarding, used anytime a new cloud service or vendor product is adopted. Start by identifying the service model, then write down what layers the provider manages and what layers you manage. Next, tie each major security objective to an owner, such as access control, patching, logging, encryption, backup, and monitoring. Then confirm what evidence exists for each objective, because shared responsibility without evidence becomes a debate during an incident. Finally, define how changes will be governed, including who can modify security-relevant settings and how those changes are reviewed. This is not bureaucracy for its own sake; it is how you prevent silent gaps from becoming production risk. When onboarding includes ownership clarity, the system starts life with fewer assumptions and fewer unknowns.

It is also important to rehearse how accountability can feel blurry during an outage or service disruption, because that is when people panic and start pointing fingers. When an outage happens, you might not know at first whether it is your configuration, your workload, the provider’s platform, or a dependency upstream. A calm response begins by using the shared responsibility map as a diagnostic guide. You identify which layers are likely involved based on symptoms, and you gather evidence from the layers you control, such as configuration states, access logs, and deployment histories. You also consult provider status and service health indicators, because provider-side events do occur and can explain a large portion of the behavior. The key is to avoid assuming you are powerless just because the provider is involved, and also avoid assuming the provider is at fault because the cloud is involved. The map helps you investigate methodically rather than emotionally.

That leads directly to tying responsibility to evidence, because evidence is what turns a shared responsibility model into an auditable, defensible reality. Evidence can include logs that show who accessed what and when, configuration snapshots that prove security settings were enabled, and access control assignments that show least privilege was actually implemented. For I A A S, evidence often includes operating system patch levels, host hardening baselines, network security rules, and identity audit trails. For P A A S, evidence often includes service configuration states, policy definitions, identity bindings, and platform logging that captures administrative changes. For S A A S, evidence often includes tenant configuration exports, administrative activity logs, identity provider integration records, and data sharing audit events. The exam mindset here is simple: if you claim a control exists, you should be able to point to something that demonstrates it. Evidence also prevents unproductive arguments about ownership when something fails.

To keep the model memorable under pressure, create a memory anchor that uses layers to remember control ownership. Imagine the stack as a set of floors in a building. In I A A S you are responsible for more floors, including the operating system and what runs on it, while the provider owns the foundation and the structural elements. In P A A S the provider takes over more middle floors, and your work shifts toward securing how your application uses the platform and how the service is configured. In S A A S the provider runs the building, and you focus on who has keys, what they can access, and how information moves within the space. When you feel unsure, return to the layer question: which layer is involved, and who owns control at that layer for this service model. That single mental move catches most confusion before it becomes an incident.

Now do a quick mental review so the concepts stay organized. Shared responsibility is a boundary map, not a comfort phrase, and the boundary shifts as you move from I A A S to P A A S to S A A S. In I A A S you typically own operating system security and the workload controls, while the provider owns physical and core infrastructure. In P A A S the provider takes on platform patching and maintenance, while you own secure configuration, identity, and application behavior. In S A A S you focus heavily on identity, data, and tenant configuration, because those are the levers you can control. The common pitfalls are assuming the provider handles everything, and ignoring provider responsibilities and duplicating effort. The quick win is an onboarding ownership check tied to evidence, and the operational resilience move is using the responsibility map during outages to keep accountability clear. Those pieces together make shared responsibility actionable rather than theoretical.

To conclude, shared responsibility becomes simple when you treat it as a living map of control ownership across layers, validated by evidence and refreshed whenever services change. When you can clearly state what the provider covers and what you must configure, monitor, and prove, you prevent the silent gaps that cause most cloud security failures. When you also understand what the provider is responsible for, you avoid wasting time duplicating controls and you design more cleanly within the service model. Use layers as your memory anchor so you can reason quickly during incidents and audits without guessing. Map one system’s responsibilities and note any gaps.