VPN Logging Policies Explained: What No-Logs Actually Means

Why this matters more than marketing pages admit

Every major VPN provider advertises a “no-logs policy.” The phrase is worn out from marketing, but the underlying question is the entire privacy proposition of a VPN. When you route your traffic through a provider, you are asking them to see everything your ISP used to see. The only reason to do that is if you trust them more than you trust your ISP. That trust depends almost entirely on what they log, how long they keep it, and what they would have to hand over if a government asked.

A clear policy tells you exactly what is stored, for how long, and where. A bad policy uses the words “no logs” on a banner and then defines “logs” in a way that excludes all the things they actually keep. The difference is not academic. It is the difference between a VPN and a surveillance relay.

What a VPN can technically see

Before we read a policy, it helps to know what is architecturally possible. Any VPN that routes your traffic through its servers can, at minimum:

• See your real IP address when you connect.
• See the VPN server IP you are assigned.
• See the destination IP addresses and hostnames you connect to.
• See DNS queries unless those are offloaded to a third-party resolver outside the tunnel.
• See connection timestamps and session durations.
• See bandwidth volumes.
• See any unencrypted payload (rare in 2026 thanks to HTTPS, but not zero).

What a VPN cannot see, for HTTPS traffic, is the content of the pages you visit. That is between you and the destination server. But metadata — who you talk to, when, and how often — is often as revealing as content. A no-logs policy exists to make sure none of this metadata is stored where it could be compelled out of the provider.

The three categories of VPN logs

Almost every VPN policy can be read as a statement about three log categories. Learn these three and the rest is vocabulary.

1. Activity logs (browsing logs). URLs visited, DNS queries resolved, specific destinations contacted, and traffic volumes to those destinations. Activity logs tie a user account or real IP to a list of what they did. If a provider keeps these, they are not a privacy tool. This is the category that “no-logs” should exclude.
2. Connection logs. Metadata about each session: the user's real incoming IP, the VPN server they connected to, the time and duration of the session, and total data transferred. Connection logs do not tell an outsider what you did, but they can correlate you with a public IP at a specific time. Subpoena-friendly.
3. Aggregate and operational logs. Anonymous counters: total bandwidth per server, number of concurrent users, load averages, crash reports without identifiers. These are nearly unavoidable for running a service and do not meaningfully affect user privacy if they are actually anonymous.

When a provider says “we are a no-logs VPN,” the question is whether they are talking about category one, categories one and two, or all three. Marketing copy often blurs this on purpose.

How to read a no-logs policy in ten minutes

Pull up the privacy policy in one tab and this checklist in another. Look for the following items, in order. If any are missing or vague, the policy is weaker than it looks.

• ☐ An explicit list of data that is not collected. “We do not store destination IP addresses, DNS queries, or browsing history” is concrete. “We respect your privacy” is not.
• ☐ An explicit list of data that is collected, even if limited. Every service collects something. If the policy says “we collect nothing,” it is either wrong or carefully defining “collect.”
• ☐ A retention period. Logs held for 30 days are not the same as logs held indefinitely.
• ☐ Whether any connection logs include the real source IP. Some providers keep session metadata but strip the user's IP from it. That is a meaningful mitigation.
• ☐ Whether DNS queries are kept, and whether the resolver is operated by the VPN or outsourced.
• ☐ The jurisdiction of the operating entity. Not the marketing brand, the legal entity.
• ☐ A warrant canary or transparency report history. Absence is not proof of logging; presence is a signal the provider takes compelled disclosure seriously.
• ☐ A named third-party auditor and a dated audit report. Not a logo. A downloadable report with scope, date, and findings.

Jurisdiction 101

Jurisdiction is not a silver bullet, but it is where legal process lands when governments want data. The short version:

• Five Eyes (US, UK, Canada, Australia, New Zealand): strong legal frameworks for compelled disclosure, broad intelligence-sharing agreements. A VPN can still be run well here — Private Internet Access is US-based and has tested their no-logs stance in court — but the provider's architecture has to do the work.
• Nine Eyes and Fourteen Eyes (adds several EU countries, Germany, France, the Netherlands): similar exposure, fewer reciprocal disclosure agreements, generally stronger due-process protections.
• Privacy-friendly jurisdictions: Switzerland, Panama, British Virgin Islands, and sometimes Sweden. No mandatory data retention for VPN providers, local law requires valid legal process, and extraterritorial reach is limited. Providers headquartered here include NordVPN (Panama), Proton VPN (Switzerland), and ExpressVPN (BVI).

Jurisdiction defines what a government can legally compel. Architecture and logging policy define what the provider can actually produce if compelled. Both matter; neither is sufficient alone.

Real-world tests of no-logs claims

Marketing copy is easy. Producing zero usable data when a law enforcement agency shows up with a warrant is hard. A handful of cases have put no-logs claims to the test.

• ExpressVPN, Turkey, 2017. Turkish authorities seized an ExpressVPN server as part of an investigation. No usable user data was recovered. ExpressVPN later moved to RAM-only infrastructure across its fleet.
• Private Internet Access, multiple US cases. PIA has been subpoenaed by US authorities several times. The company has repeatedly stated, and court filings have confirmed, that it could not produce user activity data because it was not collected.
• Mullvad, Sweden, 2023. Swedish police executed a search warrant at Mullvad's office looking for customer data. The raid reportedly left empty-handed because Mullvad does not store customer identifying information in the first place.
• NordVPN, 2018 Finland server incident. An intruder gained access to a single server via a misconfigured remote management tool. No user logs were compromised, but the incident exposed weaknesses in their infrastructure monitoring. NordVPN responded by auditing its fleet and publishing findings.

These cases do not prove that all no-logs claims are genuine. They do prove that some no-logs architectures work under real legal pressure. When evaluating a new provider, the absence of such test cases is not proof of failure, but the presence of one is strong evidence.

Independent audits: what counts and what does not

An audit is only as good as its scope, its methodology, and its auditor. Here is how to read one without getting fooled by a logo.

• Named auditor. Cure53, Securitum, KPMG, Deloitte, Leviathan, PwC, and Assured have repeatable methodologies and reputations to protect. A one-time “audit” by a firm with no track record should be treated skeptically.
• Scope. An audit that only covers the Windows client tells you little about server logging. Look for audits of the server infrastructure, the logging configuration, and the privacy claims specifically.
• Date. A 2019 audit does not tell you anything about 2026 infrastructure. Recurring annual audits are stronger than one-off reports.
• Findings. A good audit finds things. A report with zero findings is either from an auditor that did not look hard or a provider that is exceptional. Both are possible; neither is the default.
• Public availability. The full report should be downloadable, not summarised on a marketing page.

The case for RAM-only servers

RAM-only (sometimes called “diskless”) infrastructure is now common across top-tier VPNs. The servers run from volatile memory, with the operating system loaded from a read-only source at boot. There is no persistent disk to collect logs on, and a reboot wipes any runtime state.

What this buys:

• A stolen or seized server contains no logs by definition.
• Forensic investigators cannot recover deleted files, because there are none.
• Rogue changes to the server are rolled back on the next reboot.

What this does not buy:

• Protection from logs being forwarded to a central log pipeline. If syslog or a telemetry agent on the box ships data to a remote collector, the RAM-only server is not the final storage location.
• Protection from runtime memory being dumped during an active attack. This is niche, but real.

RAM-only is a strong signal; it is not a proof of no logging. It only works when paired with a broader architecture that limits where data can flow and an audit that verifies the whole pipeline.

Named providers, summarised

Based on public privacy policies, published audits, and documented legal cases as of May 2026. This is informational; we are not endorsing any specific product in this guide.

Red-flag language in VPN privacy policies

Language that should make you read the rest of the policy very carefully:

• “We do not log your browsing activity.” Technically narrow. May still log DNS, timestamps, connection metadata, or real IPs.
• “We may collect information to improve the service.” Vague catch-all. Look for what, exactly, is improved.
• “We share data with third-party service providers.” Expected for billing and crash reporting, concerning if the third parties are ad networks or analytics platforms.
• “We reserve the right to comply with lawful requests.” Everyone does. The question is what they would have to hand over.
• “Logs are anonymised.” Anonymisation is easy to claim and hard to verify. Aggregated counts are defensible; “anonymised” session records often are not.

A practical checklist before you subscribe

Ten minutes per provider. Do this for any VPN you are paying for:

• ☐ Read the privacy policy end to end. Yes, the whole thing.
• ☐ Identify the specific operating legal entity and its jurisdiction.
• ☐ Find a third-party audit from a named firm within the last 24 months, and skim the scope.
• ☐ Check whether the provider has ever been subjected to legal process, and if so, what was produced.
• ☐ Verify the provider runs its own DNS resolvers or uses encrypted third-party DNS, not the default ISP resolver.
• ☐ Check for a transparency report or warrant canary.
• ☐ Run a DNS leak test and an IPv6 leak test after connecting. If traffic leaks outside the tunnel, the logging policy is moot.
• ☐ Look for RAM-only infrastructure or an equivalent architectural commitment.

The bottom line

No-logs is a specific technical and legal commitment, not a slogan. A credible no-logs claim has three parts: a privacy policy that is concrete about what is and is not collected, an architecture that makes logging difficult (RAM-only servers, provider-run DNS, jurisdiction without mandatory retention), and at least one piece of public evidence that the commitment holds — a court case, a raid, or a recurring independent audit.

If a VPN has all three, its no-logs claim is defensible. If it has only marketing copy, treat the tunnel as private from your ISP but not private from the VPN.

Related reading: Free VPN risks · Do you still need a VPN? · What to do after a data breach.

Frequently Asked Questions