Cloud storage privacy policies are long documents written by lawyers for lawyers, optimized to be technically accurate rather than readable. Most people agree to them by clicking through a setup screen. This is not unreasonable — reading every terms of service in full is not a practical use of anyone’s time.
But these documents contain specific provisions that determine real and significant differences between services. Whether the provider can read your files. Whether it can train AI on your content. Whether it will hand your data to law enforcement without telling you. Whether your data is actually deleted when you leave.
You do not need to read every word. You need to know which sections to find and what the language in those sections actually means. This is a guide to doing exactly that.
Start With the Privacy Policy, Not the Terms of Service
The terms of service govern your legal relationship with the provider — payment, termination, liability limits. The privacy policy governs what happens to your data. These are separate documents, and for storage privacy questions, the privacy policy is the one that matters.
Most privacy policies link directly from the service’s settings page, footer, or from the terms of service document. Bookmarking it and searching within it is more useful than reading it top to bottom.
The document length is itself somewhat informative: shorter policies that cover everything in simple language are more interpretable than 15,000-word documents with extensive carve-outs. But length alone is not the signal — a well-written long policy can be clearer than a short one full of vague language.
Red Flag #1: “Improve Our Services” Without Definition
The phrase “to provide, improve, and develop our services” or close variants appears in nearly every cloud storage privacy policy. It sounds benign. It can mean many things.
When this phrase is the only description of how your content is used, it is ambiguous enough to cover:
- Using your content to train AI models
- Using derived data (metadata, usage patterns) for product analytics
- Using aggregate patterns from your files to build features that benefit other users
- Sharing your content with AI subprocessors for the purpose of generating new features
The red flag is not the phrase itself — some service improvement using data is genuinely necessary for any product. The red flag is when this phrase appears without any specification of what “services” means in terms of your actual files, whether it includes AI training, and who “our” covers in terms of third parties.
What to look for instead: Language that explicitly distinguishes between “operating the service” (storing and returning your files) and “improving products” (using your data for development purposes). Better policies specify what uses require what consent, and explicitly list AI training as either permitted (with or without opt-out) or prohibited.
Red Flag #2: Broad Third-Party Sharing Language
Every service that uses subprocessors — and virtually all cloud storage services do, because they rely on third-party infrastructure providers, payment processors, and software vendors — must share some data with third parties. The question is which data, under what controls, and for what purposes.
Language like “we may share your information with partners who help us provide our services” without further specification is a blanket authorization for data sharing. “Business partners” — as opposed to “service providers who process data on our behalf under our instructions” — often signals that your data can be shared with entities who use it for their own commercial purposes.
What to look for: A list of third-party categories or specific named subprocessors, with a description of what data they receive and what they can do with it. The EU’s GDPR requires this level of specificity for companies operating in Europe; privacy policies from services subject to GDPR are often more specific in this area than those from services only subject to US law.
A service that specifies “we share data with the following categories of service providers who process data on our behalf and are contractually prohibited from using it for other purposes” is meaningfully more limited than one that reserves the right to share with “business partners.”
Red Flag #3: Vague Language Around Law Enforcement Access
Every cloud storage service will comply with legally valid law enforcement requests. The relevant differences are in what law enforcement access actually looks like and what the service does to protect you in that process.
Bad language: “We may disclose your information as required by law or when we believe disclosure is necessary or appropriate.” “Necessary or appropriate” is entirely self-referential — the service is the judge of what is appropriate.
Better language: “We respond to lawful legal process, including court orders, subpoenas, and valid government requests, and we require valid legal process before disclosing content. We notify users of legal process when permitted by law.”
What to look for specifically:
- Does the service require a warrant (or equivalent) before disclosing content (as opposed to metadata)?
- Does the service notify you when it receives and complies with legal process, unless prohibited from doing so?
- Does the service publish a transparency report showing how many requests it receives and what types?
- Does the service say it will resist overbroad legal requests?
A provider that publishes regular transparency reports — showing the number of government requests received, the types of requests, and whether they were complied with — is operating with more accountability than one that does not. Google, Apple, Microsoft, and Dropbox all publish transparency reports; many smaller services do not.
Red Flag #4: The “AI Training” Section (Or Lack of One)
The most consequential new category of privacy policy language in recent years is around AI training. As cloud services have built AI features, their policies have been updated to reflect expanded uses of user data.
The specific language to find is whether the service uses your content to train AI models. This may appear:
- In a specific section on AI features
- In a general section on “how we use your data” or “data processing”
- In a separate AI-specific addendum or policy linked from the main privacy policy
Clear red flag: “You grant us a license to use your content to provide, improve, and develop our products and services, including by training machine learning and artificial intelligence models.” This is an explicit grant for AI training on your content.
Yellow flag: “We may use aggregated, de-identified data from our services to improve our AI features.” The devil is in the definitions of “aggregated” and “de-identified,” which are not uniform across the industry and often mean something narrower than users assume.
What good looks like: “We do not use your content to train AI models. We use AI features powered by [named third parties] to provide features including [specific features]; those third parties process your data under our instructions and are contractually prohibited from using it for AI training.”
If you cannot find any mention of AI training in the policy, you cannot conclude that the service does not train on your content. Absence of mention is not the same as absence of practice. Look for the explicit prohibition, not just the absence of permission.
Red Flag #5: Deletion That Isn’t Deletion
When you delete a file from cloud storage, or when you delete your account, the question of what actually happens to your data is answered by specific policy language — not by the fact that the file is no longer visible in your interface.
What commonly happens: Files are moved to a “recently deleted” or “trash” folder with a retention window before permanent deletion. Account deletion triggers a grace period — often 30 to 90 days — before data is actually removed. Backup copies on disaster recovery infrastructure may persist longer than the primary copy. Derived data (thumbnails, metadata, search indexes, AI embeddings created from your files) may be governed by different retention policies than the files themselves.
What to look for in the policy:
- How long is the retention period after file deletion?
- How long is the period between account deletion request and data erasure?
- Do backup systems purge deleted data on the same schedule as primary systems?
- Is derived data (metadata, thumbnails, AI-derived embeddings) deleted on the same schedule as content?
- Does the service make specific commitments about irreversibility of deletion?
What good language looks like: “Upon account deletion, we begin a [X]-day grace period after which your account and all associated content are permanently and irreversibly deleted from our primary systems. Backup copies are purged within [Y] days. We do not retain derivative data beyond the primary deletion window.”
daftei specifies a 30-day grace period after account deletion before permanent, irreversible erasure. The policy does not retain derived data beyond the primary deletion window. Explicit, specific deletion commitments like these are what distinguishes a service that actually deletes your data from one that archives it indefinitely under different labels.
Red Flag #6: Encryption Claims Without Specifics
“We use industry-standard encryption to protect your data” is a phrase that appears in the privacy policy of services with meaningfully different encryption architectures. The statement is technically compatible with server-side encryption (where the provider holds keys and can decrypt your data) and is also compatible with end-to-end encryption (where only you hold keys).
What to look for:
- What is encrypted? (Files in transit? Files at rest? Metadata?)
- What encryption standard? (AES-256 for at rest, TLS 1.3 for in transit are reasonable baselines)
- Who holds the encryption keys? (If the answer is not specified, the provider holds them)
- Is any encryption client-side or end-to-end? (This would be explicitly stated if it were the model — if it is not stated, assume server-side)
Server-side encryption with provider-held keys protects you against storage breaches where an attacker gains raw access to the storage layer. It does not protect you against the provider accessing your files, against legal orders to the provider, or against insider threats at the provider.
End-to-end or client-side encryption means the provider cannot read your files and legal orders to the provider cannot compel production of decrypted content. This is a different level of protection, and it would be stated explicitly in the policy if that is the model.
A policy that says “encrypted at rest using AES-256 and in transit using TLS” without specifying who holds keys is describing server-side encryption. That is the baseline — useful, but not the same as “only you can read your files.”
The Jurisdiction Question
Where the service is incorporated and where its servers operate determines which legal frameworks govern data access requests.
A service incorporated in the United States is subject to US federal law, including FISA national security orders that may come with gag orders preventing the provider from notifying you. A service in the EU is subject to GDPR, which provides stronger baseline data protection rights. Switzerland is subject to Swiss law, which is generally more protective of data privacy than EU law in some respects but also has its own legal process framework.
Jurisdiction does not eliminate legal access risk — every jurisdiction has some form of legal compulsion for data — but it shapes which legal frameworks apply and what rights you have.
A service that holds servers only in one jurisdiction creates a single legal venue for access requests. A service with servers across multiple jurisdictions may be subject to access requests from multiple legal systems simultaneously.
The privacy policy typically identifies the jurisdiction of incorporation. The data processing addendum or “data storage and transfer” section usually identifies where servers are located.
Building a Quick Review Checklist
When evaluating a new cloud storage service, search the privacy policy for these specific terms and read the surrounding context:
- “Train” or “training” — appears in AI training provisions
- “Business partners” — signals potentially broad third-party sharing
- “Law enforcement” or “legal process” — describes disclosure policies
- “Delete” or “deletion” or “erasure” — describes what happens when you remove data
- “Encryption” or “encrypt” — find specifics on key custody
- “Improve” — find definitions of what improvement means for your data
- “License” — describes the rights you grant the provider over your content
Most privacy policies have a search function in the browser. Fifteen minutes with these search terms covers the substantive privacy questions without requiring you to read every word of a lengthy legal document.
The goal is not to find a perfect policy — every service has some data use that might not be your preference. The goal is to understand the actual model clearly enough to make a deliberate choice about what you store where, rather than discovering the terms after the fact.