What Data a VPN Must Hold to Function at All

A VPN cannot function without knowing your real network address and the destinations you ask for, at the same time, for the duration of your session. It also cannot run as a business without an account record and a payment record. That is the floor: the data that must exist in some form for the service to work at all. Every privacy claim is a claim about what happens above that floor — what gets written down, for how long, and in what form.

Knowing where the floor is makes provider claims far easier to read, because you can immediately separate the impossible ones from the merely unverified ones.

The unavoidable operational data

Your source address, while connected. The server has to know where to send replies. This is not a policy choice; it is how packet networks work.

Your requested destinations, while connected. Forwarding traffic on your behalf means resolving and connecting to the places you want to reach. The server is handling them by definition.

DNS queries, if the provider runs the resolver. Directing lookups through the tunnel is one of the things a VPN is supposed to do, and the natural place to send them is a resolver the provider operates. That resolver sees every hostname.

Session state. Keys, the mapping between your tunnel and its outbound connections, and enough bookkeeping to route replies back to the right client.

Concurrent-connection accounting, if the service limits how many devices can be used at once. Enforcing a limit requires knowing how many sessions an account has open right now.

Bandwidth accounting, if the service has any usage limit or needs to manage capacity.

All of this exists in memory during your session, necessarily. The privacy question is whether any of it is written to persistent storage, and if so, for how long and with what identifiers attached.

The unavoidable business data

An account identifier. Something the client authenticates with.

A contact address, in practice, for password resets and service notices.

Payment records. Whoever processed the payment holds a record of it, and the provider holds enough to know the subscription is valid. Payment methods designed to minimise identity linkage change what this record contains, but they do not remove the existence of a transaction.

Support correspondence. Anything you sent a support agent exists, along with whatever context you volunteered in it — often including your address and the service that was misbehaving.

Infrastructure records at third parties. The provider’s own suppliers — hosting companies, transit providers, payment processors — hold their own records about the provider’s systems, on their own terms, which is worth remembering when reading a claim about a single company’s practices.

This is why “no logs” almost never means “no data about you”, as what a no-logs claim is worth sets out at length. A great deal exists that has nothing to do with connection logging.

What can genuinely be reduced

The floor is a floor, not a ceiling, and the space above it is where real differences live.

Persistence. Data can exist only in memory and be gone at reboot rather than written to disk. Architectures designed around this constrain what survives an incident or a seizure — with the limits described in what a RAM-only claim means.

Retention windows. Operational records can be discarded in minutes rather than kept for months. A specific, short, stated window is one of the most informative things a policy can contain.

Identifier separation. Authentication can be designed so the server verifying that a subscription is valid does not need to know which subscription it is. This is a real engineering discipline and the difference between “we choose not to correlate” and “correlation requires joining systems that were built apart”.

Aggregation. Capacity planning needs totals, not per-user histories.

Resolver design. A resolver can be operated so queries are not attributed or retained.

Payment minimisation. Methods that reduce what the provider learns about the payer’s identity shrink the business-data floor, without removing it.

How to read a policy against the floor

This gives you a practical test. For any claim, ask which category it falls into:

Impossible claims — “we never see your traffic”, “we cannot know your IP address”, “we hold no data about you at all”. These contradict the floor. A provider making them is either being loose with language or does not want you thinking about the architecture.

Structural claims — “our servers write nothing to disk”, “authentication is separated from subscription identity”, “the resolver does not attribute queries”. These describe design, are meaningful, and can in principle be examined by an auditor.

Policy claims — “we do not retain connection logs”, “we discard operational records within a stated period”. These describe choices. They can be true, they can change, and they are what an audit can support but not prove permanently.

Irrelevant claims — cipher names, server counts, jurisdiction slogans. See military-grade encryption and server counts for why these consume most of the page while telling you least.

Why the floor is the right starting point

It reframes the entire evaluation. The question is not whether a provider can be trusted to be blind — it cannot be blind, because the service requires sight. The question is how much of what it sees is written down, how quickly it goes away, and whether the architecture makes correlation hard rather than merely discouraged.

That is also why the honest description of a VPN is a relocation of trust rather than an elimination of it, as what your VPN provider can see spells out. You are choosing a custodian for information that will exist regardless. Choose one whose claims survive contact with the floor.