Cloud security failures are rarely failures of the platform. They are usually a misunderstanding about where the provider's obligation ends, acted on for long enough that nobody rechecks it.
This page sets out the model, how the boundary moves between service types, and which controls remain the customer's in every case. The security operations work that sits on top of it, including detection, investigation and response, is covered in Cloud Security.
The line, as the providers state it
Amazon describes the split as security of the cloud against security in the cloud: the provider is responsible for protecting the infrastructure that runs the services, and the customer is responsible for what they deploy and configure on it. See AWS, Shared Responsibility Model.
Microsoft presents the same idea as a matrix, laying out each responsibility area against on-premises, infrastructure as a service, platform as a service and software as a service, and showing responsibility transferring to the provider as you move along that row. See Microsoft, Shared responsibility in the cloud.
The line moves with the service model
With infrastructure services you receive compute, storage and networking, and everything above the hypervisor is yours: the operating system, its patching, the runtime, the application, the data and the access to all of it.
With platform services the provider takes the operating system and the runtime, leaving the application, its configuration, the data and the permissions. With software services almost everything is theirs except the two that never move.
Three things are always yours
Whatever the service model, the customer retains responsibility for their data, for who can reach it, and for how the service is configured.
That is the whole of the practical security problem in most estates. A provider cannot know whether a storage container should be public, whether an administrator should hold standing privileges, or whether a dataset belongs in that region. Those are decisions about your business and they are made in your console.
Identity is the new perimeter, and it is yours
In a cloud estate, permissions do what the firewall used to. An over-permissive role is reachable from anywhere the credential is, which makes identity design the highest-leverage security work available.
The recurring failures are familiar: permissions granted broadly during a deployment and never narrowed, long-lived access keys in code or on a laptop, administrative access that is standing rather than requested, and service accounts holding far more than their function requires. None of these are platform weaknesses and all of them are customer responsibilities.
Misconfiguration is the dominant failure mode
The characteristic cloud incident is not an exploited platform vulnerability. It is a resource exposed by a setting: storage left open, a database reachable from the internet, a security group opened for troubleshooting and never closed, a snapshot shared more widely than intended.
These are cheap to detect and cheap to prevent, which is the frustrating part. Continuous configuration checking, guardrails that prevent the dangerous setting rather than reporting it afterwards, and infrastructure expressed as reviewable code between them remove most of the category.
Compliance inheritance is partial, and the part matters
A provider's certifications cover the provider's responsibilities. Building on a certified platform means the underlying controls have been examined; it does not mean your workload is compliant, because the controls on your side of the line have not been looked at by anyone.
This is where the phrase "we are on a compliant platform" does real damage in procurement. The platform's attestation is evidence about the platform. Your obligations are evidenced by your own controls, your own configuration and your own assessment.
Federal programs make the split explicit
In United States federal procurement the mechanism for authorizing a cloud service is FedRAMP. The FedRAMP program management office resides within the General Services Administration and supports agencies and cloud service providers through the FedRAMP authorization process, with one of its stated purposes being to enable reuse of security packages so that an authorization performed once can be relied on by other agencies. See GSA, FedRAMP.
What that authorizes is the service. An agency deploying onto an authorized service still holds the controls in its own boundary, which is why an authorization is a starting point for an agency assessment rather than a substitute for one.
The control catalogue does not move to the provider
Federal systems are assessed against a control catalogue whatever the hosting model. NIST SP 800-53 Revision 5 sets out those controls, including provisions such as CP-9 SYSTEM BACKUP and the requirement for an ALTERNATE PROCESSING SITE. See NIST SP 800-53 Revision 5.
Some of those controls become inherited when a service is used, some become shared, and some remain wholly the customer's. Producing that mapping honestly, control by control, is the work that turns a hosting decision into an authorizable system, and it is the work most often deferred.
Federal guidance on customer-side configuration
The federal position is not that the provider's assurance is sufficient. CISA's Secure Cloud Business Applications project exists specifically to publish secure configuration baselines for widely used cloud services, which is an acknowledgement that the customer-configurable surface is where the risk concentrates. See CISA, Secure Cloud Business Applications (SCuBA) Project.
The useful reading for any organization, federal or not, is that published baselines exist and are worth measuring an estate against rather than inventing a standard locally.
Patching, and the question people get wrong
Who patches what follows directly from the service model, and it is the responsibility most often assumed away. On infrastructure services the guest operating system and everything above it is the customer's, including the kernel, the runtime and the libraries the application depends on. On platform services the provider maintains the runtime and the customer still owns application dependencies.
The trap is a managed-sounding service that is not managed in the relevant sense. A virtual machine offered through a marketplace listing, with a vendor name attached, is still a virtual machine whose operating system nobody else is updating. Server and Operating System Management covers the discipline that follows.
Where the model is silent
Responsibility matrices describe technical controls and say nothing about several things that decide outcomes: who is on call, how quickly a report is acted on, who notifies whom, and what happens when the two parties disagree about whether an event is an incident.
Those belong in the operating agreement rather than the responsibility model, and leaving them to the model is how an organization discovers mid-incident that everybody involved believed somebody else was co-ordinating.
Logging is yours to enable and to keep
Platforms generate control-plane and data-plane logs, and in most cases they are not retained by default for as long as an investigation needs. Enabling them, centralizing them, protecting them from deletion by the account they describe, and keeping them long enough are customer responsibilities.
The requirement is easiest to see backwards. During an incident the question is what happened and when, and a log that was not enabled three months ago cannot be enabled retrospectively.
Encryption, and who holds the key
Providers encrypt storage by default, which addresses one threat: physical media leaving the facility. It does nothing about a credential with permission to read the data, because that request is authorized and the platform decrypts it.
Deciding who holds the key determines what encryption is actually protecting against. Provider-managed keys are operationally simple; customer-managed keys let you revoke access independently of the platform's permission system. Both are legitimate, and the choice should follow from a stated threat rather than from a default.
Availability responsibility is shared too
Providers offer zones and regions; using them is the customer's decision. A workload running in one zone is exposed to that zone, and no commitment from the provider changes that.
The same is true of backup: managed services run the machinery, and retention, immutability and the existence of a copy outside the account remain yours. Backup and Data Protection covers what that means in practice.
Third parties extend the line further
Every software service in the estate adds another provider with its own model, and the aggregate is what actually protects the organization's data. Integrations between them create paths that neither provider's model describes.
Knowing which services hold what data, and what each provider's boundary is, is unglamorous inventory work that pays for itself the first time a supplier has an incident.
Writing the boundary down
The recurring cause of gaps is not disagreement but assumption. Each party assumes the other is handling something, and nobody is. Patching, key rotation, log review, certificate renewal and configuration monitoring are the usual candidates.
LABUSA's approach to managed infrastructure is boundary-first for exactly this reason: agree what is in scope, what is not, and who holds each responsibility before the operational work starts. The managed service this boundary work belongs to describes how that runs across cloud, private and hybrid estates, including for public-sector obligations covered in Government and Public-Sector Cloud Infrastructure.