How to read a VPN privacy policy in ten minutes
Six phrases decide almost everything in a VPN privacy policy. Here is how to find them and what the answers mean.
August 20, 2026 · 9 min read
TL;DR — The homepage is marketing; the privacy policy is the part with legal consequences, and the two frequently disagree. You do not have to read it end to end. Search for six specific phrases, use them to answer three questions, and you will know what a provider actually collects — in about the time it takes to make coffee.
Nobody reads privacy policies, and the people who write them know it. That is not usually a conspiracy — it is a document written by lawyers to protect a company, in language that makes broad permissions sound procedural. But it is also the only part of a VPN’s website with legal consequences attached, which makes it the only part worth trusting over the homepage.
The good news is that you do not need to read it properly. Almost everything that matters clusters around a handful of phrases, and a search box finds them in seconds.
Why the homepage and the policy disagree
A homepage says “we never log your activity”. A policy says the company “may collect certain diagnostic information, including connection timestamps and bandwidth consumption, to maintain service quality”. Both sentences can appear on the same website, and only one of them was reviewed by a lawyer.
They disagree because they are written for different purposes. The homepage is a promise to a customer; the policy is a description of permissions to a regulator. When they conflict, the policy is the one that describes what is allowed to happen.
The six phrases to search for
Open the policy, press Ctrl-F or Cmd-F, and work through these. Each one marks the spot where the real terms usually live.
“may collect”
The most important two words in the document. “May” is a permission, not a plan — it describes the ceiling of what is allowed, and the ceiling is what you are agreeing to. Read everything after it as though it is already happening.
“affiliates” / “partners”
Where data sharing gets described without naming a recipient. If a policy shares with unnamed partners for unspecified purposes, the effective scope is whoever the company chooses tomorrow.
“aggregated” / “anonymised”
Often accurate, sometimes doing a lot of work. Ask what is aggregated and how — connection metadata that includes timestamps and a source IP is not meaningfully anonymous, however it is summarised.
“business transfer”
The clause that says your data moves with the company if it is sold. Common, unremarkable, and worth noticing: it means the privacy policy protecting you is a policy the next owner can rewrite.
“as required by law”
Every provider has this and every provider must. It is not a red flag on its own. It is only meaningful alongside the answer to what actually exists to be produced — the clause is a pipe, and what matters is whether anything is in it.
“connection logs” / “diagnostic”
The polite terms for session metadata: timestamps, server chosen, bytes transferred, sometimes the source IP you connected from. This is where a no-logs claim most often turns out to have a footnote.
Three questions the policy must answer
With those phrases located, you are trying to answer three things. If the document cannot answer them clearly, that is itself the answer.
- What is required to create an account? An email address populates a permanent identity record no matter what the logging section says. This is the question people skip, and it is usually the one that decides whether a provider can name you.
- What is retained about a connection, and for how long? Look for the retention period specifically. “We do not log activity” and “we retain connection records for 30 days” can appear in the same policy and both be true.
- Who else receives it, and what happens if the company is sold? Sharing clauses and business-transfer clauses together describe the full set of parties who could end up holding your data, including parties who do not exist yet.
What a good answer looks like
Rather than describe one abstractly, here is ours, so you can check the method against a real document. Our privacy policy answers the three questions like this: nothing is required to create an account beyond generating a 16-digit number; no activity, DNS or user-attributable IP records are retained at all, so there is no retention period to state; and there is no subscriber identity data to share, transfer or sell, because none was collected.
You should not take that on faith either — which is the point of the next section.
What this method will not catch
A privacy policy is a statement of intent. It is not evidence, and reading one carefully cannot tell you whether the code matches the claim. Plenty of providers with excellent policies have been found retaining data anyway, sometimes without their own management knowing.
Closing that gap takes something outside the document: an independent audit of the running implementation, published in full rather than summarised into a badge. That is a different question with its own answer — we wrote about why a no-logs claim needs an audit separately, and our own report is on the transparency page.
Used together, the two get you somewhere reasonable: the policy tells you what a provider permits itself to do, and the audit tells you whether the system it built is capable of doing it.
Read ours with the same method
Six phrases, three questions, ten minutes. We would rather you ran the test than took the adjective — and ran it on us as carefully as on anyone else.
Get LunoVPN See pricing