You bought a VPN subscription, the toggle went green, and something in your head relaxed. That relaxation is the most expensive thing about the whole setup — because the green toggle answers a question you probably never asked. It hides your IP address from the site you visit. It does not hide you. Let's walk through what actually happens on the wire, what stays visible anyway, and where the legal regime of confidential information and breach liability finally catches up with the picture.
So what does a VPN actually change?
A VPN is a tunnel between your device and a server run by the provider. Your traffic leaves your machine encrypted, arrives at that server, and exits to the internet from the server's IP address. That's it. It is a network-layer substitution.
What that buys you is real: your internet provider no longer sees which sites you open, and the site sees the VPN server's address instead of your home connection. If you are on café Wi-Fi, the tunnel also stops the person next to you from reading your traffic.
What it does not do is make you unlinkable. The moment you log into an account, the site knows exactly who you are — the IP was never the identifier that mattered most. Your browser still reports its user agent, screen size, installed fonts, time zone, canvas rendering quirks and a dozen other signals. Put together, those signals form a browser fingerprint that stays stable across IP changes. Ad networks and anti-fraud vendors have been matching users this way for years; the IP is one input among many, and often not the decisive one.
If I use a VPN, am I anonymous?
No — and the honest answer is that "anonymous" is not a binary state you can buy for $5 a month. It is a property of a whole setup matched to a specific threat model.
Think about what a site or an investigator can still collect while your VPN is on:
- Account logins. You sign into email, a marketplace, a bank. The session cookie ties every subsequent request to that account regardless of exit IP.
- Cookies and local storage. Third-party trackers persist across sessions; the tunnel does not clear them.
- Browser fingerprint. As above — stable, and increasingly used precisely because IPs are cheap to rotate.
- Payment metadata. Card number, billing address, the name on the card. A purchase over a VPN is still a purchase under your name.
- Timing and behaviour. When you are online, how fast you type, which pages you linger on.
- DNS leaks. If your device still resolves names through your ISP's resolver instead of the tunnel, the provider sees every domain you visit even though the content is encrypted.
A useful mental model: the VPN changes your return address on the envelope. It does not change your handwriting, your stationery, or the fact that you signed the letter.
What is an IP address actually worth, then?
Less than the marketing suggests, more than nothing. An IP address is a routing identifier, and in most jurisdictions it is treated as personal data when it can be linked to an individual — the EU's GDPR applies to it as such, and courts in Europe have consistently read it that way. But linking requires additional data, which is exactly what logs, cookies and accounts supply.
So the practical question is not "does my IP leak?" but "who holds the correlation between my IP and me?" Three parties usually do:
- Your ISP, which sees your connection metadata — when you connected, to which address, how much data moved.
- The VPN provider, which sees your real IP on one side and your destination on the other. That is a uniquely powerful vantage point.
- The destination service, which sees the VPN IP but also your login, fingerprint and behaviour.
When people say a VPN "protects privacy," what they usually mean is that party 1 loses visibility. Parties 2 and 3 do not. If your threat model includes the VPN provider itself — and for some readers it should — the tunnel has simply moved the trust, not removed it.
What does "no-logs" actually mean, and can I check it?
"No-logs" is a policy statement, not a technical guarantee. A provider can write anything on its homepage. What you can check is narrower and more useful:
- Whether the policy is audited, by whom, how recently, and whether the audit report is public. An independent audit of a defined scope is worth more than a badge.
- What the jurisdiction requires. Providers incorporated in jurisdictions with mandatory data-retention or broad disclosure obligations may be legally unable to keep a no-logs promise in practice. This is a legal question, not an engineering one, and it is where information security law stops being abstract.
- Whether payment is linkable. A subscription paid by card under your name creates a record even if connection logs do not exist.
- Whether the client actually enforces the tunnel. A kill switch that silently fails is worse than none, because you believe you are covered.
Where does the law actually enter the picture?
Here is the part most VPN guides skip, and it is the part that matters if you handle other people's data for a living.
The moment you run a service — a website, an app, an internal platform — your obligations are not about your own browsing habits. They are about the data you hold. Under the GDPR, an IP address in your server logs is personal data, which means a lawful basis, a retention limit and breach notification duties attach to it. Under the EU's NIS2 Directive (EU) 2022/2555, entities in scope face concrete cybersecurity risk-management and incident-reporting obligations, and management bodies carry personal accountability for compliance. Trade secrets get their own regime: in the US, the Defend Trade Secrets Act (18 U.S.C. § 1836) gives a federal civil cause of action, but only if the owner took reasonable measures to keep the information secret — a phrase that turns on what your access controls, contracts and policies actually say.
That is the pivot. A VPN is a personal privacy tool. Confidentiality obligations, breach liability and incident reporting are organisational duties, and they do not care whether your exit node is in another country. A company that encrypts its traffic but stores customer IPs indefinitely, without a retention policy or a documented access model, is exposed on the legal side while feeling secure on the technical side.
If you are building that picture from the developer's side, the recurring traps — GDPR scope, licence terms, IP ownership — are covered in IT Legal & Compliance: What Developers Get Wrong About GDPR, Licenses and IP, and the operational checklist for founders sits in Personal Data Protection: A Step-by-Step GDPR and CCPA Compliance Checklist.
What does a practitioner actually do, step by step?
Imagine a freelance developer who occasionally handles client datasets and wants to stop leaking. The order matters more than the tools.
Step 1 — Write the threat model first. One paragraph: who am I hiding from? The café network neighbour, the ISP, the ad network, the client's auditor, a state actor? Each answer implies a different setup. Someone hiding from ad networks needs browser hygiene, not a VPN. Someone hiding from a state actor needs a much harder conversation than any consumer product provides.
Step 2 — Fix the leaks the tunnel does not fix. DNS resolver, WebRTC, IPv6. Test, do not assume.
Step 3 — Enable and verify the kill switch. Then break the connection on purpose to confirm it works.
Step 4 — Check jurisdiction and audit status. Read where the provider is incorporated and what disclosure rules apply there. Read the audit scope, not the badge.
Step 5 — Separate browser profiles. One profile for logged-in work accounts, one for research, one for anything you would rather not have correlated. This does more for real-world unlinkability than switching exit nodes.
Step 6 — Never do certain things over a free VPN. Free providers have to monetise somehow, and the usual currencies are traffic data and injection. Banking, work email, client data, anything with credentials — none of it belongs on a free tunnel.
Where do beginners get stuck, really?
The sticking point is rarely technical. It is that the field sits on two legs — engineering and law — and most people study only one.
Learn only the engineering and you can configure WireGuard on a VPS, as the practical guide in Computer Networks (CCNA): Building a WireGuard Server on a VPS walks through, but you will not know what retention obligations attach to the logs you just started collecting. Learn only the law and you will draft a beautiful confidentiality policy for a system that leaks DNS. The people who are genuinely good at this can read a network diagram and a data-processing agreement in the same afternoon and spot where they contradict each other.
A second trap: treating compliance as paperwork. The NIS2 obligations and the "reasonable measures" standard in trade-secret law are both judged by what you did, not what you wrote. A policy that says logs are retained for 30 days, next to a cron job that never deletes them, is worse than no policy — it is evidence.
Which learning path fits you?
Three routes, honestly compared:
| Path | Time | Cost | What you get | Where it breaks |
|---|---|---|---|---|
| Self-study from documentation and primary sources | Slow, uneven | Low | Real depth on the parts you happen to touch | No feedback; you do not discover the gaps until an incident or an audit |
| Practice on your own setup | Fast on the technical side | Low | Working tunnel, tested kill switch, real leak-hunting skill | Law side stays invisible; you cannot self-check a legal decision |
| Structured course with feedback | Weeks, paced | Moderate | Both legs together, with someone checking your reasoning | Requires you to actually do the exercises, not just read |
The honest trade-off: self-study is excellent for the engineering leg and genuinely poor for the legal one, because there is no compiler for a legal argument. You can test a kill switch in five minutes. You cannot test whether your retention policy survives a regulator's reading without someone experienced telling you where it is thin.
The asibiont.com Information Security Law course is built around exactly that second leg — the legal regime of information, confidential and trade-secret protection, licensing, and liability for information offences, anchored in NIS2, the Defend Trade Secrets Act and ISO/IEC 27001 and 27002, with sample local regulations and contracts you can compare against your own. Lessons are personalised and adapt to your level, so if you already know the technical side you are not made to sit through it again.
Who this suits — and who it does not
It suits developers and sysadmins who already run infrastructure and keep bumping into questions they cannot answer from documentation: what may I log, for how long, who may read it, what do I owe if it leaks. It suits founders and product managers who sign data-processing agreements without fully reading them. It suits anyone who has just discovered that their "anonymous" setup was never anonymous and wants to understand the legal layer underneath.
It does not suit someone looking for a magic privacy product, and it will not turn a beginner into a lawyer. It also will not help if you want to hide from a determined state-level adversary — no consumer course or tool will, and anyone promising otherwise is selling you the same myth this article opened with.
If your gap is broader than law — you are still deciding whether security is the field for you at all — start with Profession: Cybersecurity Specialist before narrowing into the legal side. And if your immediate concern is your own exposed data rather than organisational obligations, Digital Hygiene in One Evening is the faster first move. For a deeper dive into this topic, see [Digital Hygiene.
The green toggle is not a promise of invisibility — it is one line of defence at one layer, and the useful skill is knowing exactly which layer that is and what the other layers still say about you. Once you can answer that for your own setup, the legal questions follow naturally: what you may collect, how long you may keep it, and what you owe when it escapes. The course walks through those obligations with real regulatory texts and sample documents, and adapts to what you already know — the details are on the Information Security Law page. For a deeper dive into this topic, see Digital Literacy & Online Safety.