Security in Cloud Services: Where Your Data Physically Sits

Cloud data still lives in a building

It is easy to think of cloud data as being nowhere in particular. In reality, every file, database and backup in a cloud service sits on physical servers inside data centres, and those buildings are in specific cities, run by specific companies and subject to specific laws.

That matters for security. When you move a workload to the cloud, you hand some security controls to the provider and keep others yourself. Knowing which is which, and knowing where your data physically sits, is the starting point for any cloud security review. This guide covers the shared responsibility model, how to trace every copy of your data, how physical and logical controls differ, and the questions to ask before you sign. If your main concern is which country's laws can reach your data, read our sovereign cloud guide alongside this one.

The shared responsibility model

Every major cloud provider describes security as a shared responsibility. AWS puts it as the provider being responsible for security "of" the cloud, while the customer is responsible for security "in" the cloud. Microsoft and Google publish similar models.

The split depends on the type of service:

• Infrastructure as a service (IaaS), such as virtual machines. The provider secures the buildings, hardware, network and virtualisation layer. You are responsible for the operating system, patching, applications, firewall rules, identities and data. • Platform as a service (PaaS), such as managed databases. The provider also takes on the operating system and platform software. You still manage access, configuration and data. • Software as a service (SaaS), such as email or CRM. The provider runs almost everything. You remain responsible for who has accounts, how they sign in, what data goes in and how it is shared.

In every model, the customer stays responsible for its data, its user accounts and its access settings. Many cloud security incidents come from that customer layer: misconfigured storage, weak sign-in controls or excessive permissions, rather than a failure of the provider's building. Colocation has its own version of this split, which we cover in our physical security and compliance guide.

Where your data and its copies physically sit

Most providers let you choose a region, which is a group of data centres in one geographic area. In Australia, AWS, Microsoft Azure and Google Cloud all offer regions in Sydney and Melbourne, and Microsoft also offers Australia Central regions in Canberra. Choosing an Australian region is the first step, but a single workload usually creates more than one copy of its data.

When you map a cloud service, check where each of these sits:

• Primary storage. The region you selected, which may span several data centres (availability zones) in that area. • Replicas and disaster recovery copies. Some services replicate to a second region automatically or by default. Check whether that region is also in Australia. • Backups and snapshots. These can be configured to copy to other regions. • Logs, monitoring and telemetry. Diagnostic data may be processed in a different location from your main data. • Support access. Ask where support staff who can access your environment are based. • Sub-processors. SaaS providers often rely on other providers for hosting, email or analytics. Their sub-processor lists show who else handles your data and where.

Providers publish data residency documentation explaining which services keep data in the chosen region and which global services do not. Read it for each service you plan to use, not just for the platform as a whole.

Physical controls vs logical controls

Physical controls protect the building and hardware: perimeter security, access cards, biometrics, CCTV, locked racks, secure disposal of drives, fire suppression and power resilience. Logical controls protect the systems and data: identity and access management, multi-factor authentication, encryption, network segmentation, logging and patching.

In colocation, you can see and inspect many physical controls yourself, because your equipment sits in a cage or rack you can visit. In the cloud, you generally cannot tour the facility. Instead, you rely on independent assurance. AWS publishes its audit reports through AWS Artifact and Microsoft through its Service Trust Portal, and providers commonly hold ISO 27001 certification and SOC 2 reports. For Australian government workloads, IRAP assessments and the Hosting Certification Framework are the key frameworks, explained in our government data centre requirements guide.

Your strongest lever in the cloud is the logical layer. Encryption with keys you control, strict access policies and good logging reduce your reliance on any one building's physical security.

Data localisation obligations in Australia

Most Australian businesses have no general legal requirement to keep data onshore, but some rules affect where data can go:

• The Privacy Act 1988. Australian Privacy Principle 8 covers disclosing personal information to overseas recipients, and APP 11 requires reasonable steps to protect personal information. The Notifiable Data Breaches scheme applies when a breach is likely to cause serious harm. • My Health Record. The My Health Records Act 2012 restricts holding My Health Record system records outside Australia. • APRA-regulated entities. Banks, insurers and superannuation funds must meet prudential standard CPS 234 on information security and CPS 230 on operational risk, which took effect on 1 July 2025 and covers material service providers, including cloud providers. • Government. Australian Government agencies follow the Protective Security Policy Framework and the Hosting Certification Framework.

Contracts can also set residency requirements, so check your customer agreements. This is general information, not legal advice. Confirm your obligations with your legal or compliance team.

Due-diligence questions for cloud buyers

• Which region or regions will our data be stored and processed in, including replicas, backups and logs? • Which services in our design keep data in the chosen region, and which do not? • Who are your sub-processors, and where are they located? • Where are support and operations staff based, and how is their access to our environment approved and logged? • Which independent reports cover the specific services and region we will use, and can we see them? • Can we hold our own encryption keys, and where is the key management service located? • How and when will you notify us of a security incident affecting our data? • How do we get our data back, and how is it deleted when we leave?

Many businesses end up with a hybrid design: sensitive systems in an Australian colocation facility and other workloads in the cloud, joined by private connections. Our cloud on-ramps guide explains how that works, and our Sydney, Melbourne and Canberra pages show local options. You can compare operators such as NEXTDC, Equinix and CDC in the provider directory, and use DChunt's free assessment to match your security and compliance needs to the right mix of facilities. DChunt is independent and does not resell data centre space or cloud services.