Ask a VPN provider how it protects user privacy, and the answer usually arrives in one of two forms: a link to a privacy policy, or a link to an audit report. Both documents matter, but they answer entirely different questions, and treating either one as a complete substitute for the other is a common source of confusion for consumers trying to evaluate a provider’s trustworthiness. This report untangles what each document actually promises, where the two overlap, and where dangerous gaps can hide between them.
What a Privacy Policy Actually Is
A privacy policy is a legal document. Its primary function is to describe, in terms that satisfy regulatory requirements (GDPR, CCPA, and similar frameworks depending on jurisdiction), what data a company collects, how it’s used, how long it’s retained, and what rights users have over it. Crucially, a privacy policy is a statement of intent and commitment, drafted by legal counsel, and it is enforceable primarily through regulatory and contractual mechanisms — not through independent technical verification.
This means a privacy policy can be entirely accurate and legally sound while still leaving open questions that only a technical audit can answer: does the infrastructure actually behave the way the policy describes? Is there a gap between what legal has written and what engineering has implemented?
What a Security Audit Actually Is
A security audit, by contrast, is a technical verification exercise. It doesn’t ask what a company intends to do — it examines what the company’s systems are actually configured to do, based on direct inspection of code, infrastructure, and process. An audit can confirm (or contradict) specific claims made in a privacy policy, but it typically doesn’t address legal enforceability, regulatory compliance across jurisdictions, or what happens if the company is later acquired, relocates, or receives a legal order it must comply with.
Where the Two Documents Overlap — and Where They Don’t
| Question | Answered by Privacy Policy | Answered by Security Audit |
|---|---|---|
| What data does the company say it collects? | Yes | Partially, via infrastructure review |
| Does the infrastructure actually match that description? | No | Yes |
| What are the company’s legal obligations if subpoenaed? | Partially | No |
| Are there exploitable vulnerabilities in the app or servers? | No | Yes |
| What jurisdiction governs data requests? | Yes | No |
The Jurisdiction Problem Neither Document Fully Solves
A provider’s privacy policy can promise not to log user activity, and an audit can technically confirm that the current infrastructure doesn’t do so — but neither document can guarantee what happens if the company is later compelled by a court order, a change in corporate ownership, or a shift in the legal environment of the jurisdiction it operates from. This is why jurisdiction remains a meaningful third factor alongside policy and audit: a provider headquartered somewhere with strong data protection law and no mandatory data retention requirements has a structurally different risk profile than one operating under a legal regime that can compel logging regardless of what the company’s own policy says.
Some providers address this through warrant canaries — regularly updated statements confirming that no secret legal order has been received. A missing or stale warrant canary update is sometimes (though not always) a meaningful signal, though the mechanism itself has legal limitations and isn’t recognized in every jurisdiction.
Where the Gap Between Policy and Practice Tends to Appear
In practice, the most common gaps between a privacy policy’s promises and a provider’s actual technical practice tend to show up in a handful of predictable places:
- Support and billing systems — customer service platforms and payment processors often retain identifying information (email, IP address at signup, billing details) that falls outside the scope of a “no activity logs” claim but is still personal data worth understanding.
- Crash reporting and analytics SDKs — mobile and desktop apps sometimes bundle third-party analytics or crash-reporting libraries that transmit device identifiers or usage data to external services, independent of the core VPN tunnel’s logging practices.
- Third-party server hosting — a provider may not log user data itself, but if servers are rented from a third-party data center operator, that operator’s own logging practices (at the network or hypervisor level) fall outside the VPN provider’s direct control and often outside audit scope entirely.
- Aggregated operational metrics — data used for capacity planning or abuse prevention, even when anonymized, can sometimes be re-identified if retained alongside other metadata, a subtlety that a plain-language privacy policy rarely addresses in technical detail.
How to Evaluate a Provider Using Both Documents Together
A reasonably thorough evaluation looks at four things side by side: what the privacy policy promises, what the audit report technically verifies, which parts of the infrastructure fall outside the audit’s stated scope, and what jurisdiction and corporate structure govern the company. When all four align — a clear policy, a recent audit with a broad scope, no significant unaddressed gaps, and a jurisdiction with reasonable legal protections — that combination represents a meaningfully stronger trust signal than any one document alone.
A privacy policy tells you what a company promises. An audit tells you what its systems currently do. Neither one tells you what happens next.
Practical Questions for Readers to Ask
- Does the audit’s scope actually cover the systems described in the privacy policy’s data-collection section?
- Are there third-party SDKs or analytics tools bundled into the app that the audit didn’t examine?
- What jurisdiction is the company incorporated in, and what data-retention laws apply there?
- Is there a warrant canary, and has it been updated recently?
- Does the privacy policy’s language match the technical terminology used in the audit report, or are there ambiguous terms (e.g., “connection logs” vs. “activity logs”) that could hide a meaningful distinction?
How Regulatory Frameworks Interact With Both Documents
Data protection regulations like GDPR in the European Union or CCPA in California primarily govern the privacy-policy side of this equation — they set minimum requirements for disclosure, user rights (access, deletion, portability), and lawful basis for processing. These frameworks generally don’t mandate independent technical audits as a compliance requirement, which means a provider can be fully compliant with applicable data protection law while never having commissioned a technical audit at all, and conversely a provider can pass a rigorous technical audit while operating under a legal structure that offers comparatively weaker user rights.
This regulatory gap is part of why the audit ecosystem for VPNs developed as a voluntary, market-driven practice rather than a legal mandate. It also means that regulatory compliance and audit-verified technical practice should be evaluated as separate, complementary signals rather than treated as interchangeable proof points — a provider highlighting GDPR compliance is making a different (and narrower) claim than one highlighting a recent infrastructure audit, even though both are often presented in adjacent paragraphs of the same trust-and-safety page.
It is also worth noting that some jurisdictions impose data-retention mandates that could, in theory, override a provider’s own no-logs intentions regardless of what any privacy policy or audit report states. A provider genuinely committed to minimizing this risk will often disclose its corporate jurisdiction prominently, alongside an explanation of why that jurisdiction does not impose mandatory retention requirements applicable to its service. This disclosure is a third, distinct data point that neither the privacy policy’s own legal language nor a technical audit’s findings can fully substitute for.
Readers researching this angle should look specifically for the legal entity name behind a VPN service, since marketing brand names and the incorporated legal entity handling user data are not always the same thing, and the entity’s actual jurisdiction is what ultimately determines which laws and data requests apply.
A Real-World Scenario: When the Two Documents Diverge
Consider a hypothetical but realistic scenario that illustrates why reading both documents together matters. A provider’s privacy policy states plainly that no connection logs or activity logs are retained. A subsequent infrastructure audit confirms this is accurate for the core VPN tunneling servers. However, the same audit’s scope explicitly excludes the company’s customer support platform, which is run on a separate third-party helpdesk system. That helpdesk system, as a matter of standard operation, retains the IP address and email address of anyone who submits a support ticket — data that falls outside the “VPN activity” the privacy policy was describing, but that a security-conscious user might still care about a great deal.
Neither document is dishonest in this scenario. The privacy policy is accurate about VPN activity logs specifically, and the audit correctly verified what it was scoped to verify. But a reader who only checked the audit’s headline conclusion — “no logs found” — without checking its scope exclusions would walk away with an incomplete picture of what data the company actually retains somewhere in its broader operation.
Our Takeaway
Neither a privacy policy nor a security audit is sufficient on its own to fully evaluate a VPN provider’s trustworthiness — they answer different questions, verified through entirely different mechanisms, and a provider can score well on one while leaving real gaps in the other. The most reliable evaluation comes from reading both documents against each other, paying particular attention to the boundary between what’s covered by legal promise and what’s been technically verified, and treating jurisdiction and corporate history as a third, independent factor that neither document fully resolves.