The shared responsibility model assigns “security of the cloud” to your provider and “security in the cloud” to you. That split is not negotiable, and it does not disappear because you signed a managed service agreement. What changes is the exact boundary, and that boundary shifts depending on whether you are running IaaS, PaaS, or SaaS.
- IaaS (e.g. AWS EC2, Azure Virtual Machines): the provider secures physical infrastructure, networking, and the hypervisor. You own the guest OS, applications, data, and identity.
- PaaS (e.g. Azure App Service, Google Cloud Run): the provider also manages the runtime and OS. You own your application code, data, and access controls.
- SaaS (e.g. Microsoft 365, Google Workspace): the provider manages almost everything. You still own your data, user identities, and access permissions — always.
Your immediate next steps as an Australian SME: check your SLA for data residency clauses, confirm who configures IAM and holds encryption keys, and verify your backup and logging settings are actually enabled. The Australian Cyber Security Centre (ACSC) publishes specific guidance on this model and maps it to your breach reporting obligations under the Notifiable Data Breaches scheme.
Table of Contents
- What is the shared responsibility model and why does it matter in Australia?
- What cloud providers are responsible for securing
- What you must secure: customer responsibilities and practical steps for SMEs
- How do you tell the difference between shared, inherited, and customer-only controls?
- How does responsibility change across IaaS, PaaS, SaaS, and serverless?
- How does the SRM shift when you use cloud AI and managed ML services?
- Practical application for Australian SMEs: checklist, SLA clauses, Essential Eight mapping, and two scenarios
- Key takeaways
- Why most Australian SMEs are looking at this the wrong way
- Stanfieldit can help you map and manage your cloud responsibilities
What is the shared responsibility model and why does it matter in Australia?
The shared responsibility model (SRM) is the formal framework that defines which security controls a cloud service provider (CSP) owns and which controls you, the customer, must implement yourself. The clearest way to think about it: if you can configure it, you own it. AWS introduced this framing, and Microsoft Azure uses the same conceptual split across their documentation.
The practical implication is significant. Many Australian businesses move workloads to the cloud assuming the provider handles security end-to-end. That assumption is wrong, and it creates real exposure. Misconfiguration of customer-controlled resources — a public storage bucket, an overprivileged service account, an unpatched virtual machine — sits entirely within the customer’s responsibility zone.
Why this matters for compliance in Australia. The Privacy Act 1988 and the Notifiable Data Breaches (NDB) scheme do not care where your data physically lives. If personal information is exposed because you failed to configure access controls on a cloud storage service, your organisation is the notifiable entity, not the CSP. That obligation sits with you regardless of your provider’s own security certifications.
The SRM also shapes procurement decisions. Before you sign a cloud contract, the responsibility matrix and SLA clauses should be reviewed as pre-contract items, not afterthoughts. A well-documented SLA is the primary mechanism for translating a generic SRM statement into a contract-level obligation you can actually enforce during an incident.
What cloud providers are responsible for securing
Providers secure the infrastructure layers that customers cannot directly access or configure. AWS defines this as “security of the cloud” — the physical and logical foundation your workloads run on.
Provider-owned layers typically include:
- Physical datacentres: building security, power, cooling, and physical access controls
- Physical networking: the hardware and cabling between datacentre facilities
- Host infrastructure: the physical servers and storage arrays
- Hypervisor and virtualisation layer: the software that isolates your virtual machines from each other and from the underlying hardware
- Core managed platform services: the control plane for services like managed databases, object storage, and serverless compute
- Baseline platform logging and audit capabilities: the underlying infrastructure to generate logs, even if you must enable them
Providers surface evidence of these controls through SOC 2 Type II and ISO 27001 attestations, service-specific compliance documentation, and shared control documentation available in their compliance portals. During procurement, request these artefacts directly. If a vendor cannot produce a current SOC report or a clear responsibility matrix, that is a red flag worth addressing before you sign.
The UK NCSC recommends delegating as much responsibility as possible to hyperscale providers where appropriate, because large CSPs can manage complex platform security updates more effectively than most organisations can in-house. That is sound advice, but it requires contractual clarity about exactly what the provider is managing on your behalf.
What you must secure: customer responsibilities and practical steps for SMEs
Customer responsibilities cover everything you can touch, configure, or access. Microsoft’s responsibility matrix makes this explicit: data, configurations, identities, and — depending on the service model — the guest OS and application layer always remain with the customer.
The core areas you own:
- Data classification and protection: you decide what data goes to the cloud, how it is classified, and what encryption applies
- Identity and access management (IAM): user accounts, service accounts, roles, and permissions are your configuration
- Guest OS and application patching: on IaaS workloads, the provider patches the hypervisor; you patch the OS and everything above it
- Network security rules: security groups, firewall rules, and virtual network configurations are customer-managed
- Encryption key ownership: even when a provider offers encryption at rest, you should manage your own keys using a customer-managed key (CMK) service
- Backup and disaster recovery verification: a backup that has never been tested is not a backup
For Australian SMEs, the most common gaps are IAM hygiene and storage configuration. Default public access on object storage (S3 buckets, Azure Blob containers) has been the root cause of numerous data exposures. Check every storage resource for public access settings as a first-order priority.
Pro Tip: Run a monthly IAM review using your provider’s access analyser tool (AWS IAM Access Analyzer or Microsoft Entra ID Access Reviews) to catch overprivileged accounts before they become a breach.
Under the NDB scheme, if a misconfiguration in your customer-controlled layer exposes personal information, you are required to notify both the Office of the Australian Information Commissioner (OAIC) and affected individuals. The Privacy Act 1988 obligation does not transfer to your CSP. Practical cyber security steps for small businesses should include this notification workflow as a documented procedure.
How do you tell the difference between shared, inherited, and customer-only controls?
Not every control falls cleanly into “provider” or “customer.” The AWS Well-Architected Framework identifies a third category: shared controls, where the provider defines requirements or supplies the platform capability, but you must implement and verify the control within your own environment.
Three categories with examples:
| Control category | Who acts | Example |
|---|---|---|
| Provider-only | CSP manages entirely | Hypervisor patching, physical access, baseline DDoS protection |
| Shared / inherited | CSP provides capability; customer enables and configures | Encryption at rest (provider supplies the mechanism; you manage keys or enable CMK), platform logging (provider generates logs; you must enable retention and alerting) |
| Customer-only | Customer manages entirely | IAM policies, guest OS patching, application code, data classification, backup schedules |
The practical decision rule is three questions: Who operates it? Who configures it? Who can access the keys or data? If the answer to any of those is “you,” the control is at least partly yours.
Patch management is a useful illustration. On a managed database service (PaaS), the provider patches the database engine. On a self-managed VM running the same database (IaaS), you patch both the OS and the database engine. The workload looks similar; the responsibility split is entirely different.
Google Cloud’s “shared fate” model takes this further, supplying opinionated secure landing zones and infrastructure-as-code templates to reduce the chance of misconfiguration in the shared zone. It is a useful evolution of the standard SRM framing, particularly for teams without dedicated security architects.
How does responsibility change across IaaS, PaaS, SaaS, and serverless?
Responsibility increases for the customer as you move from SaaS toward IaaS. The table below maps the standard layers across service models.
| Layer | IaaS | PaaS | SaaS | Serverless / managed |
|---|---|---|---|---|
| Physical datacentre | Provider | Provider | Provider | Provider |
| Physical network | Provider | Provider | Provider | Provider |
| Hypervisor / virtualisation | Provider | Provider | Provider | Provider |
| Guest OS | Customer | Provider | Provider | Provider |
| Runtime / middleware | Customer | Provider | Provider | Provider |
| Application code | Customer | Customer | Provider | Customer |
| Data | Customer | Customer | Customer | Customer |
| Identity and access | Customer | Customer | Customer | Customer |
| Network configuration | Customer | Shared | Provider | Shared |
Three quick examples:
A VM-hosted SQL Server on Azure (IaaS) means you patch Windows Server, patch SQL Server, configure the firewall, and manage backups. Azure secures the physical host and hypervisor.
A managed Azure SQL Database (PaaS) removes OS and database engine patching from your list. You still configure firewall rules, manage authentication, and own the data.
Microsoft 365 (SaaS) means Microsoft manages the application, infrastructure, and availability. You configure user accounts, set conditional access policies, manage data retention labels, and own every file your users create.
Serverless functions (e.g. AWS Lambda) sit between PaaS and IaaS: the provider manages the execution environment, but your function code, the data it processes, and the IAM permissions it runs under are entirely your responsibility.
Use this table during architecture reviews. When a team proposes a new cloud service, map each layer to an owner before the service goes live, not after.
How does the SRM shift when you use cloud AI and managed ML services?
AI workloads introduce a responsibility split that many Australian SMEs have not yet mapped. The model hosting infrastructure is provider-managed, but the data you feed into it, the prompts you construct, and the outputs you act on are your governance obligations.
Microsoft’s AI shared responsibility guidance is direct: customers must protect sensitive input data, manage prompt security, and mitigate prompt-injection risks. The provider secures the model hosting environment and applies platform-level safeguards, but has no visibility into what you send as input or how you use the output.
Practical steps for Australian SMEs using cloud AI services:
- Minimise sensitive data in prompts: never send unredacted personal information, financial records, or health data to a third-party AI API unless you have a data processing agreement and confirmed data residency
- Implement strict API access controls: treat AI API keys like privileged credentials — rotate them, store them in a secrets manager, and audit usage logs
- Test for prompt injection: if your application passes user-supplied text to an AI model, validate and sanitise inputs before they reach the API
- Govern outputs: AI outputs that contain or reconstruct personal information can trigger NDB obligations — log what goes in and what comes out
- Review your AI provider’s data handling terms: confirm whether your inputs are used for model training and whether data leaves Australian jurisdiction
For broader context on AI governance in Australian SMEs, the AI automation Australia guide covers implementation considerations and governance frameworks relevant to this space. Partner resources on AI security best practices are also worth reviewing when evaluating SaaS AI integrations.
Practical application for Australian SMEs: checklist, SLA clauses, Essential Eight mapping, and two scenarios
Cloud onboarding checklist
- Document a responsibility matrix for each cloud service before go-live — map every layer to provider, shared, or customer
- Establish an IAM baseline: enforce MFA for all accounts, apply least-privilege roles, disable unused accounts within 24 hours of staff departure
- Confirm encryption and key ownership: enable encryption at rest and in transit; use customer-managed keys for sensitive data workloads
- Enable logging and monitoring: turn on cloud-native audit logs (AWS CloudTrail, Microsoft Defender for Cloud, Google Cloud Audit Logs) and set retention to meet your compliance requirements
- Verify backup and recovery: test restoration quarterly; document your recovery time objective (RTO) and recovery point objective (RPO) against your disaster recovery plan
- Define incident response roles: document who contacts the CSP, who notifies the OAIC, and who communicates with affected individuals in a breach scenario
SLA and contract clauses to check
- Uptime vs security responsibilities: confirm the SLA covers availability but does not imply security of your data or configurations
- Incident notification timelines: the NDB scheme requires notification to the OAIC “as soon as practicable” — your CSP’s contractual notification window must support that
- Compliance evidence: request current SOC 2 Type II reports and ISO 27001 certificates before signing
- Data residency and jurisdiction: confirm data is stored in Australian regions (or acceptable jurisdictions) and that the contract reflects this
- Indemnity for misconfiguration: understand whether the contract limits provider liability for breaches caused by customer misconfiguration — most do
Essential Eight mapping
The Australian Cyber Security Centre’s Essential Eight controls map directly onto the customer responsibility zone:
- Patch applications and OS: entirely customer-owned on IaaS; partially shared on PaaS
- Multi-factor authentication: customer-configured in IAM, regardless of service model
- Restrict administrative privileges: customer-managed IAM policy
- Application control: customer responsibility on IaaS and PaaS workloads
- Backups: customer-owned configuration and verification, even when using provider backup services
Two short scenarios
Scenario 1 — Public storage misconfiguration. A healthcare practice using AWS S3 to store patient records leaves a bucket with public read access enabled. AWS’s infrastructure is secure; the misconfiguration is in the customer’s configuration layer. The practice is responsible for the exposure, must notify the OAIC under the NDB scheme, and cannot claim the breach against AWS’s SLA. The contractual trigger is the customer’s own incident response plan, not the provider’s.
Scenario 2 — Managed database vulnerability. A managed Azure SQL Database has a known vulnerability in the database engine. Microsoft patches the engine as part of their PaaS responsibility. The customer does not need to act on the engine patch. However, if the customer’s application code passes unsanitised input to the database (SQL injection), that is a customer-layer vulnerability. The provider’s patch does not protect against it.
For managed services support during cloud onboarding, Stanfieldit’s cloud migration services team can help you map responsibilities before you go live.
Key takeaways
The shared responsibility model means your cloud provider secures the infrastructure, but you always own your data, identities, and configurations — regardless of service model or managed service tier.
| Point | Details |
|---|---|
| Providers secure infrastructure | Physical hosts, networking, and hypervisor are provider-owned across IaaS, PaaS, and SaaS. |
| Customers always own data and identity | Data classification, IAM, and encryption key management remain your responsibility in every service model. |
| Service model shifts the boundary | Moving from IaaS to SaaS reduces your OS and runtime obligations, but never removes data and identity duties. |
| SLA and contracts are enforceable tools | Document responsibilities in your SLA before signing; a verbal SRM understanding is not enforceable during an incident. |
| Stanfieldit supports your obligations | Stanfieldit provides cloud onboarding, Essential Eight alignment, and managed security reviews to help Australian SMEs close the customer-side responsibility gap. |
Why most Australian SMEs are looking at this the wrong way
The standard advice is to “understand the shared responsibility model” and then implement the checklist. That framing puts the cart before the horse. The real problem is not that SMEs lack awareness of the model — it is that they treat it as a one-time exercise rather than an ongoing operational discipline.
The most common gap Stanfieldit sees is not a missing firewall rule or an unpatched server. It is an IAM configuration that was correct on day one and drifted over 18 months as staff changed, projects were added, and permissions were granted without a corresponding review. The “if you can configure it, you own it” rule does not just apply at deployment. It applies every time someone adds a service account, grants a role, or spins up a new workload.
The second underappreciated issue is the SLA. Most SMEs sign cloud contracts without reading the responsibility matrix. When an incident occurs, they discover the provider’s SLA covers availability, not the security of customer-configured resources. That is not a provider failure. It is a procurement failure, and it is entirely preventable.
The practical priority order for most SMEs is: IAM first, logging second, backups third. Get those three right before you worry about anything else. If your team does not have the capacity to maintain them, that is exactly the scenario where a co-managed security arrangement with an MSP makes sense — not because the model is complex, but because it requires consistent attention that most SME IT teams cannot sustain alongside everything else they manage.
Stanfieldit can help you map and manage your cloud responsibilities
Knowing the shared responsibility model is one thing. Having the controls in place, documented, and reviewed regularly is another. Stanfieldit works with Australian SMEs to close the gap: cloud onboarding with a documented responsibility matrix, IAM baseline configuration, Essential Eight alignment, and SLA review before you sign.
If you are unsure whether your current cloud setup meets your obligations under the NDB scheme or the ACSC’s guidance, a cloud responsibility review is the right starting point. Stanfieldit’s managed IT security services team can run that review with you, identify gaps in your customer-side controls, and help you put the right documentation in place. Contact Stanfieldit to book a cloud responsibility review.
Authoritative sources and further reading
Keep these pages alongside your contract SLA when documenting responsibilities. The vendor SRM pages and your signed agreement together form your primary evidence base.
- ACSC cloud shared responsibility model guidance for SMBs — the most directly relevant Australian government guidance for this topic
- AWS shared responsibility model — AWS’s definitive statement of provider vs customer responsibilities, including service-specific matrices
- Microsoft Azure shared responsibility in the cloud — Microsoft’s responsibility matrix across IaaS, PaaS, and SaaS, including AI workload guidance
- Google Cloud shared responsibilities and shared fate — Google’s evolution of the SRM concept, including secure landing zones and opinionated controls
- NCSC cloud security: shared responsibility model — practical guidance on delegating platform security to providers where appropriate
- Vendor-specific responsibility matrices: request these directly from your CSP’s compliance or sales team during procurement — they are more granular than the public documentation and should be attached to your contract
