HOSTING / KNOW WHO CAN SEE YOUR DATA
Privacy When Choosing Hosting
Privacy is about what information is collected, who can use it, and how long it stays around. A service can protect its servers well while still collecting more data than you want.
This guide is about choosing hosting services. For how this website handles requests, read the separate site privacy policy.
Start with the Information, Not the Privacy Badge
List what the service needs to do its job. Then identify data collected around that job: visitor addresses, request URLs, mailbox metadata, DNS queries, account details, support attachments, backups and diagnostic logs. Metadata can reveal patterns even when message content is encrypted.
| Service | Information to consider | Question to ask |
|---|---|---|
| Web / application | Visitor logs, uploaded content, databases, error traces and third-party plugins. | Can sensitive fields be excluded from logs and analytics? |
| DNS | Public zone records and query logs are different datasets. | What is public, and which queries does this provider retain? |
| Messages, attachments, delivery metadata, archives and administrator access. | Who can access mailbox content, and is that access audited? | |
| Server / storage | Disks, snapshots, replicas, encryption keys and support diagnostics. | Who can decrypt copies, and when are they deleted? |
| VPN | Connection information, account records, routing and app telemetry. | Which exact categories does the “no logs” claim exclude? |
Encryption: Protected from Whom?
- In transit: protects a connection between defined endpoints. If a CDN terminates HTTPS, that CDN is an endpoint for that connection.
- At rest: protects stored data under a key and access model. If the service can use the key, it may decrypt data to operate.
- End-to-end or client-side encryption: can keep content inaccessible to the storage or transport provider when the design and key custody actually provide that property. Metadata and endpoints still need consideration.
Ask who holds usable keys, who can authorize decryption, and whether support or recovery procedures create another access path. “Customer-managed keys” alone does not answer all three questions. Confirm how losing a key affects recovery before depending on a provider-blind design.
Require individual accounts, limited permissions and recorded privileged access where the service supports them. Separate routine support access from emergency access, and ask how each is approved and reviewed.
Data Location Is More Than a Region Selector
The location of the primary server is only one part of the picture. Backups, failover copies, support access, logs, security tools and subcontractors may involve other locations. Ask for the scope of a residency commitment in writing.
A country name is not a universal privacy rating. Applicable rules depend on the parties, processing and circumstances. For organizational or sensitive data, review the relevant processing agreement, subprocessors, transfer arrangements and incident-notification terms with qualified help where needed. A hosting certification does not automatically make your use compliant.
Retention and Deletion Need Separate Answers
“Delete” can mean removing an item from the live application while copies remain in a recycle bin, snapshot, log or backup. Ask about each data category, not just account closure. Retention locks and legally required preservation can change what is removable and when.
Long retention can improve recovery while increasing stored-data exposure. Keep what is needed, restrict access and test deletion as well as restoration. “Unlimited backups” is a capacity claim, not a reason to keep sensitive data forever.
Public DNS and Domain Privacy Are Different
Public DNS records are meant to be answered. Obscure hostnames and TXT values are not suitable places for secrets. DNSSEC authenticates DNS data; it does not make the records private. Encrypted DNS can protect a client-to-resolver connection while the resolver still processes the query. See the IETF’s DNS privacy considerations.
Domain registration privacy concerns registration contact information, not the content of the website or DNS zone. Public redaction does not mean no information is held by a registrar or that disclosure can never occur. Rules vary by domain ending; ICANN’s Registration Data Policy addresses the covered gTLD registration context.
A VPN Changes the Trust Boundary
A correctly configured VPN can protect traffic within its tunnel from the local network. The VPN operator becomes another party to evaluate. It does not remove account identity, cookies or browser fingerprinting. Ordinary HTTPS protects its content through the VPN unless TLS is intercepted; do not treat VPN encryption as a replacement for HTTPS.
Confirm which traffic is routed, how DNS and IPv6 are handled, and what happens on reconnection or tunnel failure. Review the exact logging policy, business model and audit scope. A recent audit is useful evidence within its scope, not a perpetual guarantee. The FTC’s VPN guidance explains why the operator deserves scrutiny.
Understand personal, remote-access and site-to-site VPN services →
Privacy Questions to Take to a Provider
- What content, metadata, account and diagnostic information do you collect?
- What is each category used for—including advertising, profiling or AI training—and can secondary uses be disabled?
- Who can access or decrypt it, and what access records are available?
- Where do primary data, backups and support processing take place?
- Which subcontractors or integrations receive data?
- What are the retention and deletion timelines for each type of copy?
- What happens after cancellation, a restoration or a legal preservation requirement?
- Which published commitments and current audit findings support the claims?
The takeaway: choose a service whose data practices fit your needs. More storage, more encryption badges or a different server country cannot replace clear answers about access and use.