Read your provider’s contract once and the whole argument disappears. Amazon, Microsoft and Google will secure the buildings, the power, the hypervisor and the physical network. Everything you put on top of that, your data, your user accounts, your configuration choices, stays yours. That split is the shared responsibility model, and the reason it matters is blunt: when a cloud incident makes the news, the failure is usually on the customer’s half of the line.
What the model actually says
AWS states the split in five words: security of the cloud versus security in the cloud. AWS takes the hardware, the software that runs its services, the networking and the facilities. You take whatever you choose to build. The company is careful to add that your exact share depends on which services you pick, because a managed database hands you far less to patch than a bare virtual machine does.
Microsoft frames it as a diagram that slides. In an on-premises data centre you own the whole stack. As you move to infrastructure, platform and then software services, rows of that stack transfer to Microsoft, and the documentation is explicit that four things never move: your data, your endpoints, your accounts and your access management.
Google goes one step further with what it calls shared fate. The argument is that a provider which simply hands you a responsibility matrix and walks away has not really helped, so Google publishes secure-by-default blueprints, opinionated foundations and even a Risk Protection Programme that ties cyber-insurance to your measured configuration. The responsibility boundary is the same. The support on your side of it is better.
Three providers, three vocabularies, one boundary. The provider protects the platform. You protect the use you make of it.
Where the line moves: IaaS, PaaS and SaaS
The useful version of this model is not a slogan, it is a grid. Microsoft publishes the division of responsibility by deployment type, and the table below follows that structure. Read it top to bottom and you can see your workload’s real surface area.
| Layer | On-premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Data classification and accountability | You | You | You | You |
| Client and endpoint protection | You | You | You | You |
| Identity and access management | You | You | Shared | Shared |
| Application-level controls | You | You | Shared | Provider |
| Network controls | You | Shared | Provider | Provider |
| Host infrastructure | You | Shared | Provider | Provider |
| Physical hosts, network and data centre | You | Provider | Provider | Provider |
Two rows deserve a second look. Identity sits in your column or in the shared column every single time, which is why access review is the highest-value hour in any cloud audit. And network controls become the provider’s job only when you buy a platform or software service. Lift a server image into a virtual machine and the firewall rules are still yours to get wrong.
- A managed database patches its own engine. It does not decide whether the listener is reachable from the public internet.
- Object storage encrypts at rest by default on all three major providers. It still serves whatever you mark as public.
- A managed Kubernetes control plane is the provider’s. The container images, the admission rules and the service accounts are yours.
Why the customer side is where breaches start
Verizon’s 2026 Data Breach Investigations Report, published in May 2026, recorded a change worth sitting up for. Exploitation of software vulnerabilities became the single most common way into an organisation at 31% of breaches, overtaking stolen credentials for the first time in the report’s 19-year history. Credential abuse fell to 13%. Social engineering accounted for 16%, and the human element appeared in 62% of breaches overall.
Look at those three bars against the grid above. Patching your application dependencies, protecting your staff from a convincing message and rotating your own keys all sit squarely in the customer column. None of them is something AWS, Azure or Google Cloud can do on your behalf, however good their underlying platform is.
The money side is just as pointed. IBM’s 2026 Cost of a Data Breach Report puts the global average cost of a breach at USD 4.99 million, a 12% rise on the year before and a record for the study. IBM reframes that as roughly USD 1,100 for every hour the incident runs, which is a more useful number when you are arguing for a budget: every hour you shave off detection and containment has a price tag attached.
The four jobs that never transfer
Strip the model back and four responsibilities follow you across every provider and every service model. Microsoft lists them plainly, and they are a better starting checklist than any vendor diagram.
- Your data. Classification, retention, encryption decisions and the legal obligations that attach to it. A provider can offer you a key management service. It cannot decide which fields count as personal data in your business.
- Your endpoints. Laptops and phones reach into the cloud with real credentials. An unmanaged device holding a long-lived token is a cloud security problem wearing a desk-side costume.
- Your accounts. Joiners, movers and leavers. Dormant administrator accounts are the most common finding in the reviews we run, and they are entirely free to fix.
- Your access management. Who can assume which role, from where, with what second factor, and who approved it. This is the control that turns a single stolen password into a non-event.
If you only have budget for one improvement this quarter, spend it on the third and fourth items. Multi-factor authentication on every administrative account and a documented leaver process cost almost nothing and remove the cheapest attack available to anyone targeting you. We have written about that trade-off in more detail in single cloud versus multi-cloud, where the same identity discipline decides how painful a second provider really is.
What holding your side of the line costs
Holding your side of the line is cheaper than most owners expect, because the controls that matter most are licence lines rather than projects. Microsoft’s published list price for Defender for Business is USD 3.00 per user per month on an annual subscription, covering up to 300 users with up to five devices each. Bundle it into Microsoft 365 Business Premium and the list price is USD 22.00 per user per month, or USD 18.79 for the version without Teams. Those were the figures on Microsoft’s own pricing page in October 2026.
| Control | List price (October 2026) | What it covers on your side of the line |
|---|---|---|
| Microsoft Defender for Business | USD 3.00 per user / month | Endpoint detection and response, next-generation antivirus, up to 300 users |
| Microsoft 365 Business Premium | USD 22.00 per user / month | The above plus identity, device management and data protection |
| Microsoft 365 Business Premium (no Teams) | USD 18.79 per user / month | Same bundle for organisations that already use another collaboration tool |
| Multi-factor authentication on admin accounts | No licence cost on major providers | The single highest-value control in the customer column |
Set that against the IBM average and the maths is uncomfortable rather than close. A thirty-person office on Business Premium pays USD 7,920 a year at list price. One breach at the global average costs six hundred times that. We are not suggesting licences alone prevent incidents, and plenty of good security costs nothing but attention. The point is that the cheap half of your responsibility is genuinely cheap.
A quarterly review that takes about ninety minutes
Here is the review we run with clients who have a single cloud account and fewer than fifty staff. It is deliberately short, because a review you actually perform beats a forty-page framework you abandon in March.
- List your administrators. Every account with a privileged role, human or machine. Confirm each one still has a named owner and a second factor. Twenty minutes.
- Check what is reachable from the internet. Public storage buckets, open database ports, management interfaces, forgotten test environments. Twenty minutes.
- Review your keys and tokens. Anything older than ninety days, anything in a repository, anything shared by more than one service. Fifteen minutes.
- Test one restore. Not the backup job’s green tick, an actual restore of one real file or table. Twenty minutes, and the most commonly skipped step in the list.
- Write down what you changed. Five minutes, and it turns the next review into a comparison rather than a fresh start.
Nothing in that list requires a specialist tool. All three major providers expose it through their own consoles and free security dashboards. The reason it does not happen is that nobody owns it, which is a management problem dressed as a technical one. Put a name and a recurring calendar entry against it and most of the risk in a small cloud estate simply evaporates.
Two neighbouring decisions change how much work this review involves. The architecture you pick shifts your share: read our look at serverless for how a managed runtime removes patching from your column entirely. And your recovery design decides how bad a bad day gets, which we cover in four cloud disaster-recovery patterns by budget.
Getting a second pair of eyes on it
Eudora Technology works remotely with clients across several time zones, and a configuration review is one of the things that genuinely does not need anyone in the room. Our cloud solutions service covers exactly the customer column described above: identity and access review, public exposure checks, key hygiene, backup verification and a written set of findings you can hand to whoever maintains your systems. If your business also needs on-site work in Sri Lanka, that is handled by our local sister operation at eudora.lk.
The honest version of this advice is that you probably do not need to buy anything new. You need to know which half of the line each control sits on, and you need someone to check your half on a schedule. That is the whole model.
Frequently asked questions
If my provider is certified to ISO 27001, am I covered?
No. Certifications cover the provider’s controls, which you inherit for things like physical security. AWS calls these inherited controls and publishes audit attestations so you can see exactly which ones they are. Your own configuration, accounts and data handling sit outside that scope and are assessed separately if you are certified yourself.
Does moving to software as a service remove my responsibility?
It removes most of it, not all. Microsoft’s own matrix keeps data classification, endpoint protection, identity and access management in your column even for software services. In practice that means a SaaS breach usually traces back to an account that should not have existed or a permission nobody reviewed.
Who is responsible if a provider region goes down?
Availability of the region is the provider’s responsibility. Designing your workload to survive the loss of one is yours. That is why AWS documents recovery strategies ranging from backup and restore through to multi-site active-active, and expects you to choose one against your own recovery objectives.
How often should a small business review its cloud configuration?
Quarterly for a stable estate, and immediately after any change in staff with administrative access. The ninety-minute checklist in this article is the version we use with clients who have one cloud account and no dedicated security staff. Bigger or regulated estates need more, but the sequence stays the same.
Is misconfiguration still the main cause of cloud breaches?
It remains a leading cause, but the 2026 DBIR shows unpatched software overtaking credential theft as the top entry point at 31% of breaches. Both live in the customer column. The practical reading is that patch discipline now deserves as much attention as access control, not less.
Want your cloud configuration reviewed against the customer side of the shared responsibility model, with a written findings list rather than a dashboard screenshot? Get in touch with Eudora Technology to talk about your project.
.jpg){kind=link}