There is a line in every major cloud provider's documentation that customers read, understand, and then fail to act on. It says, in various phrasings, that the provider is responsible for the security of the cloud and the customer is responsible for security in the cloud. By 2012 this framing had become standard across the industry. It was clear, it was published, and it was almost universally misread — not because the wording was ambiguous, but because customers had spent a decade buying hosting where the boundary sat somewhere else entirely, and because the sales conversation encouraged the comfortable interpretation. The pattern of failures that followed over the next decade did not involve providers failing to meet their obligations. Almost all of them involved customers not realising they had any.
What the Model Actually Says
The division is precise and it varies by service type, which is the part that causes most of the confusion. Infrastructure as a service. The provider secures the physical facilities, the hardware, the hypervisor and the network fabric. The customer is responsible for the operating system, patching, application code, network configuration, access control, encryption and data. This is the widest customer obligation, and it is close to the full responsibility of running your own servers minus the building. Platform as a service. The provider additionally manages the operating system and runtime. The customer retains application security, configuration, identity and data. Software as a service. The provider runs almost everything. The customer retains identity and access management, configuration of the application's own security settings, data classification, and decisions about who sees what and what integrates with what. In every model, without exception, the customer owns identity, access and data. That is the constant, and it is also where the overwhelming majority of real incidents originate.
Where Customers Consistently Misread It
Five misconceptions recur, and each has produced its own category of breach. "Their security certifications cover us." A provider's SOC 2 or ISO 27001 attests to the provider's controls over the provider's scope. It says nothing about whether your storage bucket is public or your administrative account has a weak password. Certification is evidence about one half of the boundary. "Data in the cloud is encrypted." Usually true at rest and in transit, and largely irrelevant to the common failure mode. Encryption protects against physical theft and interception. It does not protect against a misconfigured permission, because the authorised path decrypts automatically. "The default configuration is secure." Defaults are chosen to make services work and to reduce support load, not to minimise your risk. Many of the most publicised cloud data exposures were default or convenience settings left in place — openly accessible storage, unrestricted network rules, permissive service accounts. "The provider backs everything up." Providers protect against their own infrastructure failure. They do not generally protect you against your own deletion, a ransomware event in your account, or a corrupted synchronisation — and SaaS retention windows are frequently far shorter than customers assume. "Availability is guaranteed." The SLA specifies a credit, not a guarantee. A service credit for a few hours of downtime does not compensate for a day of lost trading, and the contractual cap almost always sits far below the business consequence.
The Structural Reason This Keeps Happening
It is tempting to attribute this to carelessness. The more accurate explanation is that cloud adoption relocated security work to people who did not know they had inherited it. When a server sat in a data centre, an infrastructure team with security training built it, patched it and configured its firewall. When the same workload moved to a cloud console, the person provisioning it was frequently a developer or an analyst, working quickly, using defaults, with no formal handover of the responsibilities the infrastructure team used to discharge. The controls did not fail. They were never assigned. That is an organizational problem dressed as a technical one, and it explains why the same misconfiguration categories appeared in company after company for a decade.
Practical Guidance for Shared Responsibility
- Write down the boundary for each service you use, and have both sides agreed internally. Not the provider's generic diagram — your specific services, with a named owner for every customer-side control. Unassigned responsibilities are unperformed ones.
- Treat identity as the primary control surface. Multi-factor authentication on all administrative access, no standing privileged roles, no shared accounts, and regular review of who holds what. In SaaS this is most of your available attack surface.
- Scan continuously for misconfiguration rather than auditing periodically. Public storage, open network rules, over-permissive service identities and unencrypted volumes should be detected within minutes of appearing, because that is how quickly they are found by others.
- Own your own backups. Verify what the provider actually retains and for how long, then take independent copies of anything you could not operate without. Test a restore. An untested backup is a belief.
- Configure logging deliberately and retain it. Cloud audit logs are frequently off by default or retained briefly. Without them, an incident cannot be investigated and the question of what was accessed has no answer.
- Read the SLA for what it excludes. The credit, the exclusions, the notice periods, the data export terms and what happens at termination matter more than the uptime percentage on the front page.
- Cover configuration in change management. A cloud console change can expose a dataset instantly and leaves no physical trace. It deserves the same review as a production deployment.
- Assign the responsibility explicitly when workloads move. Migration projects should hand over each customer-side control by name to a named owner. This single step prevents most of what goes wrong.
The Data Residency Layer
For organizations in this region, the model has a dimension that the standard diagram omits: the provider's responsibility is technical, while the customer's responsibility for regulatory compliance is absolute and non-delegable. A provider offering a UAE or Saudi region has made it possible to keep data in-country. It has not made you compliant. Which region a service is provisioned in, where backups replicate to, where support staff access from, which sub-processors are involved and whether the specific service is even available locally are all customer decisions — and regulators here hold the controller accountable regardless of what the provider's contract says. The practical failure is mundane and common: a primary workload correctly placed in-region, with a logging service, a backup target or an analytics add-on quietly defaulting to a location elsewhere. Nobody checked, because the provider was assumed to have handled it.
Why This Is Getting Harder Again
The shared responsibility model was hard enough to apply when the services were storage, compute and databases. The current generation of AI and data services has reintroduced exactly the same ambiguity at a new layer. Who is responsible if a model is fine-tuned on data that should not have left a jurisdiction? Whether prompts and outputs are retained, for how long, and whether they are used in training. Whether an AI feature enabled by default in a SaaS product has access to documents that a particular user should not see. What the audit trail looks like when an agent performs an action on a user's behalf. These are exactly the questions that were unclear about cloud storage in 2012, asked again about a less mature set of services, and the pattern of misreading is identical: customers assume the provider has handled what is in fact a configuration they own. The response is the same one that worked before. Read what the provider actually commits to, write down what remains yours, assign it to a named person, and verify it rather than assuming it.
Common Questions
What is the cloud shared responsibility model?
The division of security duties between provider and customer. The provider secures the underlying infrastructure; the customer secures what they put on it — configuration, identity, access and data. The exact line moves depending on whether the service is infrastructure, platform or software.
What is the customer always responsible for?
Identity and access management, data classification, and the security configuration of the service itself. These remain the customer's obligation in every service model, and they are where most real-world cloud incidents originate.
Does a provider's SOC 2 certification cover the customer?
No. It attests to the provider's controls within the provider's scope. It provides no assurance about the customer's configuration, permissions or access management, which are assessed separately and remain the customer's responsibility.
Do cloud providers back up customer data?
They protect against their own infrastructure failure, not generally against customer deletion, ransomware within the customer's account or corrupted data. Retention windows in SaaS products are often much shorter than customers assume, so independent, tested backups remain necessary.
Cloud Configuration Review — Outpace maps which side of the line each control sits on, finds the ones nobody owns, and fixes the misconfigurations before somebody else finds them.