What is a no-logs VPN, and how would anyone actually verify the claim?

"No logs" is on the homepage of nearly every VPN on the market. It's also one of the least verifiable claims in consumer software, because the thing being promised — that a private company isn't quietly writing down what you do — happens entirely inside infrastructure you will never see. This isn't a reason to dismiss the claim outright. It's a reason to know what kinds of evidence actually exist, what each one proves and doesn't prove, and how to weigh them against each other instead of taking a marketing badge at face value.

What "no-logs" actually covers

The phrase gets used as if it means one thing. In practice, VPN logging splits into three distinct tiers, and a provider can be completely honest about "no logs" while still keeping the middle tier.

Neither connection logs nor aggregate diagnostics are inherently dishonest to keep — the problem is only when a provider markets itself as "zero logs, period" while its own privacy policy, several paragraphs down, says otherwise. Reading the actual privacy policy, not the homepage headline, is step one of verifying any claim.

Why the claim is structurally hard to verify

A no-logs policy is a promise about ongoing behavior on infrastructure the provider controls entirely and you never get direct access to. There is no external mechanism that can continuously confirm a private company isn't writing a line to a log file at 3 a.m. on a Tuesday. Every method of verification available is necessarily indirect — a snapshot, a legal stress test, an architectural safeguard, or a self-reported statistic. None of them, alone, is proof in the way a cryptographic signature is proof. The honest approach is to stack several independent kinds of evidence and see whether they agree.

The four kinds of evidence, ranked by how much they actually tell you

1. Court cases and server seizures — the strongest real-world test

When a government agency legally compels a provider to produce user-identifying data and the provider genuinely cannot, that's a result no self-commissioned report can replicate — nobody chose the scenario or the timing, and the stakes for getting caught lying were real. A handful of providers now have a public track record here, in both directions:

2. Independent third-party audits — a scoped snapshot, not a live feed

Firms like Deloitte, PwC, and the security research group Cure53 are hired to inspect a provider's server configuration, source code, or internal processes against its stated no-logs policy. A real audit is meaningfully different from a "security review" a company writes about itself — the auditor is independent, the methodology is disclosed, and (ideally) the full report is published rather than summarized in a press release.

What it doesn't do: verify anything outside the agreed scope, or anything that happens after the audit's field work concludes. A provider that publishes one audit from three years ago is offering weaker evidence than one that publishes a fresh audit annually — recency and repetition matter as much as the auditor's name. Our Surfshark review walks through one real example of what a repeated, multi-firm audit trail actually looks like in practice, rather than a single one-off report.

3. Technical architecture — RAM-only servers, and a genuine industry disagreement

Some providers run their entire server fleet in volatile memory with no hard drives at all. Reboot the server, or cut its power, and everything on it disappears — which is precisely why the Turkish and Dutch server seizures above turned up nothing. It's a real, verifiable engineering choice, not a marketing claim you have to take on faith.

It's also genuinely contested within the industry. Proton VPN has publicly argued that RAM-only is oversold as a security guarantee, since a server's live memory is just as accessible to anyone with root-level access while the machine is running — the scenario RAM-only actually defends against is narrower: a server seized while powered off. Their position is that full-disk encryption on a stopped server provides comparable protection in most realistic threat models. Both positions have a real technical basis; the practical takeaway is that RAM-only is one useful signal, not a complete answer on its own.

4. Transparency reports — useful, but self-reported

A transparency report discloses how many legal requests a provider received in a given period and how many it could actually fulfill. A provider showing hundreds of requests received and zero fulfilled with user data is offering real evidence — but the report is written and published by the company itself, with no external party checking its accuracy before release. It's most useful as a companion to a court case or audit, not as a stand-alone proof point.

Warrant canaries: mostly symbolic today

A warrant canary is a regularly-updated statement saying, in effect, "we have not received a secret government order as of this date" — the idea being that if the statement quietly stops updating, users can infer something happened that a gag order prevents the company from stating directly. In practice, canaries have fallen out of favor: their legal enforceability is untested and disputed, they're trivially easy to let lapse for unrelated reasons, and most providers with a serious verification story have shifted toward audits and published transparency reports instead, which carry a clearer, independently checkable meaning.

Red flags that undercut a no-logs claim before you even test it

• Jurisdiction with mandatory data-retention laws. A provider legally required to log connection metadata can't out-promise the law it operates under, no matter what its homepage says.
• Ownership by an ad-tech or data-broker parent company. A VPN's revenue model matters — a company whose broader business is built on user data has a structural incentive at odds with the product it's selling you.
• Free VPNs with no clear monetization story. Server costs are real and ongoing; if a free app isn't selling a subscription, it needs another revenue source, and that source is worth identifying before you trust its privacy policy — see our free vs. paid VPN guide for what that usually turns out to be.
• A rewritten privacy policy with no changelog. Providers with nothing to hide generally don't mind showing what changed and when.
• Marketing that says "audited" without naming the firm, the date, or linking the report. A real audit is something a provider is eager to show you in full, not gesture at vaguely.

How to actually evaluate a provider's claim yourself

1. Read the actual privacy policy, not the homepage summary — specifically the sentence describing what's logged during an active connection, not just "after the fact."
2. Look for a named, dated, published third-party audit — and check whether it's been repeated, not a single report from years ago.
3. Search for the provider's name alongside "subpoena," "seized," or "court" to see whether its claim has ever actually been tested, and how it held up.
4. Check the provider's home jurisdiction against known data-retention mandates — a claim can be sincere and still be legally overridden depending on where the company is incorporated.
5. Check ownership history. Several major no-logs incidents trace back to a provider's ownership at the time, not its current management — this context changes how much weight an old failure should carry today.

None of this replaces the basics covered elsewhere on PrivacyTestLab — a no-logs policy only protects what happens after your traffic leaves your device; it doesn't fix a kill switch that fails silently, and it says nothing about whether your DNS requests are actually routed through the tunnel in the first place. Verifying "no logs" is one piece of a larger picture, not the whole thing.