Under the cloud shared responsibility model, the provider secures the underlying infrastructure — physical facilities, hardware, hypervisor and managed service platform — while the customer remains responsible for data, identity and access, configuration, and in most models the operating system and applications. The division shifts between IaaS, PaaS and SaaS, and misreading it is the most common root cause of cloud data exposure.
Key Takeaways
- Data, identity and configuration are always the customer responsibility, in every model.
- The provider is responsible for security OF the cloud; you are responsible for security IN it.
- SaaS shifts the most to the provider, but never your data classification, access control or sharing settings.
- Backup is frequently assumed to be the provider’s job and frequently is not.
- Regulatory accountability under UAE law stays with you regardless of the model.
Where the line sits by service model
IaaS — virtual machines, storage, networking. The provider secures the physical data centre, hardware and hypervisor. You own everything above that: operating system patching, host hardening, network configuration, identity, applications and data. This is the model where customer responsibility is largest and most often underestimated.
PaaS — managed databases, app services, serverless. The provider additionally handles the operating system and runtime patching. You own application code and configuration, access control, data and the service’s own security settings, which are frequently left at defaults.
SaaS — Microsoft 365, Salesforce and similar. The provider runs almost the entire stack. You still own user identity and access, data classification, sharing and retention configuration, and the security settings the product exposes. See our Microsoft 365 hardening checklist — every item there is customer responsibility, not Microsoft’s.
What is always yours
Across every model, four things never transfer:
- Data. What you store, how it is classified, who can reach it, how long it is kept, and where it resides.
- Identity and access. Accounts, roles, permissions, MFA and privileged access. No provider will fix an over-permissive role for you.
- Configuration. Security settings on the services you consume. Providers supply the capability; enabling and tuning it is yours.
- Regulatory accountability. Under UAE PDPL and sector rules such as ADHICS or CBUAE expectations, the obligation sits with you as controller. A provider contract does not transfer it.
That last point is worth stating plainly because it surfaces repeatedly in incidents: outsourcing the infrastructure does not outsource the accountability.
The assumptions that cause incidents
- “The cloud is backed up.” Provider resilience protects against infrastructure failure, not against you deleting data, ransomware encrypting it, or a malicious insider. SaaS retention windows are short and are not a backup strategy. Verify what you actually have before you need it.
- “The provider patches everything.” True in SaaS, partly true in PaaS, and false in IaaS, where OS and application patching is entirely yours.
- “Managed services are secure by default.” A managed database can still be deployed with public access and weak authentication. Defaults favour ease of deployment.
- “The provider monitors for attacks on our data.” They monitor their platform. Detecting malicious activity in your tenant — unusual access, privilege escalation, data exfiltration — is yours, which is what managed cloud security and SIEM integration exist for.
- “Our provider is certified, so we are compliant.” Their certification covers their platform. Your configuration, data handling and access control are assessed separately.
Data residency in the UAE
Residency sits in an awkward middle ground: the provider offers regional infrastructure, but choosing and enforcing it is the customer responsibility.
- Confirm the region for every workload explicitly rather than accepting portal defaults.
- Check where backups, replicas and logs reside — these frequently default to a different region than the primary workload.
- Verify where support personnel can access data from, which is a separate question from where it is stored.
- Document the position for your PDPL records of processing and any cross-border transfer assessment.
- Re-check after architecture changes — a new replica or a disaster recovery design can quietly move data.
CSPM policy can enforce region restrictions continuously and alert on resources deployed outside approved locations — see CSPM explained.
Getting your side right
- Map the model per workload. A single organisation runs IaaS, PaaS and SaaS simultaneously with different boundaries for each.
- Document who owns what internally. “The cloud team” is not an owner for data classification or access review.
- Verify backup and recovery independently for every service holding data you cannot lose, including SaaS.
- Monitor your own tenant. Forward cloud audit logs to a SIEM and alert on privileged and anomalous activity.
- Assess providers as third parties. Their certifications, incident notification commitments and subprocessors are part of your third-party risk management.
Frequently Asked Questions
What is the cloud shared responsibility model?
A framework defining which security responsibilities belong to the cloud provider and which remain with the customer. The provider secures the underlying infrastructure — facilities, hardware, hypervisor and managed platform — while the customer secures data, identity and access, configuration, and in IaaS the operating system and applications.
Who is responsible if our cloud data is breached?
Almost always the customer, because most cloud data exposure results from customer-side misconfiguration or compromised credentials rather than provider failure. Under UAE PDPL the regulatory accountability sits with you as data controller regardless of where the data is hosted.
Does the cloud provider back up our data?
Generally not in the way organisations assume. Provider resilience protects against infrastructure failure, not against accidental deletion, ransomware or malicious insiders. SaaS platforms have short retention windows that are not a backup strategy. Verify what you actually have and test a restore.
Is SaaS more secure than IaaS?
It shifts more responsibility to the provider, which reduces the surface you must manage, but it does not eliminate customer responsibility. Identity, access, data classification, sharing configuration and retention remain yours, and SaaS misconfiguration — over-shared files, unmanaged guest access — causes real incidents.
How does this affect UAE data residency requirements?
Providers offer regional infrastructure, but selecting and enforcing the region is your responsibility. Check where backups, replicas and logs reside as well as the primary workload, since those often default elsewhere, and document the position for your PDPL records of processing.
Does a provider certification make us compliant?
No. Their certification covers their platform and their controls. Your configuration, data handling, access management and monitoring are assessed separately against your own obligations. Provider attestations are useful evidence in your third-party assessment, not a substitute for your own compliance.
Talk to a UAE Cybersecurity Team
Cybersecurity MEA helps UAE organisations map their actual cloud responsibilities and close the gaps — cloud security posture assessment, architecture review and continuous monitoring across Azure, AWS and Google Cloud. Request an assessment of where your boundary currently sits.