A question I’ve gotten more than once: if our data sits in Microsoft’s data centre, doesn’t Microsoft have our data?

The instinct is reasonable. We’ve been trained for two decades to treat “on the cloud” as a synonym for “in someone else’s hands.” For free consumer services — Gmail, Instagram, YouTube — the instinct is close to right. The provider is the operator, has the keys, and is monetizing what you put there.

For the major enterprise clouds — AWS, Azure, Google Cloud — the picture is different in ways that matter. Not perfect, just different.

The building and what’s in it

The cleanest way to think about it: the cloud provider is a landlord. They own the building, the locks on the outside doors, the power, the plumbing, the security cameras in the lobby. You are the tenant. You decide what goes in the apartment, who has keys to it, and what’s in the safe.

The landlord can evict you (subject to contract). The landlord can be served with a court order to give the authorities access to the building. The landlord cannot, in the normal course of business, open your safe — because they don’t have the combination, and they’ve built the building so that opening it without you noticing is a fireable offence at every level of the org chart.

That last sentence is doing a lot of work. Let's unpack it.

Why the landlord doesn’t actually want your data

The cloud provider business model only functions if regulated industries — banks, hospitals, governments, defence contractors — trust them with workloads that come with serious consequences if mishandled. A single credible incident of a cloud provider reading customer data without authorization would destroy that trust. We’re not talking about a bad quarter. We’re talking about losing every healthcare customer, every government customer, every financial customer, very quickly.

So the providers have built layers of mechanism specifically to make it hard for themselves to access your data — and easy to prove they didn’t. Background-checked staff. Hardware-isolated key storage. Encryption that uses keys you control, not keys they hold. Tamper-evident audit logs for every administrative action. Independent attestations (SOC 2, ISO 27001, IRAP — the alphabet keeps going).

This isn’t virtue. It’s a simple case of incentive alignment. The provider’s commercial survival depends on not being able to read your data. That’s a stronger guarantee than virtue.

The ladder of who can see what

Where exactly your data sits depends on choices you make as a tenant, not the provider. There’s a rough ladder:

  1. Default storage. Data is encrypted at rest, but the provider holds the keys. They contractually won’t access it. Technically, they could be compelled to.
  2. Provider-managed keys with audit. Same as above, but every administrative key access is logged and visible to you. Compulsion still possible; invisibility no longer.
  3. Customer-managed keys. You generate and hold the encryption keys in a hardware security module. The provider stores ciphertext. Without your key, they have noise.
  4. External key management. Your keys live outside the provider entirely — on your own hardware or a third-party service. The provider has to ask you to decrypt anything. You can say no, or just not be reachable.
  5. Confidential computing. Data is encrypted not just at rest and in transit, but while being processed in memory, inside a hardware-isolated enclave the provider can’t peer into. This is real, available now on all three majors, and underused.

Most enterprise workloads sit at level 1 or 2 by default. Level 3 is a configuration choice that costs you nothing in functionality and a small amount in operational complexity. Levels 4 and 5 are real options for workloads where the stakes justify the friction.

The point is: where your data sits on this ladder is your call, not the provider’s. The provider will sell you the service at any level. Most organizations are at level 1 because nobody asked the question — not because they chose to be.

What you should actually worry about

The thing executives worry about — “Microsoft is reading our data” — is, for any serious enterprise deployment, not the live risk. The live risks are different:

  • Misconfiguration on your side. The single largest cause of cloud data exposure isn’t the provider. It’s a storage bucket that someone set to “public” because it was faster than configuring access properly. The provider’s controls are strong; the defaults you apply on top of them are where data leaks happen.
  • Identity and access sprawl. Hundreds of contractors with standing access to production. Service accounts with passwords in a wiki. The provider is doing their job; the tenant isn’t doing theirs.
  • Lawful access by governments. A real concern, especially across borders. If your data sits on infrastructure subject to a foreign government’s compelled-access regime, “the provider won’t read it” doesn’t help much if their government can. This is solvable — sovereign regions, customer-held keys, jurisdiction-aware architecture — but it has to be designed in, not assumed.
  • The provider going down. Resilience and lock-in are bigger day-to-day concerns than confidentiality for most organizations.

None of these is “the cloud provider is rifling through your files.” That’s almost never the threat.

The reframing

The honest version of the executive question isn’t “does the provider have our data?” It’s “have we configured the system so that even the provider can’t usefully access our data, and can we prove it?” For both, the answer can be yes. For most organizations today, the answer is closer to “we haven’t checked.”

The cloud isn’t custody. It’s tenancy. The keys to the safe are still yours to hold, if you ask for them.