The model, in one sentence
Cloud providers are responsible for the security of the cloud — the physical data centres, the underlying hardware, the network infrastructure and the core services themselves. Customers are responsible for security in the cloud — how those services are configured, who has access, and how the data placed inside them is protected. Misunderstanding where this line sits, more than any single technical flaw, is the leading cause of cloud security incidents.
What the provider secures
- Physical security of data centres, including access control, surveillance and environmental protection.
- The underlying hardware, host operating system and virtualisation layer beneath customer workloads.
- Global network infrastructure, including protection against large-scale distributed denial-of-service attacks at the network edge.
- The security and availability of the managed service itself — for example, that a managed database engine is patched against known vulnerabilities in the database software.
What remains the customer responsibility, regardless of provider
- Identity and access management: who can access what, and whether permissions follow least privilege rather than broad, convenient grants.
- Data classification and encryption: whether sensitive data is encrypted, and whether encryption keys are managed appropriately.
- Network configuration: security groups, firewall rules, and whether resources are exposed to the public internet unnecessarily.
- Operating system and application-level patching for any compute the customer manages directly, such as virtual machines.
- Configuration of the managed services themselves — a correctly patched managed database can still be left publicly accessible by a customer configuration choice.
- Logging, monitoring and incident response for activity within the customer environment.
The line shifts depending on the service model
The exact split moves depending on what kind of service is being used. Infrastructure as a Service (a virtual machine) leaves the customer responsible for almost everything above the hypervisor, including the guest operating system. Platform as a Service (a managed database or a managed Kubernetes control plane) shifts more onto the provider, who now patches and secures the platform layer itself. Software as a Service shifts the most onto the provider, leaving the customer responsible mainly for identity, access and how the data within the application is configured and shared. Confirming which model applies to each service in use, and adjusting security effort accordingly, avoids both wasted effort and dangerous gaps.
The misconfigurations behind most real incidents
- Publicly accessible storage buckets (S3, Azure Blob, Cloud Storage) containing sensitive data, almost always the result of a permissive access policy rather than a provider vulnerability.
- Overly broad IAM roles and policies granted for convenience during initial setup and never subsequently tightened.
- Security groups or firewall rules left open to the entire internet on a port that should be restricted to specific known addresses.
- Unencrypted data at rest or in transit where encryption was available and simply not enabled.
- Default credentials or overly permissive default configurations left unchanged after a resource is provisioned.
- Logging and monitoring not enabled, so a breach that does occur is discovered weeks or months later rather than in near real time.
A practical starting checklist
- Enable and review the provider security posture tools by default: AWS Security Hub, Azure Security Center (Defender for Cloud), or GCP Security Command Center.
- Apply least-privilege IAM from the start, and review permissions on a regular schedule rather than only when they are first granted.
- Enforce encryption at rest and in transit as a default policy, not an opt-in decision made per resource.
- Restrict public network exposure to only what is genuinely required, and review it on the same schedule as IAM.
- Turn on centralised logging (CloudTrail, Azure Monitor, Cloud Audit Logs) before an incident, not after one.
- Run infrastructure as code with policy checks (via Terraform, CloudFormation, or equivalent) so misconfigurations are caught in review, not in production.
Frequently asked questions
Not if the breach genuinely occurred on the provider side of the line — the underlying infrastructure, hardware or the core managed service itself. Those incidents are rare and are the provider responsibility. The overwhelming majority of publicised cloud data breaches instead involve a customer-side misconfiguration, such as a publicly exposed storage bucket.
No. It shifts more of the security burden onto the provider, but configuration, access control and data protection choices remain the customer responsibility regardless of how much of the underlying platform is managed.
Overly broad access — either IAM permissions granted for convenience and never tightened, or storage and network resources left more open than necessary. Nearly every major publicised cloud breach traces back to some form of this.
The underlying principle is the same across all three, though the specific tools and terminology differ (Security Hub versus Defender for Cloud versus Security Command Center). The customer responsibility for identity, configuration and data protection is consistent across all of them.
The built-in security posture tools each provider offers do surface many common misconfigurations, but they need to be enabled and actively reviewed. None of the three enables and monitors this automatically as a substitute for a customer security programme.
At minimum quarterly for most organisations, with automated alerting for high-risk changes (such as a new highly privileged role) reviewed immediately rather than waiting for the next scheduled review.
How we can help
Migrations that build the correct access and network baseline from day one.
Solution Design & ArchitectureNon-functional requirements, including security, designed in before the build starts.