Cloud Shared Responsibility Model Explained

The shared responsibility model says that the cloud provider secures the cloud itself, meaning the physical data centres, hardware and core virtualisation, while you are responsible for security in the cloud: your data, identities, access rules, configuration and the applications you run. The exact boundary moves depending on the service type, but one point never changes. The customer always remains responsible for their own data and for who is allowed to access it.

Misunderstanding this line is one of the most common causes of cloud security incidents. Providers such as AWS and Azure publish their own descriptions of the model, and you should read them for the services you use. This article explains the idea in practical terms, shows how the split shifts between virtual machines, platform services and software-as-a-service, and gives you a checklist for your side of the line.

The model in one sentence

Think of renting an office in a managed building. The landlord is responsible for the structure, the lifts, the front-door security and the electricity supply. You are responsible for who you give keys to, whether you lock your own office, what you leave on your desk and how you vet your staff. A burglar who walks through an unlocked office door is not the landlord's failure.

How the boundary shifts by service type

The more managed the service, the more the provider takes on. The more control you have, the more you must secure.

Layer	Infrastructure (IaaS), e.g. virtual machines	Platform (PaaS), e.g. managed databases, app services	Software (SaaS), e.g. Microsoft 365
Physical data centre, hardware, network	Provider	Provider	Provider
Hypervisor and core platform	Provider	Provider	Provider
Operating system and patching	You	Provider	Provider
Runtime, middleware	You	Shared or provider	Provider
Application code	You	You	Provider
Network and firewall rules for your resources	You	You (configuration)	Limited
Identity and access management	You	You	You
Your data, its classification and its protection	You	You	You

The details vary by provider and by individual service, so verify the split in the documentation for each service you adopt. Managed services are not "someone else's problem": they remove some of your tasks and leave the configuration, access and data decisions with you.

What the provider typically handles

• Physical security of facilities, power and cooling.
• Hardware lifecycle and replacement.
• The network backbone and the isolation between customers.
• The security of the virtualisation layer and the core services.
• Compliance certifications and audit reports for their own controls, which you can use as evidence in your own assessments.

What you are responsible for

1. Identity and access

Most cloud breaches involve credentials or over-permissioned accounts, not clever attacks on the platform. Priorities:

• Enforce multi-factor authentication on every human account, above all the root or global administrator.
• Apply least privilege: grant only the permissions a person or service needs.
• Prefer short-lived credentials and roles over long-lived access keys. CI/CD systems can use federation instead of stored keys, as in our GitHub Actions guide.
• Remove accounts and keys when people leave or projects end.
• Separate production from development with distinct accounts or subscriptions.

2. Data protection

• Know what data you hold and how sensitive it is, including personal data subject to GDPR. For legal interpretation, take advice from a qualified professional; this article is not legal advice.
• Encrypt data at rest and in transit, and manage keys deliberately.
• Check storage permissions. Publicly readable storage buckets are a recurring source of exposure.
• Back up data and test restores; see disaster recovery in the cloud.

3. Configuration and network

• Close management ports such as SSH and RDP to the open internet; use a bastion, VPN or provider session tooling.
• Keep security groups and firewall rules narrow, and review them regularly.
• Use private networking for databases and internal services.
• Turn on the provider's baseline security tooling and review its findings.

Misconfiguration is the largest category, and it is best addressed by defining infrastructure in reviewed code, as described in infrastructure as code with Terraform, and by adding automated policy checks to pipelines.

4. Workloads and applications

• Patch operating systems on virtual machines, and rebuild container images regularly (see Docker explained).
• Follow secure development practice and test against the OWASP Top 10 web application risks.
• Scan dependencies and images for known vulnerabilities.
• Store secrets in a managed secret store, never in code or images.

5. Logging, monitoring and response

• Enable audit logging of administrative actions and keep the logs somewhere an intruder cannot easily erase.
• Alert on suspicious events, such as new administrator accounts, disabled logging or unusual regions in use.
• Write an incident response plan, with contacts and a decision on who can isolate systems. The monitoring principles in our other article apply to security signals too.

A practical responsibility matrix

For each important system, write down a short table like this and keep it with your documentation:

Control	Provider	Us	Named owner
Physical security	Yes	No	n/a
OS patching on VMs	No	Yes	Platform team
Database engine patching (managed)	Yes	Maintenance windows and versions	Platform team
User access reviews	No	Yes	IT lead
Data classification	No	Yes	Data owner
Backups and restore tests	Tooling	Policy and testing	Platform team

The "named owner" column matters most. A control that belongs to "the team" in general belongs to nobody.

Common mistakes

• Assuming the provider backs up your data. Many services offer durability, which is not the same as protection from deletion, corruption or ransomware. Configure real backups.
• Using the root account for daily work. Lock it away with strong MFA and use named, least-privilege roles.
• Leaving storage public by accident. Enable account-level blocks on public access where you do not need it.
• Treating compliance certificates as your compliance. The provider's certification covers their layer. Yours must cover your configuration and processes.
• Permanent access keys in code repositories. They get found. Use roles, federation and secret scanning.
• Ignoring the managed-service boundary. A managed database still needs sensible network rules, access control and encryption settings.
• No logging. Without audit logs you cannot tell what happened after an incident.
• One-off reviews. Configuration drifts. Review continuously, ideally with automated checks.
• Forgetting SaaS. Even in Microsoft 365 or similar tools, you still own accounts, sharing settings, MFA and data retention.

Making it stick in a small team

Small teams cannot review everything by hand, so lean on automation. Turn on the provider’s built-in security posture tooling, send its findings to a channel that someone actually reads, and set a short, regular slot to work through them. Use policy rules to block the worst mistakes before they reach production, such as public storage or open management ports. Review who has administrator rights each quarter, because access tends to accumulate as people change roles. None of this needs a large budget; it needs named owners and a routine that survives busy periods.

A starter checklist

1. MFA on all human accounts, with the root account locked down.
2. Separate accounts or subscriptions for production and non-production.
3. No public storage unless deliberately and reviewably public.
4. Management ports closed to the internet.
5. Encryption at rest and in transit enabled, and keys owned.
6. Audit logging on, stored securely, with alerts on risky events.
7. Patching and image rebuild routine in place.
8. Secrets in a secret manager.
9. Backups tested by restoring them.
10. A written, owner-assigned responsibility matrix.

Summary

The provider secures the platform; you secure what you put on it and who can reach it. Settle ownership explicitly, start with identity, data and configuration, and automate checks so that good settings persist. If you would like help translating this into concrete controls, CloudWiss's cloud and DevOps services include security compliance work as part of cloud infrastructure delivery, alongside monitoring, backup and recovery design.