A No-Logs Audit Is a Snapshot, Not a Forever Promise
A useful VPN audit has a named system, time period, method and finding. Here is how to tell what it actually checked — and what remains outside scope.
“Independently audited” sounds like a binary fact. Either a VPN passed or it did not. The report itself is rarely that simple. An audit tests a defined set of systems, controls or claims during a particular period. The value of the result depends on that scope.
A careful reader should be able to answer five questions: who performed the work, what they examined, when they examined it, how they tested it and what limitations remained.
1. Who was the auditor?
Name recognition is useful but insufficient. Look for the legal entity that signed the report and the professional standard used. A security consultancy performing a configuration review is doing different work from an accounting firm conducting an assurance engagement.
The provider usually pays for the audit. That does not make the findings false, but it makes publication terms important. Did the provider publish the full report, a short opinion letter or only its own summary? Can the auditor describe exceptions, or does the contract restrict disclosure?
2. What exactly was in scope?
“The VPN” is not a precise system. A provider may operate authentication services, payment systems, websites, apps, VPN gateways, DNS resolvers, analytics tools and support platforms. An audit of gateway logging does not necessarily cover account records or website tracking.
Write down the named components. Useful reports identify server images, orchestration, logging pipelines, authentication flows and the policy claims mapped to them. If mobile applications or third-party infrastructure are excluded, the conclusion should stay equally narrow.
Geography matters too. Testing a sample of server locations may reveal how the standard build behaves without proving that every rented server was configured identically.
3. What period did it cover?
A point-in-time examination asks whether controls were designed or configured as described on one date. A period examination tests whether controls operated over weeks or months. Both can be valuable, but they answer different questions.
The report date is not automatically the testing date. Read the period, then compare it with later ownership, infrastructure and policy changes. A clean result from two years ago says little about a system rebuilt last month.
4. What evidence did the auditor use?
Interviews and document review establish how a system is supposed to work. Stronger technical evidence may include configuration inspection, code review, attempts to retrieve activity records, observation of data flows and sampling of production systems.
No audit can prove that data has never existed anywhere. It can provide assurance that the examined design and controls did not create or retain specified records during the scope. The wording matters: “no evidence found,” “controls suitably designed” and “provider does not log” are not interchangeable conclusions.
5. Were there exceptions?
An exception is not automatically a failure. It may identify a control that operated inconsistently, a system excluded from testing or a recommendation the provider accepted. Hiding every exception behind “passed” removes the information readers need.
Check whether the report distinguishes operational logs from activity logs. Server load, crash reports and aggregate bandwidth can be compatible with a no-activity-logs policy, but identifiers and retention periods determine the privacy impact.
Evidence outside the audit
An audit is one line in a longer ledger. Other useful evidence includes:
- published architecture and reproducible app builds;
- court or law-enforcement records showing what the provider could supply;
- incident reports and postmortems;
- ownership and jurisdiction changes;
- transparency reports; and
- later audits with comparable scope.
None is decisive alone. A court case may test one account under one configuration. Open-source apps reveal client behaviour but not server logging. A transparency report is a provider statement unless independently supported.
The short record to keep
For each audit, record the provider, auditor, report link, systems, locations, examination period, assurance method, conclusion, exceptions and publication limits. Then add later events instead of overwriting the old entry.
That is the difference between a badge and evidence. “Audited” is marketing shorthand. The ledger is the scope, date, method and result.