The shared responsibility model is the way cloud providers divide security work with their customers: the provider secures the underlying cloud, and you secure what you put in it and how you configure it. AWS describes this as security "of" the cloud versus security "in" the cloud. Microsoft and Google publish similar models for their platforms, and most hosting and SaaS vendors work on the same principle.
For a small or mid-sized business, the point is simple: moving a website, database or office system to the cloud hands over some tasks, not all of them. Weak accounts, public storage and unpatched servers sit on the customer side of the line, and the provider will not fix them for you.
What the provider usually covers
In the major public clouds, the provider secures the infrastructure that runs its services, typically:
- Physical security: data centre buildings, access control, power and cooling.
- Hardware and physical network: servers, storage devices, routers and cabling inside its facilities.
- Virtualisation layer: the hypervisor that separates one customer's virtual machines from another's.
- Managed platform layers: for platform and software services, the operating system, runtime and much of the application stack.
What you always keep
Whatever service you choose, some responsibilities stay with your business. Microsoft's published guidance lists data, endpoints, accounts and access management as areas the customer always retains. In practice that means:
- Your data: what you store, who can see it, encryption choices, retention and backups.
- Identities and access: creating and removing user accounts, admin rights, multi-factor authentication and role-based access control.
- Configuration: sharing settings, firewall rules, storage permissions and which features are switched on.
- Devices: the laptops and phones staff use to sign in.
- Application credentials: API keys and tokens, which belong in proper secrets management, not in code or shared documents.
How the split changes by service type
The more of the stack the provider manages, the less you have to maintain — but the customer side never disappears.
- Infrastructure as a Service (IaaS): for example a cloud virtual machine. You manage the operating system, its updates and security patches, installed software and network rules. AWS gives EC2 as an example where the customer handles guest OS patching and security group (firewall) settings.
- Platform as a Service (PaaS): for example a managed app hosting service or managed database. The provider runs the servers and operating system; you remain responsible for your application code, its dependencies, configuration and access.
- Software as a Service (SaaS): for example cloud email or an online accounting system. The provider runs the application; you still control users, permissions, sharing settings, MFA and the data your team puts in.
Many businesses use all three at once, each with a different split.
Common gaps for SMEs
Typical gaps when responsibilities are assumed rather than written down:
- assuming the provider backs up your data in a way you can restore, without checking the service terms or testing a restore;
- storage buckets or shared folders left open to "anyone with the link" or to the public;
- a cloud server set up once and never updated — patch management on IaaS is the customer's job;
- admin accounts shared between staff or former contractors, with no MFA;
- no one assigned to watch alerts, logs or website monitoring, so problems are found by customers first;
- an IT vendor or developer who set things up, with no written agreement on who maintains them afterwards.
How to put the model into practice
You do not need a large security team. A practical starting point:
- List your cloud services: hosting, storage, email, databases, payment and line-of-business SaaS.
- Read each provider's responsibility page: check which tasks stay with you.
- Write a simple responsibility table: for each service, note who handles accounts, patching, backups, monitoring and incident contact — your staff, your IT provider or the cloud provider.
- Close the customer-side basics first: MFA on admin accounts, least-privilege access, private-by-default storage, tested backups.
- Review when things change: a new service, a new vendor, or staff leaving.
This fits a zero trust mindset: do not assume the cloud is safe by default.
Frequently asked questions
Does moving to the cloud make my business more secure?
It can, because the provider takes over physical security and infrastructure maintenance. It does not secure your accounts, data or settings for you; the result depends on how well your side is managed.
Is the split the same for every provider?
No. The general idea is similar, but the exact division varies by provider, service and contract. Check the provider's own documentation and your service terms rather than assuming.
If we outsource IT, who is responsible?
The cloud provider's side stays the same. Your side can be delegated to an IT provider or developer, but agree it in writing — who patches, backs up and monitors each system. Your business still owns the data and the decisions.
Does the provider back up our data?
Some services include backup or recovery features, but coverage, retention and restore options vary. Many providers treat data protection as a customer responsibility. Confirm what is included, add your own backups where needed, and test a restore.
If you want help mapping who is responsible for each part of your cloud setup, or closing the customer-side gaps, see our cybersecurity and compliance services. For ongoing maintenance with agreed response times, see managed support and SLA.