The Budapest Convention on Cybercrime — opened for signature in 2001, entered into force in 2004 — has been ratified by more than 60 states. The 14-eyes arrangement that dominates VPN review sites accounts for 14 of them. The remaining states in the treaty network can request, and receive, mutual legal assistance in criminal investigations that produce subscriber data, traffic data, and in some cases stored content. "Outside the 14-eyes" is not outside the network. It is a marketing claim dressed as a jurisdictional analysis.
Whether that matters depends on who you are and who is looking for you. A privacy-conscious user concerned about ISP data harvesting and ad-tech correlation faces a fundamentally different legal exposure than a journalist protecting a source in a country with aggressive lawful intercept capability. The treaty framework that applies, the subpoena mechanism that works, and the data the provider can even produce under compulsion — all of these change with the threat model. We will walk through three hypothetical scenarios. Each describes a different person, a different adversary, and a different 14-day evaluation protocol for testing whether a VPN provider's jurisdictional position actually defends against the threat that matters.
Scenario 1: The Amsterdam Freelance Journalist
Imagine a freelance journalist based in Amsterdam. She covers financial crime and her current investigation involves leaked documents from a corporation headquartered in a 5-eyes country — let us say the United Kingdom. Her adversary is not a nation-state signals intelligence agency. Her adversary is a well-funded corporate legal team with the resources to pursue civil discovery in multiple jurisdictions and the connections to encourage a law enforcement referral if the leaked documents can be characterized as stolen property.
The Netherlands is a 9-eyes member. It participates in the SIGINT Seniors Europe arrangement that sits beneath the broader UKUSA Agreement of 1946. Dutch intelligence services — the AIVD and MIVD — operate under the Intelligence and Security Services Act 2017 (Wiv 2017), which was revised after a 2018 advisory referendum. For signals intelligence purposes, the Netherlands cooperates with 5-eyes partners.
But that is the intelligence layer. Our journalist's adversary is not an intelligence agency — it is a corporate legal team using the civil and criminal mutual legal assistance framework. The relevant mechanism is not the UKUSA signals channel. It is the bilateral MLAT between the Netherlands and the United Kingdom, supplemented by the European Investigation Order framework that applied between EU member states and which continued to function under transitional arrangements following Brexit.
Her 14-day evaluation protocol:
Days 1–3. Identify the VPN provider's jurisdiction of incorporation. Not the marketing jurisdiction — the actual legal entity. Verify through corporate registry filings, not the provider's website. A provider that says "based in Panama" but operates through a Delaware LLC for payment processing has created a US-compellable nexus.
Days 4–7. Map the MLAT network from the provider's jurisdiction. For each MLAT the jurisdiction has signed, note: whether it covers civil matters or criminal matters only, whether it includes real-time intercept provisions or only stored data, and whether the dual criminality requirement applies — meaning the requesting country must show that the underlying conduct is criminal in both jurisdictions.
Days 8–10. Evaluate the provider's architecture against the MLAT scope. If the provider operates RAM-only servers, an MLAT request for stored data returns nothing meaningful. But if the provider runs persistent disk infrastructure with centralized authentication logs, an MLAT request may produce connection timestamps, bandwidth usage, and authentication metadata even without content decryption. The question is not whether the provider has a no-logs policy. The question is whether the server architecture makes logging technically impossible or merely policy-prohibited.
Days 11–14. Test the VPN client's protocol implementation against the specific DPI capability of the journalist's local network. If the VPN uses WireGuard — specified in Jason Donenfeld's 2017 whitepaper as a fixed-header protocol with a known initial handshake pattern — a DPI-capable observer can identify WireGuard traffic without decrypting it. The handshake initiator message is 148 bytes. That fingerprint is documented in the protocol specification. If the adversary's goal is to prove the journalist used a VPN at a specific time — sufficient to support a civil subpoena timeline argument — WireGuard's identifiable traffic pattern becomes relevant. OpenVPN over TCP port 443 with `tls-crypt` obfuscation is harder to fingerprint but not immune to statistical traffic analysis.
For this journalist, the 14-eyes framing is almost irrelevant. Her exposure runs through the MLAT and EIO framework, not the signals intelligence arrangement. A VPN "outside the 14-eyes" but inside the Budapest Convention treaty network does not reduce her legal exposure by a single mechanism.
Scenario 2: The Austin Privacy-Conscious Developer
Picture a software developer in Austin, Texas. He works from home, uses public Wi-Fi at coffee shops regularly, and his threat model is narrow: he does not want his ISP selling browsing metadata to data brokers, and he does not want ad-tech networks building a cross-site profile from his home IP address. No one is investigating him. He is not a target.
His adversary is commercial surveillance infrastructure: the ISP's data monetization program — legal under post-2017 FCC rules in the United States, after the Congressional Review Act repealed the Obama-era broadband privacy regulations — and the ad-tech correlation engine that maps IP addresses to browsing profiles across publisher sites.
For this developer, the entire 5-eyes/9-eyes/14-eyes framework is operationally irrelevant. No intelligence agency is interested in his traffic. No MLAT request will ever name him. His evaluation protocol is shorter and structurally different.
Days 1–3. Confirm the VPN provider does not inject tracking headers or advertising into HTTP traffic. This has happened with commercial VPN providers. Verify by routing traffic through the VPN and inspecting HTTP response headers for injected identifiers. A `curl -v` comparison with and without the VPN active will surface most header injection.
Days 4–7. Verify DNS handling. The developer's risk is DNS leak — queries escaping the VPN tunnel and reaching the ISP's DNS resolver, which logs them. Test with `dig` queries to a known canary domain while the VPN is active. Confirm that all DNS resolution occurs within the tunnel. Check for WebRTC IP leaks in the browser — a deanonymization vector that operates outside the VPN tunnel entirely unless the browser is explicitly configured to block it.
Days 8–10. Evaluate the provider's payment and account data exposure. If the developer pays with a credit card and registers with his personal email, the provider holds identity data compellable under a domestic subpoena — no MLAT required. The jurisdictional question for this user is not about international treaty frameworks. It is about domestic compulsion. A US-based provider served with a National Security Letter under 18 U.S.C. § 2709 can be compelled to produce subscriber records with a gag order attached. A provider outside US jurisdiction requires at minimum an MLAT request, which for a non-criminal commercial privacy matter may never be initiated.
Days 11–14. Measure whether the VPN introduces latency or reliability degradation that will cause the developer to disable it. A VPN that gets turned off because it slows down workflow provides zero protection. Measure baseline latency to the three most-used services, then measure with the VPN active. If degradation exceeds 40ms on average, behavioral data says the user will disable the VPN within a month. This is not a security metric. It is a behavioral prediction, and for this threat model it matters more than jurisdiction.
Here is where two primary documents collide. The CLOUD Act of 2018 states that a US provider must comply with lawful data requests regardless of where the data is stored — the extraterritorial reach is explicit in the statute's text. The GDPR, effective the same year, asserts under Article 48 that third-country judicial decisions requiring data transfer are not recognized unless grounded in an international agreement such as an MLAT. Both are operative law. Both apply to a US VPN provider that processes EU user data. The tension between them remains formally unresolved, though the EU-US Data Privacy Framework adopted in 2023 addresses some transfer mechanisms. For the Austin developer routing only US domestic traffic, this conflict is academic. For a European user of a US-headquartered VPN, it is not.
Scenario 3: The Geneva Human Rights Researcher
Let us say a researcher at a Geneva-based NGO documents detention conditions in a country with aggressive domestic surveillance and no independent judiciary. Her contacts inside that country communicate through encrypted channels, but the metadata — who communicates with whom, when, and from which IP range — is the exposure she needs to control. Her adversary is a state security apparatus with the capability to request mutual legal assistance through diplomatic channels, even when the underlying investigation would not meet due process standards in a Swiss court.
Switzerland is not a member of the 5-eyes, 9-eyes, or 14-eyes arrangements. This is the fact most VPN review sites stop at. Here is what they omit: Switzerland is a party to the Budapest Convention on Cybercrime. Switzerland has bilateral MLATs with the United States, Germany, France, Italy, and dozens of other countries. Switzerland participates in the Schengen Information System through its Schengen association agreement, which includes provisions for law enforcement data sharing.
What the Netherlands handles through its 9-eyes membership and the European Investigation Order framework, Switzerland addresses through bilateral MLAT agreements and the Schengen association. The mechanism differs. The endpoint — a legal request for subscriber data served on a provider incorporated under Swiss law — is functionally equivalent for the data categories most MLATs cover.
Days 1–3. Identify whether the VPN provider's Swiss incorporation is substantive or nominal. A provider incorporated in the Canton of Zug as a GmbH with local directors, local infrastructure, and local legal counsel is genuinely subject to Swiss jurisdiction — including its relatively strong procedural protections for surveillance targets. A provider with a Swiss shell entity but infrastructure routed through data centers in Frankfurt and Amsterdam has Swiss letterhead and German and Dutch compulsion exposure.
Days 4–7. Map which countries have functioning MLAT arrangements with Switzerland that cover the data categories the researcher needs to protect. Connection metadata — timestamps, IP addresses, session duration — is typically within MLAT scope. Content decryption is typically not, unless the provider holds decryption keys. The researcher must determine whether her adversary's government has a bilateral MLAT with Switzerland, and whether that MLAT covers the relevant data categories.
Days 8–10. Evaluate whether the VPN provider has received and complied with prior legal requests. Swiss law requires transparency from telecommunications providers under the Federal Act on the Surveillance of Post and Telecommunications (BÜPF). Check whether the VPN provider publishes a transparency report. If it does, examine the request volume and compliance rate. If it does not, that absence is data — it means the no-logs claim cannot be verified against actual legal compulsion history.
Days 11–14. Assess the provider's operational security posture against known VPN infrastructure vulnerabilities. CVE-2023-20269 — the Cisco ASA and FTD unauthorized access vulnerability disclosed in September 2023 — was actively exploited in the wild to compromise remote access VPN sessions. The CVE is not about consumer VPN client software specifically, but it demonstrates the attack surface: VPN server infrastructure is itself a target. The researcher should verify that the provider's server-side stack runs current, patched software, and that the provider maintains a documented vulnerability disclosure and patching policy. A provider that was running unpatched Cisco ASA firmware during the September–October 2023 exploitation window demonstrated an operational security posture incompatible with protecting high-risk traffic.
What All Three Share
Three scenarios. Three different adversaries. Three different jurisdictional exposure maps. One shared pattern: the number of "eyes" in the surveillance arrangement is not the variable that determines exposure.
All three evaluation protocols require four structural steps. First, verify the legal entity — not the marketing identity, the actual incorporated entity that receives and must respond to legal process. Second, map the MLAT network from that entity's jurisdiction to the adversary's jurisdiction — the specific bilateral or multilateral agreement, not the generic "eyes" membership. Third, test the provider's architecture against the specific data categories the relevant MLAT covers — a RAM-only server architecture responds differently to a stored-data request than a persistent-disk architecture, regardless of privacy policy language. Fourth, assess operational security independently of the jurisdictional question — a provider in a favorable jurisdiction running unpatched infrastructure is worse than a provider in a "bad" jurisdiction running hardened, audited systems.
The 14-eyes framework is a signals intelligence arrangement. It governs how the NSA, GCHQ, BND, and their counterpart agencies share intercepted communications. It does not govern how a French prosecutor requests subscriber records from a Dutch VPN provider. That request runs through an MLAT or the European Investigation Order. Conflating the two frameworks is the analytical error most VPN review sites make, and it leads users to optimize for the wrong variable.
Which Scenario Is You
Start by naming your adversary. Not "hackers" — that is not specific enough to evaluate. Not "the government" — which government, which agency, which legal authority, which data category. If you cannot name the adversary, you cannot evaluate the VPN.
If your answer is "my ISP and ad-tech companies," you are Scenario 2. Your evaluation is simpler, your jurisdictional exposure is primarily domestic, and the 14-eyes framework is not a meaningful factor in your analysis.
If your answer involves a specific law enforcement or intelligence agency in a specific country, you are Scenario 1 or Scenario 3. Your evaluation requires MLAT mapping, legal entity verification, and architecture analysis that extends well beyond reading the provider's privacy policy.
If you cannot decide, default to the strictest protocol. Evaluate as if your adversary has MLAT capability. The steps are identical — they take longer to execute. A VPN provider that survives a Scenario 3 evaluation will survive Scenarios 1 and 2. The reverse is not true.
---
This piece did not cover Tor-over-VPN or VPN-over-Tor configurations — those involve threat models that extend beyond provider jurisdiction into network-level anonymity, which requires a separate and significantly more complex analysis. It did not cover warrant canary reliability, which has no legal precedent establishing enforceability in any jurisdiction discussed here. And it did not address the Second Additional Protocol to the Budapest Convention, adopted in 2021, which expands cross-border direct data access provisions in ways that may alter the MLAT evaluation framework described above — that protocol is not yet in force in most signatory states, and its operational impact remains speculative until ratification numbers and implementation practice accumulate.