ProtonVPN vs NordVPN: Reading a Provider's Documents Instead of Its Values

Comparisons of this pair usually turn into a discussion of character: one provider’s stated values against another’s, as though a mission were a specification. It is not, and treating it as one is how people end up trusting a sentence. But providers do publish material that can be assessed, and reading it is the most productive hour available to anyone choosing between two services.

No verdict follows, and no claims about either company’s features, structure, or terms — those live on their own sites, currently, and any version printed here would be stale. What follows is which documents to read and what each one can and cannot establish.

Why a stated mission is not evidence

A declared purpose, an origin story, a legal form, a philosophical commitment: these are worth something, because organisations do behave in line with how they understand themselves, and because a public commitment is something to be held to. They are also cheap to write, unfalsifiable as stated, and revisable without notice.

The failure mode is substitution. A reader who finds a mission agreeable stops examining, and a reader who finds a competitor’s marketing crass stops examining that one too. Both have replaced assessment with affinity. The correct handling is to treat a mission as a reason to look at the documents, not as a substitute for having looked.

There is a second trap specific to values-forward positioning: it attracts the assumption that everything else follows. A strong privacy commitment says nothing about client stability, support quality, refund behaviour, or how a service performs on your connection — all of which you will notice daily.

The documents worth reading, and what each establishes

The privacy policy. Establishes: what the company says it collects, keeps, and shares, and for how long. This is the operative statement, and it usually differs in tone and content from the marketing. Does not establish: whether the description matches practice.

The terms of service and the acceptable-use policy. Establish: your obligations, what use gets an account closed, what the company disclaims, and the refund and cancellation position. Do not establish: how any of it is enforced. Read these before subscribing, because they are the document you actually agreed to.

A transparency report. Establishes: that the company has a process for handling official requests and is willing to describe it, plus whatever it chooses to publish about volume. Does not establish: completeness, since a provider is generally not free to disclose everything, and the absence of a report is not evidence of an absence of requests.

An audit or assessment report. Establishes: that specified things were examined at a specified time and matched a specified description. Scope and date are everything, and the reasoning is set out in ExpressVPN: not a review. Does not establish: anything outside the scope, or anything after the fieldwork.

A technical or security description. Establishes: how the company says the system is designed — and design claims are the most useful kind, because a provider that has arranged not to hold something is in a different position from one that has promised not to look at it. That distinction is the substance of what a no-logs VPN policy means. Does not establish: that the deployed system matches the description.

Published source code. Establishes: what the software on your own device does, which is genuinely valuable and independently checkable. Does not establish: what runs on the provider’s servers, which is where the interesting questions are.

Release notes and a status page. Establish: whether the thing is actively maintained and how the company communicates during failure. This is neglected, and it is one of the better predictors of what living with a service will be like. Do not establish: anything about security posture.

Incident disclosures. Establish: how the company behaved when something went wrong, which is the most informative material a provider ever publishes about itself. Do not establish: that no undisclosed incident occurred.

How to read a document you are not meant to enjoy

  • Find the definitions. A policy that promises not to keep “logs” is only as strong as its definition of the word, and the definition is often somewhere else in the document.
  • Hunt for the hedges. Generally, typically, where possible, to the extent permitted, may. Each one marks a place where the plain reading and the commitment diverge.
  • Read the exceptions, then reread the promise. Exceptions are usually grouped later and change the earlier text substantially.
  • Note the effective date and whether a change history exists. A policy that shows its revisions is far more useful than one that does not.
  • Notice what is not addressed. Silence on a question you care about is an answer of a kind, and it is the thing marketing pages are best at hiding.
  • Check whether the marketing claim appears anywhere in the binding document. Often it does not, and that gap is the single most informative observation available to a prospective customer.

What differences between two providers’ documents indicate

Comparing document sets is a legitimate exercise, with one caution: you are comparing disclosure practices as much as underlying reality. A provider that publishes more has given you more to assess and has also given itself more to be held to, which is a meaningful choice. But a thinner document set may reflect a smaller company rather than a worse one.

So read differences as signals about candour and maturity, not as measurements of security. And weigh design descriptions above promises, published full reports above summaries, and disclosed incidents above unblemished records.

What no document establishes

Whether commitments are honoured today, whether an employee has access they should not, whether the company will be structured the same way next year, or how the service will perform on your connection. Those belong to the categories described in judging a VPN on privacy — either trust, or something only your own testing can settle.

A reading order for one sitting

Privacy policy, then acceptable-use policy, then refund terms, then any technical design description, then the scope section of the most recent audit report, then release notes, then any incident disclosure. Do it for both providers, in the same order, taking notes against the same questions. An hour spent this way tells you more than any comparison article, and unlike the article it is current.

Bottom line

Judge providers on their documents rather than their declared values: the privacy policy for what is claimed, the terms for what you agreed to, a design description for whether data is avoided or merely unexamined, audits for scope and date, and incident disclosures for behaviour under pressure. Read for definitions, hedges and omissions, prefer design claims to promises, and treat a mission statement as a reason to keep reading rather than as a finding.