Privacy in Cloud Services: Eight Facts Buyers Should Demand From Vendors

Most "cloud privacy" articles treat the subject as a technology question — encryption algorithms, key management, zero-knowledge architectures. Those things matter, but they are downstream of a more important question: what does your contract actually let the provider do with your data? The technology is only as strong as the legal boundary around it, and in our experience most cloud buyers sign contracts without reading the data-handling clauses closely enough to know what they just agreed to.

Here are eight facts we insist on getting in writing before we recommend a cloud provider to a customer. They are not technical specs. They are the things that determine whether your privacy posture is real or performative.

Fact One: Where The Data Physically Lives

This sounds obvious. It is not. Hyperscalers have regions that map roughly to geography, but "region" is not the same as "physical location" and "physical location" is not the same as "jurisdiction." A European region may replicate metadata to the US. A US region may be operated from an overseas support center. A "sovereign" region may still route authentication requests through infrastructure in another country.

Ask for a written statement of exactly which data is physically stored where, including backups, metadata, telemetry, and support tickets. If the vendor will not put it in writing, assume the answer is "somewhere other than where you expected."

Fact Two: Who Can Access The Data Without Telling You

Every cloud provider has employees with some level of access to customer data. The question is who, when, and under what controls. Mature providers have break-glass procedures — access requires approval from multiple people, is logged immutably, and is reported to the customer after the fact. Less mature providers have support engineers who can read customer databases with no approval workflow and no customer notification.

Ask for the written access-control policy. Ask whether customer notification is required for provider access, and under what circumstances. Ask how long the access logs are retained. "Our employees are trained in privacy" is not an answer.

Fact Three: What Happens When A Government Asks For Your Data

This is the fact that most buyers never ask about and that matters more than almost any other. If your cloud provider receives a subpoena, a national security letter, or a law enforcement request for your data, what happens? Do they notify you? Do they challenge the request? Do they comply silently? Does the answer depend on the jurisdiction of the requesting authority, the jurisdiction of the data, or the jurisdiction of the provider?

The US CLOUD Act, the EU GDPR, and various sovereign-data regulations collide in interesting ways here. A US-headquartered provider with data in a European region may still be compelled to hand over that data to US authorities without notifying you or the European data subjects. That is not a hypothetical scenario — it is the legal framework.

Ask for a transparency report. Ask for the government-request policy in writing. Ask whether the provider notifies customers of requests and under what exceptions.

Fact Four: What Happens To Your Data When You Leave

Contract termination is when privacy commitments get tested. Does the provider delete your data when you cancel? Within what timeframe? Does "delete" mean actually erased from disks, or marked for deletion and eventually garbage-collected? What about backups — are those deleted on the same timeline or do they persist for months after cancellation? What about logs and telemetry collected from your usage?

Mature providers have a documented data-deletion procedure with specific timelines. Less mature providers have a policy that amounts to "we'll get to it eventually." Ask for the procedure in writing, with timelines, and verify that it includes backups and derived data.

Fact Five: Whether Your Data Is Used To Train Models

This is the new question of the AI era and it deserves specific attention. If you use a cloud provider's AI services — whether a hosted language model, a vision API, or a translation service — is your input used to train future models? What about your stored data, if the provider offers AI features that can read it? Are there opt-out mechanisms, and are they on by default or off by default?

The answer varies by provider and by service tier. Some providers explicitly commit to not training on customer data in enterprise tiers. Others reserve the right, with opt-out buried in configuration. Get the answer in writing, for the specific services you are using, and revisit it whenever you adopt a new service.

Fact Six: What Encryption Actually Protects

"Data is encrypted at rest and in transit" is a statement that technically sounds reassuring and practically means very little. The relevant questions are: who holds the keys, when is the data decrypted, and who has access at that moment. A provider that holds the keys can decrypt your data whenever they want — the encryption protects you from a stolen disk, not from the provider itself. A bring-your-own-key arrangement changes who can read the data but usually does not prevent the provider from reading it when your application is accessing it.

True zero-knowledge architectures exist but are rare in enterprise cloud services. Most "encryption at rest" is protection against physical theft and compliance check-box filling, not protection against the provider. Know which category your encryption actually belongs to.

Fact Seven: What Gets Logged And How Long It's Kept

Every cloud service generates logs about how you use it. Those logs are privacy-relevant metadata even when they do not contain your actual data. They reveal usage patterns, access times, query volumes, error rates, and often IP addresses and user identifiers. The provider may retain those logs for months or years for their own operational purposes, and they are subject to the same government-access and employee-access questions as your primary data.

Ask what is logged, how long it is retained, who has access to it, and whether it is included in deletion procedures when you cancel.

Fact Eight: What Happens If The Provider Has A Breach

Every provider will eventually have a security incident. The questions are how quickly they will tell you, how much detail they will share, whether they will pay for your notification costs and credit monitoring, and whether the contract gives you any meaningful remedies. Most standard cloud contracts cap liability at the fees paid over the last twelve months, which is usually orders of magnitude less than the actual cost of a breach.

Ask about the incident-notification timeline. Ask about the breach-cost allocation. Ask whether there is a notification obligation for incidents that affect the provider's infrastructure but not your specific data — you may care about incidents where the provider thinks you were not directly affected.

The Contract Is The Privacy Posture

The point of all eight facts is that cloud privacy is primarily a contract problem. Encryption, zero-trust networking, and key management are tools that help enforce the contract, but the contract itself is what defines what privacy you actually have. Buyers who treat privacy as a technology checklist end up protected against the wrong threats.

Before signing any cloud contract, ask for the data processing agreement (DPA), read it carefully, and do not accept answers that consist of whitepapers or blog posts. Get the commitments in the contract itself. A vendor who will not commit in writing is a vendor whose privacy posture you cannot rely on, regardless of how many certification badges appear on their website.

Three Takeaways

1. Privacy is a contract, not a certification. Certifications are necessary but not sufficient. Read the DPA.
2. The hardest questions are about jurisdictions and access. Where the data physically sits, who can compel access, and what notification obligations exist matter more than encryption algorithms.
3. AI training clauses are the new footnote to read carefully. If you have not checked whether your provider is training on your data, you do not know whether they are.