SaaS Shared Responsibility Model: Who Secures What
If you run an Australian SaaS business, you sit in the middle of two shared responsibility relationships, not one. Your cloud provider secures the physical data centres, the hardware and the hypervisor. You secure everything you build and configure on top: your application code, identity and tenant isolation, encryption keys, logging, backups and every cloud setting. Your customers secure who they invite in and what they upload. Your provider’s certificates cover their layer only, never yours.
That middle position is the part generic explainers miss, and it is the part a customer security review will test.
What is the shared responsibility model?
The shared responsibility model is the division of security duties between a cloud provider and its customer. Amazon Web Services frames it as security of the cloud, which is theirs, versus security in the cloud, which is yours. Microsoft Azure and Google Cloud publish equivalent models with the same underlying logic.
Where the line falls depends on the service type. For infrastructure services such as virtual machines, you own the operating system, the patching and everything above it. For managed services such as a hosted database, the provider takes the operating system and the engine, and you keep the schema, the access control and the data. For fully managed platform services you keep less still, but you never reach zero, because configuration and access are always yours.
The trap is assuming that managed means secured. A managed database with a public endpoint and a weak password is a provider doing its job correctly and a customer doing theirs badly.
Why does an Australian SaaS business have three layers, not two?
Standard explanations of the shared responsibility model describe two parties: the cloud provider and the customer. A SaaS business is both. You are the customer of AWS, Azure or Google Cloud, and you are the provider to the organisations that buy your product. Each relationship carries its own set of duties, and conflating them is how gaps appear.
The middle layer is the largest, and it is entirely yours. It is also the layer nobody else audits on your behalf. Your cloud provider’s ISO 27001 certificate and SOC 2 report attest to their controls over their infrastructure. They say nothing about whether your application enforces authorisation correctly, whether one tenant can reach another tenant’s data, or whether your access keys are sitting in a public repository.
This is the single most common misunderstanding in Australian SaaS security reviews. A vendor sends their cloud provider’s compliance pack in response to a security questionnaire. It answers roughly one question out of twenty, and the reviewer reads it as either confusion or evasion.
What exactly is the SaaS layer responsible for?
The middle layer covers everything you write, configure or operate. Listed plainly, it is a longer list than most teams expect.
- Application code and dependencies. Your own logic, plus every library you pull in and never update.
- Identity and tenant isolation. Authentication, roles, and the boundary that stops customer A reading customer B’s records. For multi-tenant products this is the highest-consequence control you own.
- Cloud configuration. Storage bucket permissions, security groups, network boundaries, public endpoints. Misconfiguration, not provider failure, causes most cloud data exposure.
- Secrets and encryption keys. Where keys live, who can use them, and how they rotate. Provider key management makes this easier, not automatic.
- Logging and monitoring. What you record, how long you keep it, and whether anyone is alerted. Cloud providers supply the tooling and leave the decisions to you.
- Backups and recovery. Provider durability is not a backup. A deletion replicates perfectly across three availability zones.
- Your own sub-processors. Every service you embed becomes part of what your customer is trusting.
Testing that layer is a separate exercise from securing it. Cloud penetration testing in Australia covers what a test of your environment examines, and mobile app penetration testing for SaaS teams covers the client side.
What does a customer actually ask you to prove?
An Australian enterprise security review does not ask you to recite the shared responsibility model. It asks a short list of questions, and your answers to a few of them decide whether the deal proceeds.
Notice that the cloud provider layer carries the least weight. Naming your provider and your region takes one line, and reviewers move on. The questions that stall deals are all about the middle layer: tenant isolation, current testing, monitoring and where data goes. How to vet a supplier’s SOC 2 report shows the same review from the buyer’s side of the table, which is a useful way to anticipate the questions.
How does data location fit into the shared responsibility model?
Data location is a responsibility that looks like it belongs to your cloud provider and does not. The provider offers Australian regions. Choosing one, keeping data in it, and knowing where every sub-processor sits are all yours.
For Australian buyers this matters more than it does in most markets. Government and government-adjacent customers frequently require onshore hosting outright. Commercial buyers increasingly ask, and under the Notifiable Data Breach scheme you carry obligations for personal information regardless of which supplier’s infrastructure it was sitting on when it was exposed.
The answer a reviewer wants is specific: the region, confirmation that backups and logs stay in it, and a current list of sub-processors with their locations. Data sovereignty for Australian SaaS covers the detail, and IRAP versus ISO 27001 covers what changes when you sell to government.
How does shared responsibility affect SOC 2 and ISO 27001 scope?
Both frameworks let you rely on your cloud provider for the layer they control, provided you can show you manage that reliance. You do not re-audit AWS. You do have to demonstrate that you assessed them, that you monitor their reports, and that you have identified which of your own controls depend on theirs.
| Layer | Who it belongs to | What your auditor expects from you |
|---|---|---|
| Data centre and hardware | Cloud provider | Evidence you obtained and reviewed their current report |
| Host and hypervisor patching | Cloud provider | Confirmation of which services are managed, and which are not |
| Operating system on your instances | You | Your patching process and records, if you run instances |
| Application and tenant isolation | You | Design evidence, access control testing, penetration test results |
| Cloud configuration | You | Configuration standards and how drift is detected |
| Customer user administration | Your customer | Clear documentation telling them it is theirs |
The bottom row is the one SaaS vendors forget. In SOC 2 these are described as complementary user entity controls: the things your customers must do for your controls to work. If your system description does not state them, your auditor will ask, and a buyer who assumes you handle something you do not has a gap neither of you is watching. SOC 2 for Australian SaaS companies covers scoping this properly.
Common questions about the SaaS shared responsibility model
What is the AWS shared responsibility model?
AWS divides security into security of the cloud and security in the cloud. AWS is responsible for the hardware, the physical facilities, the network infrastructure and the virtualisation layer. You are responsible for your operating systems where applicable, your application, your data, your identity and access management, your encryption choices and your configuration of every AWS service you use.
Which responsibilities does the cloud provider have?
Physical security of data centres, hardware maintenance and disposal, the host operating system and hypervisor, the underlying network, and the availability of the regions and zones you pay for. For managed services they extend to the service engine and its patching. They never extend to how you configure the service, who you give access to, or what you put in it.
Does the shared responsibility model work the same way on Azure?
The principle is identical and the boundaries shift slightly by service. Azure publishes its split across infrastructure, platform and software services, with responsibility moving toward Microsoft as you move up the stack. Information and data, devices, and accounts and identities remain the customer’s responsibility in every Azure service model, which mirrors AWS and Google Cloud.
Who is responsible for patching in the shared responsibility model?
It depends on the service. On virtual machines, guest operating system and application patching is yours. On managed databases and serverless platforms, the provider patches the engine and the runtime while you remain responsible for your own code and its dependencies. Dependency patching is always yours, and it is the one most often missed because it feels like somebody else’s infrastructure.
Does a cloud provider’s SOC 2 report cover our SaaS product?
No. It covers their controls over their infrastructure during a defined period. It is useful evidence for your supplier assessment and your auditor will want to see you have reviewed it. It says nothing about your application, your tenant model or your configuration, and sending it in answer to a question about your product will usually slow a security review rather than speed it up.
Getting your layer in order
The practical test of whether you understand the shared responsibility model is whether you can answer one question without hedging: if a customer’s data were exposed tomorrow, which layer would it have come from? For almost every SaaS incident on record, the answer is the middle one. Configuration, access control and application logic, not the data centre.
Write your layer down. List what you own, what evidence you hold for each item, and what you tell customers is theirs. That document answers most of a security questionnaire, forms the backbone of a SOC 2 system description, and shows you where your own gaps are before a buyer finds them.
Siege Cyber helps Australian SaaS businesses work out exactly where their responsibility starts and prove they are meeting it. See our virtual CISO services or get in touch to talk it through.