VPN Privacy Policy vs the Data Path: A Comparison Walkthrough

Take one sentence from the policy, the one that made you consider the provider, and follow it through the system. A promise about the tunnel does not automatically describe the account portal, the resolver, the support inbox or the payment processor. Most bad comparisons come from reading a claim about one component and applying it to another. The walkthrough below turns that habit into a short worksheet.

Follow the data, not the adjective

A headline such as no activity logs is a statement about a category, and the useful question is which component could produce that category in the first place. The tunnel endpoint can see source addresses and timestamps; a resolver can see queried names; the account system can see identity and payment history; support can see whatever you paste into a ticket. Two of those might be operated by the same company and one might be a contractor.

Encryption in transit tells you nothing about retention, because the endpoint decrypts before it forwards.

Build a component map first

Write six rows: client application, tunnel endpoint operator, DNS resolver, account and billing system, support channel, and any diagnostic or crash-reporting recipient. For each row note who operates it and whether that party is the same company you are reading about. White-label services, contracted support desks and third-party analytics make the answer interesting more often than not.

Then list what each component technically has access to: source address, account identifier, queried name, connection time, transferred volume, device details, submitted report. Availability is not retention, but it identifies which part of the policy has to answer for which question.

Compare categories, purpose, retention and sharing

A claim about not storing browsing destinations does not cover session timestamps, and a claim about aggregate statistics does not describe the raw records that fed them. Look for the exact category, the stated purpose, the retention period and the sharing language, in that order. Where the policy says anonymous, check what identifiers and time granularity were removed rather than accepting the word as an explanation.

Watch for policy sections that apply by product line. A browser extension, a mobile client and a router appliance from the same brand can have different data paths, and the policy may cover all three with one page of generalities.

The IETF privacy considerations guidance is a useful structure here because it forces the analysis per component rather than per marketing sentence.

Price the evidence you accept

Open-source client code describes what the client does with your data, and it says little about the backend that terminates the tunnel. An audit covers a stated system over a stated period, which is useful and narrower than a permanent guarantee. A jurisdiction claim is a statement about legal process, not about technical logging. Each of those is evidence of a specific kind, and mixing them produces confident conclusions that nobody can defend a year later.

Encryption at rest protects records that still exist, so it answers a different question from whether the records exist at all.

Record what stayed unanswered

Where a component is missing from the policy or a category is not addressed, write unexplained next to it. That is the honest result, and it is more useful than converting silence into either a guarantee or an accusation. Keep the policy version and date beside your notes, because these documents change quietly and a comparison without a version ages badly.

Finally, be clear about what your own testing proved. A working exit and a changed public address demonstrate routing. They say nothing about server-side retention, and the worksheet is where that distinction lives.