Ask a business leader who’s responsible for securing their company’s cloud environment, and the answer is almost always the same: the cloud provider. It’s an understandable assumption. Cloud platforms are marketed on reliability and security, and the infrastructure behind them genuinely is built by teams with more resources than nearly any individual company could match on its own.
The assumption is also incomplete, and that gap is exactly where a large share of breaches originate. Every major cloud platform operates under what’s known as a shared responsibility model. The provider secures the infrastructure itself, the physical data centers, the network backbone, and the hardware. Everything running on top of that, user access, configuration settings, data permissions, and identity management, remains the customer’s responsibility. Most companies never read that distinction closely enough to understand where their own obligation actually begins.
Where the Misunderstanding Leads
That gap in understanding shows up clearly in the data. Verizon’s 2025 Data Breach Investigations Report found that stolen or compromised credentials remain among the most common ways attackers gain initial access to a network, and that a large majority of basic web application attacks specifically relied on stolen credentials rather than a technical exploit. None of that requires breaking through a cloud provider’s infrastructure. It requires finding one weak password, one overly permissive access setting, or one account that was never removed after an employee left.
This is the part the shared responsibility model makes clear and marketing materials often gloss over: the cloud provider isn’t going to stop a breach caused by a misconfigured storage bucket, an employee reusing a compromised password, or an access permission nobody remembered to revoke. Those failures sit entirely on the customer’s side of the line.
Where Responsibility Actually Splits
| Typically the Cloud Provider’s Responsibility | Typically the Customer’s Responsibility |
| Physical data center security | User access management and permissions |
| Network infrastructure and hardware | Data encryption and classification |
| Platform uptime and availability | Identity and authentication controls |
| Underlying virtualization security | Application-level configuration |
The right side of that table is where most preventable breaches actually happen. It’s also the side most companies pay the least attention to, because it doesn’t feel like “cloud security” in the way the provider’s marketing describes it.
Why the Assumption Persists
Part of the reason this misunderstanding sticks around is that cloud migrations are often sold and executed as a technical project rather than an ongoing operational responsibility. A company moves its systems to the cloud, the migration goes smoothly, and everyone moves on assuming the hard part is finished. In reality, the migration is the easy part. Managing access, monitoring configuration drift, and keeping identity controls current are the part that requires continuous attention long after the migration project has technically ended.
Companies evaluating providers of cloud services in Los Angeles increasingly ask a pointed question during vendor selection: who is monitoring our access and configuration after the migration is done? A provider that treats the migration as the finish line, rather than the starting point of an ongoing security relationship, is one that leaves the customer holding the exact responsibilities most likely to lead to a breach.
The Configuration Problem Nobody Budgets For
Beyond credentials, the other recurring failure point is configuration drift. A storage bucket gets set to public during testing and never gets locked back down. A new application gets deployed with default permissions that are broader than necessary. An old service account retains access long after the project it supported has ended. None of these require a sophisticated attacker. They require someone to notice, and in a fast-moving cloud environment, noticing requires deliberate monitoring rather than a one-time setup checklist.
A Short List of Questions Worth Asking
Businesses trying to gauge whether they’ve fallen into the shared responsibility gap can usually get a clear answer from a few direct questions:
- Who reviews access permissions on a recurring schedule, not just when the system was first set up?
- Is multifactor authentication enforced across every account with cloud access, including service accounts?
- How quickly are former employees’ and vendors’ credentials revoked after their access is no longer needed?
- Has anyone audited storage and database configurations for public exposure in the last quarter?
A business that can’t answer these confidently is likely operating with the exact gap that shows up in breach reports every year.
Why This Matters More as Environments Grow
The gap between assumption and reality widens as a company’s cloud footprint grows. A business running a handful of cloud applications can often track access and configuration manually, even if imperfectly. A business running dozens of interconnected services, each with its own permission sets and integrations, cannot realistically maintain that level of oversight without a dedicated process behind it. The complexity that makes cloud infrastructure powerful is the same complexity that makes manual oversight unreliable past a certain scale.
This is where the distinction between a basic cloud hosting arrangement and genuinely managed cloud services becomes more than a marketing phrase. A hosting relationship ends at uptime and infrastructure. Managed cloud services in Los Angeles or any other market extend into the ongoing access reviews, configuration audits, and identity management that sit squarely on the customer’s side of the shared responsibility line. The businesses that treat that distinction as meaningful, rather than interchangeable, are the ones less likely to discover their gap the hard way.
Closing the Gap Requires Ownership, Not Just Awareness
Understanding the shared responsibility model is a start, but understanding alone doesn’t close the gap. Someone still has to own the customer side of that line on an ongoing basis, reviewing access, auditing configurations, and enforcing identity controls as the environment changes. That ownership is where cloud security actually lives day to day, far more than in any feature the underlying platform provides out of the box.
The companies that avoid becoming another line in next year’s breach report aren’t the ones with the most expensive cloud platform. They’re the ones who understood early that moving to the cloud shifted where their security responsibility begins, rather than removing it entirely.