Cloud security is a shared responsibility: where most organizations still fall short

Cloud providers patch hypervisors and keep the network backbone online, but none of that decides who inside a customer’s organization can reach a production database, or whether last week’s configuration change left a storage bucket open to the public internet. Most cloud breaches trace back to that second category, not the first, and a lot of security teams still haven’t fully absorbed the difference.

Companies moving workloads into hybrid cloud or multi-cloud setups tend to assume that signing with a major provider settles the security question. It doesn’t. The dashboard usually looks fine while a stale access permission or an exposed port from an old migration sits somewhere the provider’s monitoring was never built to catch.

The line that keeps getting blurred

The shared responsibility model isn’t a secret. AWS publishes it, and so does every other major provider. Everything below the operating system, the data centers, the backbone, the hypervisor, is the provider’s job. Above that line is where things get messy, because data, identity and access management, and how an application gets configured all sit with the customer, along with the operating system itself when a workload runs on infrastructure-as-a-service.

Reading that split on a page is one thing. Living inside it is another. Signing a contract with a major cloud vendor creates a quiet assumption that security got outsourced along with everything else. It didn’t. Only the infrastructure moved. Whatever an organization builds on top of that infrastructure is still, entirely, its own problem, and that’s usually where things go wrong.

Part of the reason this gap persists is that cloud security requires knowledge most security teams didn’t need five or ten years ago. CCSP exam preparation is one way organizations are addressing that directly. The Certified Cloud Security Professional (CCSP) is an ISC2 credential covering cloud data security, cloud platform and infrastructure security, cloud application security, and the legal and compliance issues that come with running workloads on someone else’s servers. It was built around this responsibility line specifically, because that’s where cloud-focused staff need real fluency, not just familiarity.

Where things actually break

A handful of failure patterns show up again and again, starting with cloud storage buckets and databases that ship configured to be locked down, but the settings are easy to miss under deadline pressure, and a bucket meant for internal use quietly becomes reachable from anywhere. Identity sprawl is just as common, since access piles up quietly: a new service here, a contractor account there, and six months later nobody remembers why a particular service account still has admin rights to production. Identity and access management, or IAM, is supposed to catch this, but only when somebody owns it day to day instead of setting it up once and walking away.

Network exposure builds up the same way. A port opened for a migration. A firewall rule added for a one-off integration. A route nobody removed after the project ended. None of these look dangerous individually. Teams that haven’t audited their routing and access rules in a while are often surprised by what’s still open. That’s part of why protecting routing infrastructure has become as central to cloud security as access control, since the network layer and the application layer are no longer separate problems.

Then there’s encryption. It’s available almost everywhere in modern cloud platforms, and it still gets skipped, usually for internal traffic or legacy systems, on the assumption that “internal” means “safe.” It doesn’t. Once someone has a foothold inside a network, unencrypted internal traffic is what they go looking for next.

None of this requires a sophisticated attacker. It requires an organization that assumed the provider had things covered, or a team that never got the training to know what “covered” was supposed to mean. The costs aren’t abstract. Cyberattacks that start with a misconfigured cloud resource carry real financial damage, real downtime, and lasting reputational cost.

A skills gap that’s still catching up

Cloud adoption outpaced cloud security training at a lot of organizations, not because anyone dropped the ball, but because the timeline was tight. Infrastructure moved to the cloud over a handful of years. The specific expertise needed to secure it, shared responsibility boundaries, cloud-native identity models, provider-specific configuration risk, is still catching up in a lot of security departments.

That shows up as a real gap on the ground. A generalist security background covers a lot, but it doesn’t automatically teach which provider settings actually matter, how storage permissions propagate across a shared environment, or where cloud-native identity diverges from the on-premises model most security staff learned first. Organizations building out or restructuring a security function to actually cover this can find a useful starting point in this guide to building a cybersecurity team, which walks through role coverage and where the common blind spots sit.

The domains a cloud-focused certification covers line up almost exactly with the failure patterns above. Someone trained in cloud data security knows why a storage bucket needs deliberate configuration instead of a default setting. Someone trained in cloud platform security treats identity sprawl as something to design around, not something to clean up quarterly. For anyone making architecture decisions in a cloud environment, that background tends to be the difference between a team that responds to incidents and one that prevents them in the first place.

The bottom line

Provider infrastructure is, in nearly every case, more secure than what an individual organization could build on its own. That was never the risk. The risk lives in the part of the shared responsibility model that belongs to the customer: configuration, access control, network exposure, encryption. None of that gets fixed by switching providers. It gets fixed by making sure the people responsible for a cloud environment actually have the training to secure the parts of it that were always, in fact, theirs to secure.