A question I hear regularly from executives and board members: if our records sit in a Microsoft or Amazon data centre, doesn’t that mean they have our data?

It’s a fair instinct. Two decades of free consumer tech trained us to treat “in the cloud” as shorthand for “in someone else’s hands.” With consumer apps like Gmail or Instagram, that instinct is spot on: the provider holds the keys, scans the content, and monetizes what you upload.

Enterprise cloud infrastructure — AWS, Azure, Google Cloud — works on a fundamentally different model.

The building and the safe

Think of an enterprise cloud provider as a commercial landlord. The landlord owns the concrete, the perimeter fencing, the backup generators, the plumbing, and the cameras in the lobby. You are the tenant. You decide what comes through the suite door, who gets a keycard, and what gets locked inside the wall safe.

If you stop paying rent, the landlord can lock your suite. If served with a warrant, the landlord has to let law enforcement into the building. What the landlord cannot do in the normal course of business is open your safe — because you hold the combination, and the building is engineered so that any attempt by building staff to touch your lock triggers an indelible alarm.

Why the landlord doesn’t want your combination

That restraint isn’t charity; it’s self-preservation.

The trillion-dollar cloud business only works because banks, hospitals, defence ministries, and regulators trust it with their crown jewels. A single confirmed case of a cloud provider snooping through an enterprise customer’s database wouldn’t just cause a bad press cycle — it would trigger an existential exodus of every regulated customer they have.

To protect their own business model, cloud providers spend billions engineering systems that lock their own employees out of customer data — and prove to auditors that they stayed out. That means hardware security modules (HSMs), customer-controlled encryption keys, zero-standing-privilege administration, tamper-evident audit logs, and continuous third-party audits (SOC 2, ISO 27001, Protected B).

You don’t have to trust the landlord’s benevolence. Their commercial survival depends on being provably unable to read your files — and aligned incentives beat good intentions every time.

Five levels of lock and key

How much the landlord can see isn’t decided by the cloud provider — it’s decided by how you configure your tenancy. In practice, there are five tiers:

  1. Default encryption. Your data is encrypted on disk, but the provider manages the keys. Contractually, they promise not to look. Technically, if served with a court order, they have the means to decrypt it.
  2. Audited provider keys. The provider still manages the keys, but every key event is written to an immutable log you control. They can still be compelled, but they cannot do it in the dark.
  3. Customer-managed keys (KMS/HSM). You generate and control the keys inside a dedicated hardware module. Revoke access, and all the provider has left on disk is mathematical noise.
  4. External key management (Hold Your Own Key). Your keys never touch the cloud provider’s infrastructure; they live on your own hardware or with an independent custodian. For every decryption request, the cloud has to ask your key server for permission — and you can pull the plug at any time.
  5. Confidential computing. Data stays encrypted not only on disk and across the network, but inside RAM while the CPU is actively processing it, using hardware-isolated enclaves the host operating system cannot inspect. It is live today across AWS, Azure, and GCP, and remarkably underused.

Most organizations sit at Level 1 or 2 simply because they accepted the defaults during setup. Moving to Level 3 adds pennies in cost and minimal operational friction, while Levels 4 and 5 are ready whenever regulatory or sovereignty stakes demand them. Where you sit on that ladder is entirely your call.

What you should actually worry about

When boards worry that “Amazon is reading our files,” they are usually staring at the wrong threat. In real-world incidents, cloud exposures almost always come from four places:

  • Tenant misconfiguration. The number-one cause of cloud breaches isn’t a broken cipher — it’s an engineer setting a storage bucket to “public” on a Friday afternoon to unblock a deployment. The landlord’s building is secure; the tenant left the apartment door propped open.
  • Identity and access sprawl. Former contractors with active admin tokens, over-permissioned service accounts, or API keys pasted into internal wikis.
  • Cross-border lawful access. If your provider is subject to foreign statutes like the US CLOUD Act, a promise that “the vendor won’t snoop” won’t stop a lawful subpoena — unless your architecture pairs domestic regions with keys the vendor doesn’t control.
  • Outages and lock-in. For most enterprises, a region going dark or a contract becoming impossible to exit is a far more immediate risk than espionage.

A better question for the boardroom

Instead of asking “Does the cloud provider have our data?”, leaders should ask their teams a sharper question: “Have we architected our cloud environment so that even the provider couldn’t read our data if compelled — and can we prove it?”

The cloud is tenancy, not custody. The safe is in your apartment, and the keys are yours to keep — you just have to remember to take them.