The Cloud Breach Is Almost Never the Cloud's Fault

Executive Summary

When a significant cloud incident makes the news, the instinctive question inside many organizations is whether the cloud itself can be trusted. It is the wrong question. The overwhelming majority of cloud security incidents do not originate in a failure of the cloud provider's infrastructure. They originate in the customer's own decisions — a storage bucket left open, an over-privileged identity, a misconfigured service, a credential exposed in code — operating precisely as they were configured to operate.

This matters because it reframes the entire problem. The cloud is not an environment that must be defended at its perimeter, like a data center with a firewall at the edge. It is a vast, programmable surface where almost every exposure is the direct, traceable result of a configuration or identity decision the organization made. Cloud security, properly understood, is the discipline of governing those decisions at scale — not of building higher walls around someone else's infrastructure.

The organizations that struggle with cloud security are usually the ones still trying to apply a perimeter mindset to an environment that does not have a perimeter. The ones that succeed have internalized a different model entirely.

Why This Matters Now

The migration to cloud is no longer a project; it is the operating reality. Workloads, data and identities that once lived inside a controlled corporate boundary now live in environments that are accessed over the internet by default, provisioned by software, and changed continuously by teams across the organization. The attack surface is no longer a building. It is a configuration state that updates thousands of times a day.

Two dynamics make this acute. The first is speed: cloud infrastructure is created and modified through code and automation, which means a single mistaken setting can be replicated across an entire environment in seconds, and a single over-permissive template can propagate risk faster than any human review can catch it. The second is identity: in the cloud, identity has become the primary control plane. The traditional network boundary that once contained an attacker has been replaced by a web of human and machine identities, each with permissions that determine what can be reached. An attacker who obtains a powerful cloud identity does not need to breach a perimeter — there isn't one to breach.

CISO2CISO Insight

In the data center, the question was "how do we keep attackers out?" In the cloud, the question is "what did we accidentally leave open, and what can our own identities actually reach?" The threat is rarely the provider. It is our own configuration, working as designed.

The Shared Responsibility Model Is the Whole Story

The single most important concept in cloud security is also the most frequently misunderstood: the shared responsibility model. The provider is responsible for the security of the cloud — the physical infrastructure, the hardware, the foundational services. The customer is responsible for security in the cloud — how those services are configured, who can access them, what data is placed in them, and how identities are governed.

Most organizations understand this in principle and underestimate it in practice. They assume that moving to a reputable cloud provider transfers more responsibility than it actually does. The provider will secure the platform with resources no individual customer could match. But the provider cannot stop a customer from making a private dataset public, from granting an application far more permission than it needs, or from leaving a credential where an attacker can find it. Those are customer decisions, and they are where cloud breaches actually happen.

Misconfiguration is the dominant failure mode. The recurring theme in cloud incidents is not a sophisticated exploit of the platform. It is a setting — a permission, an exposure, an access control — configured in a way that created risk, often by a team moving quickly and unaware of the consequence. Cloud security is, more than anything, the discipline of preventing, detecting and correcting misconfiguration at the scale and speed the cloud operates at.

Identity and entitlements are the new perimeter. In a cloud environment, what an attacker can do is determined almost entirely by the permissions of the identity they compromise. Over-privileged identities — human and machine — are the cloud equivalent of an unlocked door to every room in the building. Managing entitlements down to least privilege is not a hardening nicety; it is the central control.

Visibility has to be continuous and automated. Because the environment changes constantly, point-in-time assessment is nearly worthless. The exposure that did not exist this morning may exist this afternoon. Effective cloud security depends on continuous, automated visibility into configuration and identity state — the function that modern cloud-native protection platforms exist to provide.

Executive Framework

What CISOs Should Do Next

• Establish continuous visibility into cloud configuration and identity state across every environment — you cannot govern a surface you can only see at a point in time.
• Make identity and entitlement management the centerpiece of the strategy, driving human and machine permissions toward least privilege and eliminating standing excess access.
• Treat misconfiguration as a systemic risk to be engineered out — through secure defaults, guardrails in infrastructure-as-code, and automated detection — not as individual mistakes to be caught after the fact.
• Clarify the shared responsibility boundary explicitly within the organization, so that teams provisioning cloud resources understand which security decisions are theirs to own.
• Embed security into the way cloud infrastructure is built, shifting controls left into the development and provisioning pipeline rather than inspecting only what is already running.
• Govern non-human and workload identities to the same standard as human ones, since they are often the most over-privileged and least reviewed identities in the environment.

Board-Level Questions

• Do we have continuous visibility into how our cloud environments are configured and who — human and machine — can access what?
• Are we clear on which aspects of cloud security are the provider's responsibility and which are ours, and are we resourcing our side of that boundary adequately?
• How are we preventing the misconfigurations and over-permissioned identities that cause most cloud incidents — not just detecting them afterward?
• If a cloud identity in our environment were compromised today, how much of our environment could it reach?

Final Executive Takeaway

The reassuring news about cloud security is also the demanding news: the cloud itself is rarely the problem. The provider operates the platform with a level of security investment that almost no organization could replicate independently. The breaches happen on the customer's side of the line — in configurations, permissions and identities that the organization controls and is responsible for.

That is demanding because it removes the comfortable narrative that cloud risk is something done to the organization by an external threat. Most cloud risk is something the organization does to itself, through decisions made at speed by teams that often cannot see the consequences. Securing the cloud means governing those decisions — making the secure path the default, the exposure visible, and the privilege minimal.

The cloud breach is almost never the cloud's fault. Which means the work of securing it is not about trusting the provider less — it is about governing our own configuration and identity decisions far better than we currently do.

*To be continued...*