What Is a No-Log VPN? (How to Verify the Claim)

A no-log VPN is a provider that does not collect or store records of your online activity: your browsing history, the IP addresses you connect to, your DNS queries, or the files you download. The credible version of that commitment has three parts: zero activity logs, minimal and time-limited connection metadata, and a transparent account-data policy that states what is held and for how long.

Privacy and anonymity are different properties, and a no-log policy addresses only privacy. Privacy means hiding your activity from third parties such as your ISP, your employer, or government surveillance. Anonymity means being untraceable even to the VPN provider itself. A VPN can deliver privacy without delivering anonymity: a provider that shares your data with no one can still hold enough information to identify you if a court compels disclosure. For the architecture that delivers anonymity rather than privacy through provider trust, see the Tor vs. VPN comparison.

TL;DR

  • A no-log VPN does not collect or store records of your browsing history, DNS queries, IP addresses visited, or downloaded files. Reputable providers still hold minimal account data, such as billing records, because operating the service requires it.
  • A no-log policy is a claim about retention, not about visibility. A VPN server can still observe your destination IP address, and sometimes your DNS queries and the domain name in your connection’s handshake, while your traffic passes through it.
  • A privacy policy alone is a self-attestation with no external check. The strongest evidence is a real-world legal case where no data was produced under a court order, followed by a current independent audit covering the full server infrastructure, RAM-only server architecture, and a favourable jurisdiction with no mandatory data retention.
  • Private Internet Access, Mullvad, and ExpressVPN have each had a no-log claim tested by a subpoena, search warrant, or server seizure and produced nothing usable. PureVPN and IPVanish both handed over connection records that identified a user despite marketing a no-log policy at the time.

What “No-Log” Actually Means

Not collecting browsing history, DNS queries, or downloaded files is the core of what most people mean by a private VPN. It does not cover everything a VPN server could record, and providers have historically exploited that gap.

The Three Types of Data a VPN Could Record

VPN data falls into three categories, each carrying a different level of privacy risk.

Data typeWhat it includesPrivacy risk
Activity logsURLs visited, DNS queries, files downloaded, application usageHighest. This is the digital record of everything you did online. Reputable providers categorically do not collect this.
Connection metadataLogin timestamps, your original IP address, session duration, server used, bandwidth consumedMedium. These are “quasi-identifiers”: individually innocuous, but combinable through correlation attacks to identify specific users.
Aggregated logsServer load statistics, network performance metrics, regional traffic volumesLow. Collected at a population level and cannot be linked to individual users when handled correctly.

When a VPN provider advertises “no logs,” they almost always mean no activity logs. Connection metadata is the grey zone. Many providers collect some connection metadata for legitimate operational reasons, such as abuse prevention, simultaneous connection limits, and subscription enforcement, but marketing copy rarely specifies this. The relevant question is not whether a provider logs, but which specific data fields it records, and for how long.

The Minimal Data Paradox

A true “zero-log” VPN is a misnomer. Every provider must retain some data to operate as a business: an email address to manage the account, a payment method to process billing, and subscription dates to enforce plan terms. None of this is traffic logging, but it can identify you if a court compels its disclosure.

What’s actually achievable is different from a zero-data claim: no record of your activity, connection details limited in scope and retained only briefly, and clear disclosure of what account information exists and for how long. A provider that lays this out precisely is more trustworthy than one that claims to hold nothing at all.

How a No-Log Provider Enforces Limits Without Keeping Records

No-log providers enforce device limits and prevent abuse using real-time checks rather than historical records, though the specific mechanism varies by provider.

Mullvad documents the mechanism. Each VPN server queries a central service on connection to check the account number, remaining time, and whether the account has reached its device limit. Mullvad states that this validation happens in temporary memory only, with nothing written to disk, and that it cannot report how many connections an account had five minutes earlier.

Some providers also separate the identifier used for billing from the one used for the VPN session itself. Mullvad generates a random account number at signup, with no username, password, or email address required, and stores only the account number and its expiry date, plus, per WireGuard configuration, the account number, public key, and tunnel address. Payment is linked through a token that expires after 20 days for most payment methods, after which it can no longer be traced back to the account. IVPN uses the same approach: a random Account ID generated at signup, with no email or personal information required. In both cases, the account itself is not linked to a real originating IP address, though Mullvad’s WireGuard configuration record does include the assigned tunnel address.

For abuse prevention, Mullvad’s servers report two categories of data to its monitoring system: aggregated application data, such as the total number of current connections, and generic system metrics, such as CPU load and total bandwidth per server. Mullvad logs the sum of each statistic, not individual sessions, to watch for attacks, bugs, and network issues.

Some providers retain a minimal, non-historical datum for these functions. Proton VPN stores a timestamp of the last successful login attempt, which is overwritten on each new login rather than kept as a running history, and uses it to detect credential abuse. This is a single overwritten value, not a retention window with a defined duration.

No Logs Is Not the Same as Not Watching

A VPN server can observe certain metadata while your traffic passes through it, regardless of what it retains afterwards. A no-log policy is a commitment about retention, not a claim that this visibility does not exist.

Three categories of metadata are visible to a VPN server in transit. The destination IP address is unconditionally visible: the server must know where to route your packet, and no encryption scheme changes this. Your DNS queries are visible where the provider itself resolves DNS inside the tunnel, which is the case for providers such as Proton VPN and Mullvad. The TLS Server Name Indication (SNI) field, which names the domain you are connecting to, is visible on connections that do not use Encrypted Client Hello (ECH).

ECH, standardised as RFC 9849 in March 2026, encrypts the SNI field so that an observer cannot read the destination domain from the handshake. Adoption is uneven. Around 59 percent of major browsers support ECH by default, but server-side adoption remains in the low single digits across most of the web outside networks that enable it by default, such as Cloudflare. ECH also requires DNS-over-HTTPS to deliver its configuration keys; without it, the connection falls back to a plaintext SNI. Even where ECH succeeds, the outer handshake names a cover domain, such as Cloudflare’s own domain, so an observer learns which network the connection reached. SNI visibility is decreasing but not eliminated, and it does not affect destination IP visibility, which remains constant regardless of ECH.

A request for records a provider already holds is legally distinct from an order compelling a provider to begin collecting data about a named user going forward. In the United States, this prospective category is authorised under the pen register and trap-and-trace statute (18 U.S.C. §§ 3121 to 3127), which reaches any entity providing electronic communication service whose assistance may facilitate the order’s execution, and which is typically sealed with a non-disclosure requirement. Whether this mechanism has been applied to a commercial VPN provider is not publicly documented; every well-documented VPN legal case is retrospective or a server seizure, not a prospective order. That absence is not strong evidence in either direction, since an order of this type would generally not be made public.

Jurisdiction determines whether such an order is available at all. A jurisdiction can foreclose this category of order entirely through statute, rather than leaving it to a provider’s own policy: Proton VPN, for instance, cites a specific exemption under Swiss law as the basis for its claim that it cannot be compelled to log user data. That kind of statutory protection can still be changed by future legislation, so it is worth checking whether it remains current rather than assuming it is permanent.

Routing traffic through two VPN servers in sequence limits this visibility further: no single server sees both your real IP address and your destination. This protection is strongest when the two servers belong to separate providers. When one company operates both servers, that company can still be compelled or compromised as a single entity, even though no single server holds the complete picture. An adversary that can observe both ends of the chain can also attempt timing correlation, matching traffic entering the first server against traffic leaving the second, regardless of how many hops are used.

The Verification Framework: How to Separate Marketing from Reality

A privacy policy is the weakest form of evidence available. It is a self-attestation: the provider describing their own behaviour, with no external check. The verification methods are ranked from the most externally validated to the most architecturally fundamental. A provider that can point to multiple layers of this framework is more trustworthy than one that can point to only one.

Infographic titled "How to Verify a VPN No-Log Claim" showing a four-tier verification ladder on a dark navy background. From strongest to lightest: a real-world legal test at the bottom, followed by an independent audit, RAM-only server architecture, and jurisdiction plus privacy policy at the top. Each tier is labelled with an icon and a brief description in electric blue and white. A sidebar callout prompts readers to also check for a current transparency report and warrant canary.
Not all no-log claims are equal. Four ways to tell the difference between
a policy and a proof, weighted by how much independent evidence each
represents.

Independent Audits

An independent audit is a structured review of a provider’s infrastructure and data-handling practices by a firm with no commercial relationship to the outcome. In the context of VPN no-log claims, two categories of audit exist, and they are not the same thing.

Formal assurance engagements are conducted by firms such as KPMG and Deloitte under the ISAE 3000 standard, the International Standard on Assurance Engagements issued by the International Auditing and Assurance Standards Board. An ISAE 3000 engagement verifies that a provider’s internal controls and server configurations match the claims made in their published privacy policy. This is the most rigorous form of no-log verification available. SOC 2, the US-based equivalent from the AICPA, covers similar ground but has been used less frequently in published VPN no-log audits, likely because most privacy-focused providers are incorporated outside the United States. Both standards support Type 1 assessments (a point-in-time snapshot) and the more valuable Type 2 assessments (covering a defined period of ongoing operation).

Technical security audits are conducted by specialist firms such as Cure53, Securitum, Leviathan Security Group, and Schellman. These follow the audit firm’s own methodology rather than a formal assurance standard, and typically involve penetration testing, code review, and on-site server verification. They are complementary to formal assurance engagements, probing for vulnerabilities rather than verifying policy compliance, and are often more technically detailed. Cure53, for example, has conducted annual full security audits of TunnelBear since 2017. Securitum conducts annual on-site no-log verification for Proton VPN.

Two caveats apply to any audit regardless of type. First, scope matters: an audit that reviewed a single app or browser extension does not verify server-side behaviour. Before drawing conclusions from an audit report, confirm that the review covered the provider’s full server infrastructure. Second, audits are point-in-time: a passed audit confirms behaviour up to the audit date, not beyond it. Annual or biannual audits are sufficient. A single report from several years ago is not.

How to Read an Audit Report

An audit report should state three things: the standard used, the exact scope of what was reviewed, and any exclusions. ISAE 3000 is principles-based rather than prescriptive, meaning the auditor exercises professional judgement over which controls to test and how, which is why the scope statement matters more for this standard than it would for a checklist-based framework. Where a report uses Type 1 or Type 2 labelling, Type 1 covers the design and existence of controls at a point in time, and Type 2 additionally covers whether those controls operated effectively over a defined period. Not every ISAE 3000 report carries a Type label; a report’s absence of one does not by itself indicate a weaker engagement.

Surfshark’s ISAE 3000 report from Deloitte, published in June 2025, illustrates what a scope and limitations statement looks like in practice: it states that the engagement is a point-in-time assessment, that its procedures provide no assurance for any other point in time, that later modification of the system may change the conclusion, and that the procedures do not constitute a financial audit or an opinion on legal compliance. A report that omits this kind of limiting language is not necessarily untrustworthy, but a report that includes it is giving the reader an honest account of what was and was not tested.

Transparency Reports

A transparency report is a periodic disclosure by the provider detailing the legal requests they received during a given period: how many were received, how many were complied with, and in how many cases no responsive data existed. The third category is the strongest evidence: a provider that routinely reports “zero data available to produce” in response to legal requests is demonstrating its no-log policy in operation, not just in policy.

Transparency reports vary in frequency and detail. Quarterly reports are more useful than annual ones. Reports that specify the nature of requests (subpoena, court order, law enforcement request) and the jurisdiction are more useful than those that report only totals. A provider that publishes no transparency report at all, particularly one operating in a jurisdiction with strong legal compulsion tools, is providing less assurance than its privacy policy implies.


Warrant Canaries

A warrant canary is a standing public statement that a provider has received no secret government orders: no gag orders, no national security letters, no sealed court orders, as of a specified date. The mechanism works in reverse: the canary is updated regularly as long as the statement remains true. If it disappears, or if the update stops, that signals something has changed.

Warrant canaries are a useful signal but not a guarantee. Their legal enforceability varies by jurisdiction. In the United States, courts have not definitively ruled on whether removing a canary constitutes protected speech or an impermissible act of defiance of a gag order. Treat a current, regularly updated canary as a positive indicator, and treat its absence or sudden disappearance as a reason to look more closely. Do not treat it as equivalent to a passed audit or a verified legal test.

RAM-Only Servers

RAM-only (diskless) servers represent a shift from policy to architecture. Rather than committing not to store data, a RAM-only server is physically incapable of retaining data across a reboot. The entire operating system and all session data run in volatile RAM. When power is cut, whether by a scheduled wipe, a routine maintenance reboot, or a physical server seizure, all data in memory is lost. Post-seizure forensic recovery is effectively impossible under normal operating conditions.

Software-based log deletion can be circumvented, audited retrospectively, or subjected to a legal hold order requiring preservation. Hardware-level non-retention removes the data before any legal process can reach it. There is nothing to compel production of because nothing persists.

The protection depends on correct implementation, and several configuration requirements and residual risks apply. The full technical detail is in What Is a RAM-Only VPN Server.

RAM-only infrastructure requires a full server rebuild; it is not a software switch. Implementing it at scale is a deliberate operational commitment, which is why it carries weight as a verification signal.

Verification methodWhat it provesKey limitation
Formal assurance audit (ISAE 3000)Policy matched infrastructure at audit datePoint-in-time; not a continuous guarantee
Technical security auditInfrastructure withstood external technical scrutinyMethodology varies by firm; scope may be limited
Transparency reportHow the provider responded to real legal requestsOnly covers disclosed requests; detail varies
Warrant canaryNo secret orders received as of the canary dateLegal status complex; disappearance is the only signal
RAM-only serversHardware-level data non-retention; forensic non-recoverabilityRequires correct configuration; no protection during live seizure

How to Verify a No-Log Claim Yourself: A Seven-Step Check

The verification framework can be reduced to a short, ordered check you can run on any provider in one sitting.

  1. Read the data-fields list in the privacy policy. Pass: specific fields named as not collected, such as IP address, DNS queries, and timestamps. Fail: vague language such as “minimal logging” with no enumerated fields.
  2. Locate the most recent independent audit report. Pass: dated within the last eighteen months. Fail: no audit, or one older than three years.
  3. Check the audit’s scope statement. Pass: covers the full server infrastructure. Fail: covers only the client application or website.
  4. Check whether the report uses Type 1 or Type 2 labelling, where applicable. Pass: Type 2, covering a period of operation. Weaker but not disqualifying: Type 1 only, a single point in time.
  5. Check for a transparency report. Pass: published regularly, with request counts broken down by type and jurisdiction. Fail: none published, especially from a provider in a jurisdiction with strong compulsion tools.
  6. Check the warrant canary’s last update, if the provider publishes one. Pass: updated on schedule. Fail: stale, or recently removed with no explanation.
  7. Search for documented legal cases involving the provider. Pass: a case where a request was made and no usable data existed. Fail: a case where the provider produced identifying records. A clean search does not prove a provider has never received a request; court records for prospective compulsion orders are typically sealed, and free tools such as CourtListener and the PACER Case Locator cover only US federal courts.

The highest-yield step is the third: an audit that never reviewed the server infrastructure cannot support a no-log claim, regardless of what else it found.

What a VPN Server Records by Default

A VPN server does not start in a no-log state by default. Each layer, the daemon, the operating system, and the kernel, records something until it is deliberately configured not to.

OpenVPN‘s own default verbosity is level 1, which does not produce the itemised session data sometimes attributed to it. Verbose connection records instead come from the status file, a separate feature controlled by the --status and --status-version options. A version 2 status file lists the client’s real IP address, the assigned tunnel address, bytes sent and received, and connection time. On Debian and Ubuntu, the systemd unit that starts the OpenVPN service enables this status file, not OpenVPN’s own defaults; a default apt install openvpn server therefore does produce it. The file is rewritten on an interval rather than appended, and under the modern systemd unit it is stored in a memory-backed location that does not survive a reboot. It is a current-state snapshot, not a historical log, but it does hold identifying information while the server is running.

WireGuard takes a different approach at the daemon level. Its kernel module produces no logging output unless a system administrator explicitly enables kernel debugging. This differs from OpenVPN’s packaged status file. It does not mean WireGuard holds nothing: running wg show at any time reveals each peer’s public key, its real endpoint IP address and port, the time of its last handshake, and bytes transferred. This is live, in-memory state rather than a file on disk, but it includes the same real IP address that a status file would show, and is readable by anyone with access to the server.

These records exist independently of the VPN daemon’s own settings, at the operating system level. On systemd-based Linux distributions, the system journal (journald) can store daemon output persistently regardless of what the VPN application itself is configured to log. Storage mode is controlled by the Storage setting in journald.conf. Current systemd builds commonly default to persistent storage, writing to disk, rather than the volatile-until-a-directory-exists behaviour that older documentation describes. Because the default is set when systemd is compiled, it varies by distribution and version; the journalctl --header command shows whether a given server’s journal is stored on disk or in memory.

Kernel-level connection tracking (conntrack, part of Linux’s netfilter subsystem) is a separate, transient category from either of the above. It maintains an in-memory table of active connections, sized according to available system memory, with entries expiring on a per-protocol timeout. Logging of invalid packets through this system is disabled by default. Nothing is written to disk by conntrack itself, and the table is lost on reboot. An idle but still-established TCP connection can remain in the table for up to five days before expiring, though a connection that closes normally expires within seconds. This is kernel state with a long idle ceiling, not a persistent log.

A no-log server configuration requires three independent steps, because each layer above is controlled separately. Reducing OpenVPN’s verbosity alone does not remove the status file. Removing the status file alone does not silence the operating system journal. On Debian and Ubuntu specifically, the status file is set by the systemd unit’s own start command, so editing the OpenVPN configuration file alone will not remove it; removing it requires overriding the systemd unit itself.

This is also why an audit’s server-infrastructure scope matters as much as its existence. A review that examined only the client application has no way to confirm which of these layers, if any, were correctly configured on the servers actually handling user traffic.

When the Claim Has Been Tested: Real-World Legal Cases

The most reliable verification of a no-log policy is not an audit. It is a law enforcement request that returns nothing. When a government agency subpoenas a provider, seizes a server, or obtains a court order compelling disclosure, and the result is confirmation that no user data exists, that is a real-world test under adversarial conditions. No audit can replicate it.

Claims That Held Up

Private Internet Access (PIA) has been validated in two separate legal proceedings. In 2016, the FBI subpoenaed PIA in connection with a bomb threat investigation targeting schools and an airport. PIA was able to confirm only that the IP cluster used originated from the east coast of the United States and provide information about available payment methods. No user activity data existed to produce. In 2017, PIA was subpoenaed again during a federal hacking investigation in San Jose, California. PIA’s general counsel testified during the subsequent trial proceedings that no subscriber records matching the suspect’s identifiers existed in PIA’s systems. The defendant was prosecuted on other evidence. Both cases are a matter of public court record.

Mullvad VPN was subject to a physical law enforcement operation in April 2023, when Swedish National Operations Department officers arrived at Mullvad’s Gothenburg office executing a search warrant. The warrant originated from a European Investigation Order issued by German authorities in connection with a 2021 cyberattack targeting municipal institutions in Mecklenburg-Western Pomerania. Officers intended to seize computers containing customer data. Mullvad demonstrated that no such data existed on any of its systems. After consulting the prosecutor on-site, police left without taking anything and without any customer information. Mullvad confirmed this was the first search warrant the company had received in its fourteen-year history, and that even if servers had been taken, no customer data would have been on them.

ExpressVPN had a server physically seized by Turkish authorities in January 2017, in connection with an investigation into who deleted the Gmail and Facebook accounts and conversations of the assassin of the Russian ambassador in Ankara, off-duty police officer Mevlüt Mert Altıntaş, in what Turkish investigators characterised as an attempt to destroy evidence. The seizure yielded no useful user information. ExpressVPN confirmed to Turkish investigators that it holds no connection logs or activity logs. ExpressVPN subsequently stopped using physical servers in Turkey.

Claims That Collapsed

Not every no-log claim has survived contact with legal pressure.

PureVPN cooperated with an FBI investigation in 2017 that resulted in the arrest of a Massachusetts man for cyberstalking. The FBI complaint details that PureVPN provided connection logs showing that the provider’s service had been accessed by the same customer from two originating IP addresses, the suspect’s home internet connection and his employer’s network. This was sufficient to link VPN usage to the individual. PureVPN’s marketing at the time stated “we do not keep logs of your activities.” The fine print of its privacy policy, however, did reference collection of IP addresses and connection timestamps. PureVPN had been collecting connection metadata all along, and advertising a no-log policy that its own privacy policy did not fully support. This case demonstrates the gap between activity logs and connection metadata: the provider never claimed not to keep connection metadata, but marketed broadly as a no-log service. PureVPN subsequently commissioned a KPMG audit in 2020 to verify its revised policy.

IPVanish provided subscriber information and connection and disconnection timestamps to the US Department of Homeland Security in 2016 during an investigation involving child exploitation material. IPVanish’s homepage at the time advertised a “strict zero-logs policy.” The data provided was sufficient to identify the suspect. IPVanish changed ownership in 2017 and has since completed independent no-log audits with Leviathan Security Group (2022) and Schellman (2025). The current operator’s policy and the independently verified policy post-2017 are a separate matter from the 2016 failure, but the original case remains a documented instance of a no-log claim that did not hold under legal pressure.

Both cases illustrate the same lesson: the relevant question is not what a provider’s privacy page says, but what data fields are specifically listed as not collected, and whether an independent third party has verified the technical implementation of that claim.

Jurisdiction and the Legal Ceiling of Privacy

A provider’s jurisdiction determines the legal environment it operates within: the data retention laws it must comply with, the intelligence agencies that can compel disclosure, and the international cooperation frameworks it is subject to. Jurisdiction sets a ceiling on what privacy a provider can offer, regardless of its intentions.

The Five Eyes, Nine Eyes, and Fourteen Eyes Alliances

The intelligence-sharing alliances relevant to VPN jurisdiction are structured in three tiers: Five Eyes (US, UK, Canada, Australia, New Zealand), Nine Eyes (adds Denmark, France, the Netherlands, and Norway), and Fourteen Eyes (adds Germany, Belgium, Italy, Sweden, and Spain). For the full history, formal versus informal treaty status, and what each alliance operationally does, see 5/9/14 Eyes Alliance Explained.

The practical implication for VPN users: a provider incorporated in a Fourteen Eyes country operates within a legal environment where intelligence agencies from up to fourteen governments may have compulsion tools available, and where data shared with one agency may flow to others. This is the ceiling. A provider with no data to produce is less affected by this ceiling than one that retains connection metadata.

Jurisdictions With No Mandatory Data Retention

British Virgin Islands is a favourable jurisdiction. The BVI Data Protection Act 2021 is an EU-style data protection law that actively requires data not be kept longer than necessary, reinforcing rather than conflicting with a no-log policy. There are no telecommunications-specific data retention mandates. Any foreign government request for data must pass through the BVI High Court, requiring dual criminality and a high evidentiary standard. The BVI is not a member of any intelligence-sharing alliance.

Switzerland does not currently impose mandatory data retention obligations on VPN providers. The revised Federal Act on Data Protection (nFADP), effective since September 2023, emphasises data minimisation and purpose limitation without imposing retention requirements, and VPN providers have not been classified as telecommunications carriers under the Telecommunications Act’s retention rules. Proton VPN states that it is registered under a specific exemption to Switzerland’s surveillance ordinance (VÜPF), Article 21, paragraph 2, and that under current Swiss law it cannot be compelled to log user data, a status distinct from how Swiss law treats Proton Mail. A proposed revision to that ordinance would extend monitoring and retention obligations to VPN providers above roughly 5,000 users. As of February 2026, the Federal Council had not proceeded with the revision, having ordered a risk impact assessment and a second public consultation. Switzerland’s status as a favourable jurisdiction is current but under active legislative review.

Panama is widely cited as a favourable jurisdiction, and several major providers are incorporated there. The situation requires qualification. Panama’s Law 51 of 2009 requires telecommunication service providers to retain connection metadata for six months. Whether VPN providers fall within the statute’s definition of a telecommunication service provider is a matter of ongoing legal interpretation: a Panamanian law firm has published analysis arguing they may be covered, and the district attorney’s office has reportedly been processing international information requests directed at Panama-incorporated VPN providers. No published case has yet compelled a Panama-based VPN provider to surrender logs, and major providers incorporated there have passed multiple independent audits. Panama cannot be characterised as unambiguously retention-free, however.

Iceland lacks mandatory data retention laws applicable to VPN providers. As a member of the European Economic Area but not the EU, Iceland was not subject to the EU Data Retention Directive. Iceland participates in NATO and has some international cooperation arrangements, but has no data retention framework that would oblige a VPN provider to store user metadata.

Architecture Over Geography

Jurisdiction matters, but it is not the only variable. The strongest counter-argument to jurisdiction-focused analysis is architectural: if a VPN provider cannot store data, through RAM-only servers, strict no-log implementation, and no account data beyond payment processing, then its physical location becomes less relevant. There is no data to compel production of. A court order directed at a provider with nothing to produce returns nothing, regardless of the jurisdiction that issued it.

Jurisdiction sets the legal ceiling. Architecture determines whether there is anything under that ceiling within reach. A provider in a favourable jurisdiction with poor technical implementation is less trustworthy than a provider in a less favourable jurisdiction with verified RAM-only infrastructure and multiple passed audits. Assess both dimensions, and weight the technical implementation more heavily when the audit record is strong. For the mechanics of how that connection is built and what it protects, see what a VPN tunnel is.

How to Read a Privacy Policy

Reading a privacy policy well means knowing what to look for and what to treat as a warning sign.

Green Flags in a Privacy Policy

  • Specific data fields listed as explicitly not collected, not vague assurances like “we don’t log browsing activity,” but enumerated field-level commitments (“we do not store originating IP addresses, DNS queries, connection timestamps, or bandwidth usage per user”)
  • A linked audit report dated within the last eighteen months, with the scope of the review clearly stated
  • Explicit retention periods for account data: how long your email address, payment records, and subscription dates are held
  • A jurisdiction with no mandatory data retention laws applicable to VPN providers
  • Acceptance of anonymous payment methods (Monero is the strongest example; providers including Mullvad and IVPN accept it directly with no email required)
  • A documented real-world legal test where no data was produced in response to a law enforcement request
  • A regularly updated transparency report

Red Flags in a Privacy Policy

  • Vague qualifiers. Phrases like “minimal logging for service quality,” “technical data only,” or “aggregate information to improve performance” define no scope and create no enforceable commitment. They are placeholders, not policies.
  • No audit, or an outdated one. An audit older than three years, or an audit that covered only a mobile app rather than the server infrastructure, provides limited assurance about current server-side behaviour.
  • “We do not sell your data.” This says nothing about what is collected. A provider can collect extensive metadata and never sell it to anyone, while still retaining it in a form that is accessible to law enforcement.
  • No transparency report and no warrant canary. Having one or the other is acceptable; having neither is a gap a thoughtful privacy policy would not leave unaddressed.
  • A free VPN with no clear revenue model. VPN infrastructure is expensive to operate. If the service is free and there is no subscription revenue, the business model requires scrutiny. Data monetisation is the most common answer to this question in the free VPN market. A privacy policy from a free provider that offers no clear explanation of how the service is funded warrants scepticism.
  • Infrequent policy updates with no changelog. A provider that manages its no-log commitments will update its privacy policy as its practices evolve and note what changed. A policy that has not been touched in years, particularly one that predates any audit, is likely not being actively maintained.

Signing Up Without Identifying Yourself

Mullvad and IVPN both allow signup with no email address, using a randomly generated account number as the sole identifier. Mullvad currently accepts cash, Bitcoin, Bitcoin Cash, Monero, bank wire, credit card, PayPal, and Swish, and runs its own cryptocurrency nodes rather than relying on a third party. For Bitcoin and Bitcoin Cash, Mullvad stores the receiving address generated for that payment, removed after 20 days. For Monero, Mullvad retains the transaction hash beyond that 20-day period to prevent the same payment being credited twice, so Monero is not a payment method that leaves no trace at all, only one that leaves no identifying trace. IVPN accepts Bitcoin, Bitcoin Lightning, Monero, PayPal, most credit and debit cards, in-app purchases, and physical or digital vouchers, and also runs its own nodes for Bitcoin and Monero. Neither provider’s current payment method list includes Ethereum, Litecoin, or Dogecoin.

Where This Framework Applies and Where It Changes

The verification framework assumes a commercial consumer VPN, which covers most readers. Four related situations change the analysis: free VPNs, self-hosted VPNs, corporate VPNs, and high-risk use.

Free VPNs

A free VPN with no subscription revenue carries a different default risk than a paid one, because the infrastructure still has to be funded somehow. In July 2020, research led by Noam Rotem at vpnMentor found an unsecured database shared by seven Hong Kong-based VPN providers marketed as no-log services: UFO VPN, FAST VPN, Free VPN, Super VPN, Flash VPN, Secure VPN, and Rabbit VPN. The exposure totalled 1.2 terabytes across more than one billion log entries, including browsing records, plaintext passwords, IP addresses, and payment information, potentially affecting users of services that claimed over 20 million users combined, a figure from the providers’ own marketing rather than independent verification. UFO VPN disputed the anonymisation characterisation of its data and attributed the exposure to pandemic-era staffing changes; a December 2025 statement from UFO VPN claims VPN logging has since been fully disabled on both server and client sides, though this has not been independently verified.

The business-model reasoning behind this incident is sound, but it does not make “free VPNs log” a safe generalisation. Proton VPN’s free tier is covered by the same no-logs policy and the same externally audited scope as its paid service, and is subsidised by paid subscriptions rather than by data. The more accurate statement is about incentive, not category: a provider with no subscription revenue must fund the service somehow, and the historical record shows that has often meant data.

Self-Hosted VPNs

In a self-hosted VPN, you are the log operator: you set the logging policy, and there is no external provider whose logs could be requested. This adds and relocates jurisdictional exposure rather than removing it. Up to three jurisdictions can apply to a rented server: the country where the datacentre physically sits, the country where the hosting company is incorporated, which can differ and can still reach the same data, and your own jurisdiction as the operator, which applies to you personally regardless of where the server is. Cross-border requests between these typically run through mutual legal assistance treaties, which add delay rather than immunity. For the full breakdown of home-hosted versus VPS-hosted deployments and what each does and does not protect, see what a self-hosted VPN is.

Corporate and Business VPNs

Corporate VPN deployments commonly log deliberately, for compliance and incident response, which is a different purpose from a consumer no-log expectation rather than a failure of one. The Payment Card Industry Data Security Standard’s Requirement 10 mandates logging of access to cardholder data with at least 12 months of retention, but only for systems in scope of the cardholder data environment, not automatically for every corporate VPN. The HIPAA Security Rule requires audit controls for systems handling protected health information. SOC 2’s monitoring criteria are commonly satisfied through a centralised logging pipeline with defined retention. These logs exist so that an incident responder can reconstruct who connected from where and when, the exact capability a consumer no-log VPN is designed to prevent.

High-Risk Use

For journalists, activists, and others facing a state-level adversary, a single commercial no-log VPN is not sufficient on its own, and the recommended response is to identify the specific threat before choosing a tool rather than to layer VPN configurations. Freedom of the Press Foundation frames a VPN as one tool among several, most useful for specific tasks such as sensitive research where a newsroom’s IP address visiting a target’s website is itself a signal, and recommends starting by identifying the most sensitive data and who it needs protection from. For communications requiring stronger anonymity than a VPN provides, Tor uses three independently operated relays and a larger anonymity set than any single VPN. The Tor Project’s own documentation states that it generally does not recommend combining a VPN with Tor unless the user is advanced enough to configure both without compromising privacy, since a misconfigured combination can reduce anonymity rather than increase it. A no-log VPN alone is a reasonable choice against jurisdiction-limited legal demands and opportunistic monitoring; it is a starting point, not a ceiling, against a state-level adversary.

Frequently Asked Questions

What does no-log mean on a VPN?

“No-log” is a claim, not a fixed technical standard, so what it actually excludes varies by provider until you check the specifics. The reliable test is whether the policy names exact data fields it does not collect, browsing destinations, DNS lookups, timestamps, bandwidth, rather than offering a blanket assurance. A policy that lists precise categories is making a checkable claim; one that just says it “respects your privacy” is not.

Can a VPN be truly no-log?

Not in an absolute sense. Running a VPN as a business requires keeping some record to manage billing and accounts, so “zero data of any kind” is not realistic for any legitimate provider. What is achievable is zero record of what you actually did online, combined with a clearly bounded and disclosed set of account details retained only as long as needed. Judge a provider by how precisely it draws that boundary, not by whether it claims to hold nothing at all.

How do I know if my VPN keeps logs?

Read the privacy policy, looking for specific field-level commitments rather than broad assurances. Then verify: look for a current independent audit with full server infrastructure scope, check whether the provider publishes transparency reports, and search for any documented legal cases where the provider was asked to produce data. A provider that has passed a formal ISAE 3000 assurance engagement and has a real-world legal test on record is giving you two independent sources of confirmation.

Does a no-log VPN protect me from law enforcement?

A no-log VPN protects you from law enforcement disclosure only insofar as there is no data to disclose. If a provider holds no activity logs, no connection metadata, and no account data beyond what is needed for billing, and that is independently verified, then a law enforcement request returns nothing. The cases of Private Internet Access and Mullvad VPN demonstrate this outcome under real conditions. The cases of PureVPN and IPVanish demonstrate what happens when the technical implementation does not match the marketing claim. The policy is only as protective as the data architecture behind it.

What is a VPN audit?

It is an independent check confirming that a provider’s servers behave the way its privacy policy claims, rather than taking the policy on faith. Some audits are formal compliance engagements against a recognised standard; others are hands-on penetration tests carried out by security firms. Either kind is only as good as its scope and age: one that only examined a mobile app, or one that is several years old, says little about what the servers are actually doing today.

Is a VPN in a 14 Eyes country safe?

Being in a Fourteen Eyes country is a disadvantage, not a disqualifier. It means the provider’s home government has intelligence-sharing partnerships it could lean on if it ever sought user data, exposure that a provider outside those alliances does not have. But a well-audited, RAM-only provider based in a Fourteen Eyes country can still be more trustworthy in practice than an unaudited provider sitting in a nominally safer location. Where a provider is incorporated is one input, not the whole answer.

Can a no-log VPN still see my traffic?

Some of it, yes, for as long as it is passing through the server. Encryption protects the contents of your traffic, but the server still has to read the destination address to deliver your request, and depending on the setup it may also see which domain you are reaching or handle your DNS lookups. None of that contradicts a no-log policy on its own; it only becomes a problem if the provider writes any of it down.

Do free VPNs keep logs?

Often, yes, and free VPNs have the worst track record here. Running server infrastructure costs money, and a service with no subscription income has to fund itself somehow, historically that has meant selling or mishandling user data. A small number of free tiers are the exception, offered as extensions of an already-audited paid product rather than standalone free apps. Treat “free” as a prompt to check how the provider actually makes money, not as an automatic disqualifier.

Can a court force a VPN to start logging a specific user?

In some jurisdictions, this is legally possible in theory: an order compelling a provider to start capturing data on a specific target, separate from simply demanding records that already exist. No public case confirms this has actually happened to a commercial VPN provider, though that is not strong evidence either way, since orders like this typically come with a gag provision that would keep it out of view. It is a real category of legal exposure, just one without a documented precedent in this industry so far.

Summary: How to Evaluate a No-Log Claim

A no-log claim can be evaluated using four indicators, weighted by how much independent evidence each represents.

  1. Passed a real-world legal test with no data produced. A law enforcement request that returned nothing is the strongest validation available. It is adversarial, independent, and documented.
  2. Current independent audit with full infrastructure scope. An ISAE 3000 or SOC 2 assurance engagement, or a comprehensive technical audit by a specialist firm, completed within the last eighteen months and covering the provider’s complete server infrastructure.
  3. RAM-only server architecture. Hardware-level data non-retention that makes post-seizure forensics effectively impossible when correctly implemented.
  4. Favourable jurisdiction with no mandatory data retention. A legal environment that does not undermine the provider’s technical commitments through compulsion.

A provider that claims a no-log policy but cannot point to any of these four indicators is asking for trust with no independent evidence behind it.