How Independent Audits Actually Verify a VPN’s No-Log Claims
Every VPN provider says the same three words: “we don’t log.” It’s printed on the homepage, repeated in the FAQ, and recited by support agents like a mantra. The problem is that a marketing claim and a verified fact are not the same thing, and the gap between them is exactly where a privacy-conscious buyer can get burned. At Tedony, we spend a disproportionate amount of our review time on one question: how do we know this claim is actually true? The answer, increasingly, comes down to independent audits — and understanding how those audits actually work is the difference between trusting a badge and trusting the evidence behind it.
Why “No-Log” Needed a Verification Industry in the First Place
The no-log promise became a competitive necessity around the mid-2010s, once VPNs pivoted from being a niche corporate tool to a mainstream privacy product. Every provider adopted the language, but the language alone protected no one. Several high-profile incidents — court orders that produced connection logs from providers who swore they kept none, and law-enforcement requests that revealed retained IP addresses — made it clear that self-declared policies were unenforceable without outside scrutiny.
That’s the vacuum independent audit firms stepped into. Companies like Cure53, Deloitte, PricewaterhouseCoopers (PwC), KPMG, and smaller specialist security firms began offering formal engagements specifically scoped to test whether a VPN’s technical infrastructure matches its written privacy policy. This is not a rubber stamp; it is a structured, methodical process, and understanding its stages tells you exactly what a “no-log audit” badge on a homepage should and shouldn’t mean to you.
Stage One: Policy-to-Architecture Mapping
The audit doesn’t start with servers. It starts with paperwork. Auditors first read the provider’s published privacy policy line by line and translate every claim into a testable technical statement. “We do not store connection timestamps” becomes a specific question: does any logging daemon, database, or configuration file on any production server capture and persist a timestamp field tied to a user session?
This mapping stage matters because vague policy language is a common evasion tactic. A policy that says “we do not log your browsing activity” says nothing about connection timestamps, bandwidth totals, or device fingerprints — all of which could still be retained while the letter of that sentence remains technically true. A rigorous audit calls out this ambiguity explicitly, and a provider that welcomes the scrutiny will usually tighten its policy language as a direct result of the audit findings.
Stage Two: Server-Level Configuration Review
Once the claims are mapped, auditors typically request either remote access or, in stronger engagements, physical or supervised access to a sample of production servers. They examine:
- Logging daemons and system-level configs — checking whether syslog, journald, or custom logging services are writing connection metadata to disk.
- Database schemas — inspecting whether any database table includes fields for IP address, session duration, DNS query history, or bandwidth consumption tied to individual accounts.
- RAM-disk versus persistent storage setups — confirming whether servers boot from a read-only image into volatile memory (RAM-only) or whether they run from a traditional hard drive that would retain data through a reboot.
- Third-party monitoring tools — many VPNs use external services for uptime monitoring or load balancing, and auditors check whether those integrations quietly introduce data retention the provider itself doesn’t control.
This is the part of the process most people picture when they hear “audit,” but it’s also the most limited by scope. Auditors sample servers; they cannot inspect every node in a global network of a thousand-plus machines within a two-week engagement. That’s a genuine limitation worth sitting with, not glossing over — a snapshot audit tells you the sampled servers were clean at that moment, not that every server will remain clean forever.
Stage Three: Interviews and Process Review
Technical configuration is only half the story. Auditors also interview engineering staff, review internal documentation and change-management logs, and check whether the company has formal procedures preventing a future engineer from accidentally (or under legal pressure) re-enabling logging. A no-log architecture that depends entirely on the goodwill of the current CTO is fragile; a no-log architecture backed by documented, auditable deployment pipelines is durable.
This is also where auditors probe governance questions that matter enormously in practice: who has root access to production servers, how is that access rotated, and is there a paper trail if a government agency compels a change? A provider based in a jurisdiction with strong data-protection law and a demonstrated history of fighting subpoenas (rather than quietly complying) adds a second, independent layer of assurance on top of the technical audit.
The Report: What “Passing” Actually Means
At the end of the engagement, the audit firm issues a report — sometimes public, sometimes only summarized publicly with the full document available under NDA to select journalists. A strong report will:
- List the exact scope of servers, jurisdictions, and systems reviewed.
- State the audit window (a specific date range, not an open-ended claim).
- Detail any findings, including minor ones, rather than presenting a spotless result with no visible methodology.
- Include a remediation section showing what the provider fixed in response.
Be skeptical of any “audit” that produces only a press release quote with no accompanying document. A provider genuinely confident in its result has every incentive to publish the underlying report, at least in redacted form. The absence of a document, paired with heavy marketing language about “military-grade” verification, is itself a signal worth weighing.
Repeat Audits Matter More Than the First One
A single audit is a photograph of a moment in time. Infrastructure changes constantly — new servers are added, new features ship, new third-party tools get integrated. The providers we trust most at Tedony are the ones that commission repeat audits on a recurring cadence (annually, or after any major infrastructure change) rather than treating one audit as a permanent trophy. When a company’s homepage still cites an audit from four years ago with nothing since, that’s a legitimate reason to pause and ask why.
What This Means When You’re Comparing VPNs
When you’re evaluating a no-log claim, look past the badge and ask three concrete questions: Who performed the audit, and are they a recognized security firm with a track record outside the VPN industry? Is the full report available, and when was it dated? Has the company repeated the process, and did the second report show meaningful changes from the first?
None of this makes an audit a perfect guarantee — no external reviewer can watch a server twenty-four hours a day, and legal compulsion under a gag order is a scenario no audit can fully rule out. But a well-scoped, recent, published, and repeated audit is meaningfully stronger evidence than a policy page alone, and it’s the closest thing the industry currently has to real accountability. That’s the bar we hold every provider to in our reviews, and it’s the bar we’d encourage you to hold them to as well.
The Difference Between a Privacy Audit and a Security Audit
One source of confusion we run into constantly is that “audit” gets used as a catch-all term for two genuinely different engagements. A security audit (sometimes called a penetration test) looks for vulnerabilities — can an attacker break the encryption, hijack a session, or exploit a bug in the client app? A privacy or no-log audit asks a completely different question — does the infrastructure retain the kind of data the policy says it doesn’t? A provider can pass a rigorous security audit with flying colors while never having submitted to a proper no-log verification at all, and marketing copy frequently blurs the two together so that a security pentest badge gets read by consumers as proof of a no-log claim it was never designed to test.
When you’re reading a provider’s audit history, separate these explicitly. Look for the specific scope statement in the report itself — most reputable firms state clearly at the top of the document whether the engagement covered infrastructure logging practices, application code vulnerabilities, or both. If the scope section only discusses code quality and vulnerability classes with no mention of servers, logging pipelines, or data retention, that audit says nothing about the no-log claim, regardless of how it’s referenced on the homepage.
What Happens Between Audits
An audit is a snapshot, and the gap between snapshots is where things can quietly drift. A responsible provider treats an audit finding as the start of an ongoing internal process, not a box checked once and forgotten. This typically shows up as internal policies requiring security review before any new logging-adjacent feature ships — for example, before adding a new customer support tool, a new load-balancing service, or a new analytics integration, engineering teams are required to check whether it touches connection-level data and, if so, route the decision through the same privacy review that shaped the original no-log architecture.
Some of the more mature providers in this space have started publishing not just audit reports but ongoing “bug bounty” programs specifically scoped to logging and data-retention issues, inviting independent researchers to look for gaps between audit cycles rather than waiting a full year for the next scheduled engagement. This kind of continuous scrutiny is still rare, but it’s a meaningfully stronger commitment than an annual audit alone, and it’s a detail worth checking for when a provider is trying to distinguish itself on privacy specifically rather than on speed or price.
A Practical Checklist for Reading Any Audit Report
Given how much variation exists between audit engagements, we’ve found it useful to work through the same short checklist every time a new report crosses our desk at Tedony:
- Is the auditing firm named, and does it have a track record of similar engagements outside the VPN industry?
- Does the report explicitly state it covered infrastructure and data-retention practices, not just application security?
- Is the sample of servers reviewed disclosed, including how many and in which regions?
- Is there a clear date range for the engagement, and has it been repeated since?
- Are findings and remediations documented in detail, rather than a single unqualified “pass” statement?
A report that clears all five of these checks is meaningfully more trustworthy than one that clears only one or two, even if both providers describe themselves as “independently audited” in identical marketing language. The work of actually reading the report, rather than the badge, is where real due diligence happens — and it’s exactly the kind of detail we dig into every time we publish a review.