Reading a VPN Logging Policy, Clause by Clause

Last updated: October 29, 2026 · Based on provider policies and independent audit documentation

A VPN's logging policy is the single most useful document a provider publishes, and also the one most likely to be written to be skimmed rather than read. The word “no logs” appears in almost every comparison table, and it means at least three materially different things. This guide takes the policies apart sentence by sentence so you can tell which kind you are being offered, and what each version does not cover.

Table of contents

• Three different promises hiding behind one phrase
• The four clauses every policy needs to answer
• Why “we do not log” is often technically true and useless
• Reading the exceptions: the sentences that undo the headline
• Audits: what a report actually establishes
• A worked example: reading two policies against the same checklist
• Red flags
• FAQ
• Bottom line

Three different promises hiding behind one phrase

When a provider says it keeps no logs, it is usually making one of three claims, and the difference between them is the difference between a policy you can rely on and one you cannot.

• No activity logs. The service does not record what you visited. Connection metadata may still exist.
• No connection logs. The service does not record which server you connected to, when, or for how long. This is the version that matters for the question most people are actually asking.
• No identifiable logs. Data may be retained in some form, but it is not tied to an account or an IP address. Retention becomes a technical question rather than a policy one.

These are not equally strong, and providers sometimes use the first while implying the third. The order of the words in a headline is not evidence. The order of the definitions inside the policy is.

The four clauses every policy needs to answer

Whatever the marketing summary says, a logging policy has to settle four separate questions. A policy that answers three of them is incomplete, and the missing one is usually the one you would have relied on.

• What is not collected. The category of data that never reaches the provider's systems: browsing destinations, DNS queries, the content of traffic.
• What is collected anyway. Almost every provider retains something operationally necessary: the server you connected to, the time, the assigned IP, the account. The question is whether that data is tied to your identity.
• How long it is kept. A retention period stated in days or hours is a stronger signal than the word “ephemeral.” [VERIFY the current stated period for any provider you are considering.]
• Who can see it, and when. Whether the provider shares data with third parties, and whether any legal process can compel disclosure. A policy that says it will notify you of a legal request is meaningfully different from one that does not.

Why “we do not log” is often technically true and useless

A provider can honour a strict no-logs promise and still deliver a service that is not private in the way users assume, because the interesting questions live outside the logging policy. Three things sit beside it.

The DNS resolver. Where domain lookups are sent determines who sees the sites you visit, even when the VPN tunnel itself carries no record. Some providers resolve inside the tunnel; others hand the lookup to a third party. This is stated in the DNS section, not the logging section, and it is the more consequential of the two.

The account record. Payment details, an email address and an account identifier are held regardless of what the tunnel logs. This is normal and unavoidable; it is also why an account-bound no-logs claim is a weaker guarantee than it sounds.

The shared server. A server that holds multiple users' traffic at the same moment is not the same as a server holding one user's traffic alone. Persistence — a disk image that retains fragments — is a separate property from logging, and it is where memory-based and disk-based providers differ most.

Reading the exceptions: the sentences that undo the headline

Long policies are long for a reason. The exceptions are where the real terms live, and they are consistently placed further down than a reader goes.

• Malware and abuse handling. Most policies retain the ability to suspend an account and report traffic that violates a law or a provider's acceptable-use rules. The scope of that exception varies widely, and “we may review traffic in the event of a complaint” is a different promise from “we may access traffic to investigate a valid legal process.”
• Crisis and incident response. A provider under investigation or attack may temporarily widen what it holds. This is a sensible operational necessity and also a real window in which the policy does not hold.
• Aggregated or anonymised data. Many policies distinguish data that cannot be tied back to a user from data that can. The test is whether re-identification is possible in practice, which is a question about the data rather than about the sentence.

When you find these clauses, note what they permit rather than whether they exist. Every serious provider has some version of them. The difference is the breadth.

Audits: what a report actually establishes

An independent audit is the strongest evidence available short of reading the server yourself, and it is routinely over-read. Understanding what it covers prevents both over-trusting and over-dismissing.

• It establishes a specific claim at a specific time. An audit that examines a no-logs policy says nothing about whether the policy changed the following month.
• It establishes what was tested, not what was possible. The scope of the examination matters: whether it covered a full billing period, whether it covered every server type, whether the sample was large enough to be meaningful.
• It does not cover everything else. DNS handling, account records and application-layer behaviour generally sit outside a traffic-logging audit.
• Unverified means unverified. A “no logs” claim with no audit behind it is a marketing statement, and it should be weighted accordingly.

Look for the audit's own wording rather than the summary around it, and note whether the auditor is independent of the provider's own engineers or working from the provider's documentation.

A worked example: reading two policies against the same checklist

Take two providers and put them through the same four-clause checklist. The exercise is worth doing because it turns a marketing comparison into a structural one.

Provider A's policy opens with a summary sentence, then defines categories. It names what it retains, gives a retention period for each category, describes DNS handling in its own section, and closes with a clause about sharing with authorities that includes a commitment to notify the user where lawful. It has been audited, and the audit covers the traffic-logging claim across a defined period. [VERIFY the current terms directly against the provider's own policy page.]

Provider B's policy uses a single sentence to describe retention — a general statement about collecting only what is needed to run the service. It has no separate DNS section, no per-category retention periods, and no user-notification commitment. It has not been audited. Its summary table on a comparison site shows “no logs” in a green box, and so does Provider A's.

Both read as “no logs” in a summary table. Read clause by clause, the difference between them is large, and it has nothing to do with encryption quality or server count. The second provider's position may still be perfectly adequate for a person whose threat model does not include an adversary with legal process. What it does not do is establish the stronger property that the first one does.

This is the argument for reading policies rather than comparison tables. A table can only carry one cell. A policy carries the exceptions, and the exceptions are the policy.

Red flags

• No retention period anywhere. If a policy says nothing about how long, it has not answered the question.
• Retention described only as “aggregated” or “anonymous”. These terms are not technical guarantees, and they are used where they are convenient.
• DNS handling is not addressed at all. Silence here is not evidence of privacy; it means the question was left out of the document.
• An audit that covers a different claim than the headline. An audit of app security is not an audit of logging practices. Read what was examined.
• A policy whose summary contradicts its detail. If the headline says one thing and the definitions say another, the definitions are the terms.

FAQ

Does “no logs” mean the provider cannot see what I do?

It means the provider does not log it in the ordinary course of business. It does not mean the provider is technically incapable of observing traffic, because any service delivering your traffic can see it while it passes through. The difference is whether it is written down and retained, not whether it is momentarily visible. That distinction is the whole content of the policy.

Is a policy with a wide malware-abuse exception worse than no policy?

Not automatically. Every provider needs the ability to respond to a legal process and to block abuse. The question is the shape of the exception: whether it is scoped to a defined trigger and a defined period, or whether it is a general permission. A narrow exception with a stated process is a normal commercial term. A broad one is a blank cheque.

Does a server in my own country matter for the logging question?

It matters, and it cuts both ways. A provider subject to local legal process can be compelled to disclose what it holds; a provider in a different jurisdiction is not automatically safer, because the data it holds may still be reachable through other channels. This is worth thinking through alongside the policy rather than instead of it, and the framing in how to read a VPN's claims covers the jurisdiction question in more depth.

How often do policies change?

More often than version numbers suggest, and the changes are rarely announced. This is the practical argument for reading the policy at the moment you subscribe rather than trusting a copy you read once, and for treating an audit as evidence about a period rather than a permanent property.

Bottom line

The distance between a strong logging policy and a weak one is not visible in any comparison table. It lives in four clauses — what is not collected, what is collected anyway, how long it is kept, and who can see it — and in the exceptions that modify them. Read those, then read the section on DNS and the section on your provider's legal exposure. If a provider publishes those clearly, the summary box on someone else's site is the least informative part of the decision.

If you have decided that a VPN is the right tool and want to see current pricing, the link below goes to our own comparison page for the category.

See current VPN plans →