How to read a cloud provider's security page like a skeptic

Cloud-provider security pages have converged on a small vocabulary of reassuring phrases. “Bank-grade encryption.” “Military-grade AES-256.” “Trusted by thousands of companies.” “Compliant with [long list of acronyms].” A reader who is not already a specialist has very little chance of telling a thoughtful security program apart from a well-edited page.

This article gives you the questions to ask. For a solo operator or small business, working through them in fifteen minutes will often tell you more than any marketing page.

Question 1: Is “encrypted” specific?

“Encrypted” on its own tells you almost nothing. Look for:

• At-rest encryption. What algorithm and key size? AES-256 is the baseline. Anything less is a flag.
• In-transit encryption. What TLS versions are supported? TLS 1.2 minimum, preferably 1.3, with modern cipher suites.
• Who holds the key? This is the most important question. If the provider holds the key, they can decrypt on demand — for law enforcement, for themselves, for a future acquirer. If only you hold the key, they cannot.
• Client-side encryption option? Even if the default is provider-held keys, good providers offer a way to bring your own key, or to encrypt on your device before upload.

Phrases like “end-to-end encrypted” and “zero-knowledge” are specific claims. If the page uses them, great — confirm they match the technical documentation.

Question 2: Is there independent evidence?

A security page with no third-party evidence is just the provider’s word. The three common types of independent evidence:

• SOC 2 Type II report. The standard audit for service providers. Type II means the auditor tested controls over a period (usually a year), not just at a point in time. Ask whether a SOC 2 report is available under NDA to customers.
• ISO 27001 certification. A formal information security management standard, with independent certification. Common in enterprise contexts; meaningful but narrower than it sounds.
• Published penetration-test summaries. Some providers publish redacted summaries of annual pen tests. Their existence is a good sign; full public pen-test reports are rare and not always useful.

A “security badge wall” showing SOC 2, ISO 27001, HIPAA-eligible, and GDPR on the homepage is, on its own, just a set of badges. Click through and see what you can actually read.

Question 3: What is their history?

Look for:

• A public incident history. Good providers publish a status page and a post-incident write-up habit. Providers who have never had an incident either aren’t paying attention or haven’t been around long.
• Transparency reports. Legal requests received, accounts affected, and compliance rate. Providers who publish these regularly — quarterly or semi-annually — are showing their work.
• Breach history. Search for the provider’s name plus “breach” or “incident” in Google News. Some of the most-trusted providers have had incidents; what matters is how they handled them. A provider that hid or minimized a past breach is a stronger flag than one that handled one openly.

Question 4: What is their policy on legal requests?

Every cloud provider receives legal process — subpoenas, warrants, national security letters, foreign government requests. A reasonable provider will publish a policy. Key things to look for:

• Notification policy. Do they notify you before handing over data when legally permitted? Good providers do, with specific exceptions for sealed orders.
• Minimum required disclosure. Do they disclose only what the order requires, or do they add to it?
• Gag-order handling. Where forbidden from notifying you, do they use a warrant canary (a periodic statement they have not received a certain class of order, which they stop publishing when they have)?

Providers that hold your keys are a single legal step away from disclosing your plaintext. Providers that offer E2EE or client-side encryption are often required to disclose metadata, not content, because that is all they have.

Question 5: Where is the data, legally?

“Cloud” is not a jurisdiction. Ask:

• In which countries are your data physically stored?
• In which countries is the provider incorporated?
• What is the chain of ownership (any parent companies in different jurisdictions)?

A provider incorporated in one country, operating servers in another, and owned by a parent in a third is subject to the legal processes of all three. For most consumer uses this is not decisive. For regulated industries, for journalists working on politically sensitive stories, or for people living under governments they would prefer not to have access to their files, it matters a great deal.

Question 6: How is my account protected?

• Two-factor authentication options. TOTP at minimum; hardware keys, ideally. SMS-only is a sign of weak security engineering.
• Session management. Can you see and terminate active sessions?
• Alerts on suspicious sign-ins. By email or push.
• Account recovery. How does recovery work? Is it stronger or weaker than sign-in? Many account compromises happen via weak recovery flows, not via the main sign-in.

Question 7: How do I get out?

Often forgotten: the exit door.

• Can you export all your data in standard formats? How long does it take? Is there a cost?
• What happens to your data after you cancel? After what period is it deleted? Can you get a written confirmation of deletion?
• If the provider goes out of business, what happens to your data? Some provide a retrieval window; many do not.

Providers with clear exit paths are generally better-managed overall. Providers whose exit paths are unclear are providers you should plan to exit before you have to.

A ten-minute workflow

Open the provider’s security or trust page and look for, in this order:

1. An explicit statement about who holds the encryption keys.
2. A specific mention of SOC 2 Type II or equivalent, with an NDA path to see the report.
3. A link to a status page and an incident-history archive.
4. A transparency report.
5. A written policy on legal requests, including notification.
6. Documented data-export tooling.
7. Two-factor authentication including hardware keys.

If four or more of those are missing, you have a less-mature provider than the brand name suggests. That may or may not be acceptable — the right answer depends on your threat model — but at least you know.