Author: vpncomparisonguide.com

VPN websites often make statements about who they are: where the company is based, who runs it, who owns it. These are claims, and some of them can be checked against public registers. For companies registered in the UK, the Companies House register is the main official source. This guide explains what that register publishes about owners and officers, and what it does not establish. It covers companies registered at Companies House only; a VPN business registered in another country is governed by that country’s register and rules, which are outside this guide. It is general information, not legal advice, and it assesses no provider.

What the register publishes

GOV.UK describes the free “get information about a company” service as providing details such as the registered address and date of incorporation, current and resigned officers, document images, mortgage charge data, previous company names and insolvency information. Free email alerts can be set up to flag changes, such as a new director or address. The search service accepts a company name, number or officer name.

For a VPN business, the practical value is matching names. If a provider’s terms or privacy notice name a company, that name can be searched and compared with what the website says about its location, management and history.

Who counts as an owner: people with significant control

Companies must identify and register their “people with significant control” (PSCs), sometimes called beneficial owners. According to Companies House guidance, a PSC is usually someone who holds more than 25% of the shares or voting rights, can appoint or remove a majority of the directors, or can influence or control the company or a trust. The company must give details including name, date of birth, nationality, country of residence, a service address and the nature of control, and must update Companies House within 14 days of confirming a change.

The published figures for shareholding are banded rather than exact: over 25% up to and including 50%, more than 50% and less than 75%, and 75% or more. A company may also state that it has no PSC, with a reason, because its PSC information cannot be left blank. Individuals can apply to have some PSC information protected from publication, and Companies House guidance notes that protection applies from the date the application is made.

What has changed in accuracy checks

Companies House says that it historically accepted documents with limited verification, which meant less assurance over accuracy. Under the Economic Crime and Corporate Transparency Act 2023 it can now query or reject filings that appear incomplete, inaccurate or misleading, and remove false entries more quickly. Directors and PSCs are subject to identity verification, and GOV.UK guidance on PSCs notes that mandatory identity verification launched on 18 November 2025. Companies House also describes many of the Act’s provisions as still being rolled out.

Even so, the Companies House search page still carries the notice that Companies House does not check the accuracy of the information filed. Both statements appear in official material, and the safest reading is that the register is an official filing record with growing checks behind it, rather than an independently audited statement of fact. The filing is made by the company, so it is also a claim by the company, now with a degree of official scrutiny.

What the register does not show

• Where the service runs. A registered office is an address on the register. The register entry does not describe where servers are located, where staff work, or which entity operates the app.
• Whether there is a UK entity at all. A provider may be operated by a company registered elsewhere. In that case a UK search shows nothing, and the absence of a UK entry does not imply wrongdoing.
• Control through other arrangements. The PSC rules cover defined types of control. The guidance says the “other significant influence or control” condition applies only in limited circumstances, so informal influence may not appear on the register.
• Logging or security practice. Nothing on the register speaks to how data is handled. Those questions belong with the provider’s policies and any independent reports, covered in the guide to logging policies and independent audits.

The register also does not settle the question of legal reach. The guides to VPN jurisdiction and to the US CLOUD Act explain why a head office country is not the whole story.

A simple checking routine

• Note the company name given in the provider’s terms or privacy notice.
• Search the register and compare the registered office, incorporation date and officers with the website’s statements.
• Look at the PSC entries and the nature-of-control bands.
• Check the filing history for recent changes.
• Treat any mismatch as a question to ask the provider, not as proof of a problem.

Common questions

Is the register free to search?

GOV.UK states that some company details, including the items listed above, are available for free.

Does a UK registration make a VPN more trustworthy?

The register records filings and ownership information. It does not evaluate service quality or privacy practice.

The bottom line

The Companies House register gives a public, official record of registered UK companies, including officers and people with significant control, and the system has been strengthened since the Economic Crime and Corporate Transparency Act 2023. It remains a record of what the company has filed, with the search page itself stating that accuracy is not checked, and it covers only UK-registered entities. For a VPN provider, it can confirm or contradict claims about company identity and ownership, but it cannot verify where traffic is handled, how data is stored or whether a no-logs promise is kept.

Sources

• Get information about a company (gov.uk)
• People with significant control (PSCs) (gov.uk, Companies House guidance, last updated 30 July 2026)
• Then and now: the impact of the Economic Crime and Corporate Transparency Act on Companies House (Companies House blog, 8 October 2025)
• Search the register (find-and-update.company-information.service.gov.uk)

A VPN changes the network path between a device and the websites it visits, including the IP address a website sees. Many online tracking methods work differently: they rely on information kept on the device or passed in a link. The UK Information Commissioner’s Office (ICO) lists these methods in its guidance on “storage and access technologies”. This guide summarises that list and explains why a VPN is a different kind of tool. It is general information, covers the UK position, and does not assess any VPN product or tracker-blocking feature.

What the ICO guidance covers

The ICO guidance explains the Privacy and Electronic Communications Regulations (PECR), which apply in the UK. It says that PECR applies to any technology that stores information, or accesses information stored, on a subscriber’s or user’s “terminal equipment”. The rules apply in web browsers, mobile apps and connected devices. They allow use of these technologies in particular circumstances or with valid consent, and where the information is personal data the UK GDPR also applies. The guidance is addressed to organisations, so it describes what services do rather than how users should respond. Other countries, including EU member states and US states, have their own rules, which are not covered here.

The technologies the ICO lists

• Cookies are small text files generated by a web server and stored by the user’s device, usually through the browser. The ICO notes uses such as recognising a device, remembering a shopping basket, supporting log-in or remembering that a user is logged in, analysing traffic, and tracking browsing behaviour.
• Tracking pixels are small pieces of code, usually an image file, embedded in a web page or email that create communication between the user’s client and a server. The ICO’s email example records the time, location and operating system of the device used to read the message.
• Link decoration and navigational tracking add extra information to the URL in a link. This can identify where traffic came from, and the ICO says it can also identify that a user of one site is the same person as a user on another, for example by adding a user ID to a URL.
• Device fingerprinting collects pieces of information about a device’s software or hardware that can be combined to identify a particular device. The ICO lists examples such as device configuration, HTTP header information, clock information, installed fonts and plugins. It says these elements can also be combined with other information, such as IP addresses or unique identifiers.
• Web storage (localStorage and sessionStorage) lets sites store data in the browser. The ICO notes that localStorage data may be kept permanently unless removed, and that the data is not transferred to a server unless this is done manually.
• Scripts and tags are JavaScript snippets that collect additional information about visitors, often using the other technologies on this list.

Why the IP address is only part of the picture

In the ICO’s descriptions, the identifying information sits in the browser or device (cookies, web storage, fingerprint inputs), travels in the link (link decoration), or is requested by embedded content (pixels and tags). The IP address appears only as one possible extra input to fingerprinting. A VPN replaces the network address a site sees, as the guide to IP addresses as personal data explains. That does not remove a cookie already stored in a browser, change what is in web storage, or alter an identifier carried in a URL.

This is an inference from how the ICO describes the technologies, not a test result for any product. Individual VPN apps may bundle extra features, such as tracker blocking, which are separate claims that need their own evidence. The guide to browser fingerprinting covers one of these methods in more depth.

First-party, third-party and persistence

The ICO explains that the first-party or third-party label is not the main consideration for privacy purposes. What matters is who is responsible for the storage or access and why. It notes that third-party cookies can link people’s activity across different sites and devices, and that browsers have introduced limitations, including tracking protection features and restrictions on third-party cookies. In some cases, it says, resources once delivered by a third-party cookie are now delivered through a first-party cookie.

The guidance also separates session storage, which generally expires when the browser is closed or shortly afterwards, from persistent storage that lasts between visits. It adds that some session cookies can be restored by the browser in the next session, so the distinction is not absolute. Controls over these items sit in browser and device settings. The wider guide to online privacy basics covers how those controls fit with a VPN.

Common questions

Does a VPN stop cookies?

The ICO describes cookies as stored by the user’s device and sent back to the web server on later requests. A VPN does not appear in that description, so it should not be assumed to stop them.

Does the ICO say a VPN protects against these methods?

No. The guidance does not mention VPNs. It describes what services do, and the conclusion drawn here is an inference.

The bottom line

The ICO’s guidance treats cookies, tracking pixels, link decoration, device fingerprinting, web storage and scripts as technologies that store or access information on a device or travel with a link, all regulated in the UK under PECR. A VPN changes the network address a website sees, but the identifying information in these methods does not depend on that address alone. Claims that a VPN, or a bundled blocker, reduces tracking should be read as separate claims about particular features, to be checked against evidence rather than assumed from the VPN label.

Sources

• What are storage and access technologies? (ico.org.uk, Guidance on the use of storage and access technologies)

VPN providers often point to a penetration test or security assessment as evidence of quality. A summary that says “tested by an independent firm” is a claim about an event, and what that event covered is a separate question. The UK’s National Cyber Security Centre (NCSC) publishes guidance on penetration testing that explains what these tests are designed to do and where their limits lie. The guidance is written for organisations commissioning tests, not for consumers comparing VPNs, so this guide applies its points by analogy and labels them as such. It is general information and assesses no provider.

What the NCSC says a penetration test is

The NCSC guidance, first published on 8 August 2017 and reviewed on 10 January 2022, opens by calling penetration testing a core tool for analysing the security of IT systems that is “not a magic bullet”. It defines a penetration test as a method for gaining assurance in the security of an IT system by attempting to breach some or all of the system’s security, using the same tools and techniques as an adversary might.

It adds that a test should be viewed as a way of gaining assurance in an organisation’s own vulnerability assessment and management processes, not as the primary way of identifying vulnerabilities, and compares it to an external financial audit that checks whether the internal team’s processes are sufficient.

What a test can tell you

According to the NCSC, a well-scoped test can give confidence that the products and security controls tested have been configured in accordance with good practice and that there are no common or publicly known vulnerabilities in the tested components, at the time of the test. A test report is expected to include the issues found, a risk assessment for each, and a way to resolve them. Findings are normally given a severity rating, and any departure from the standard rating should be documented and justified.

What a test cannot tell you

The same guidance sets out several limits that matter when reading a published summary:

• A snapshot in time. A test can validate only that systems are not vulnerable to known issues on the day of the test. The NCSC notes that a year or more may pass between tests, so problems can exist for long periods without being detected.
• Dependence on scope. The scoping stage fixes the technical boundaries, the types of test, and the time and effort allowed. If testers find components outside the scope that affect security, the exclusion may be recorded as a limitation on testing.
• Dependence on the testers. Tests cannot be entirely procedural, so the quality of the work is closely linked to the abilities of the people doing it.
• Different testing bases. Testers may be given full information about the target (open box) or none (closed box). Closed-box work models an outside attacker, but the NCSC notes that limited information and time can leave vulnerabilities undiscovered.
• Not suited to every target. The NCSC describes penetration testing as appropriate for a specific operational system made up of products and services, and says it is not an appropriate technique for product-specific testing.

The last point is relevant to VPN apps, which are products. A published VPN assessment may be a different kind of review, such as a code or configuration review, so the report’s own description of its method matters more than the label “penetration test”.

Reading a provider’s published summary

Using the NCSC’s framework as a checklist, these are the questions a summary should answer:

• Who and when? Which firm performed the work, who commissioned and paid for it, and on what dates?
• What was in scope? Which apps, versions, servers and back-end systems were included, and which were excluded?
• What method? Open-box, closed-box, code review, or something else?
• What was found? A report that lists issues with severity ratings tells a reader more than a statement that none were significant.
• What happened next? Were the findings fixed, and was that confirmed by retesting? The NCSC says the organisation, not the test team, owns risk decisions and fixes.
• How current is it? Does the tested version match what is being sold today?

The guides on logging policies and independent audits and on the 2017 OpenVPN audits show how age and scope affect what a published audit can support. A related distinction, between stated policy and verified practice, runs through the guide to warrant canaries and transparency reports.

Common questions

Does a clean report mean the service is secure?

No. Under the NCSC’s description, a test shows the state of the tested components against known issues at a point in time, within an agreed scope.

Is an independent test the same as an audit of a no-logs policy?

Not necessarily. A security test looks at vulnerabilities, while a logging audit looks at data practices. Each has its own scope, and one does not substitute for the other.

The bottom line

The NCSC describes penetration testing as a useful way to gain assurance about a defined system at a point in time, not a guarantee of security and not a primary method for finding vulnerabilities. When a VPN provider cites a test, the claim becomes meaningful only to the extent that the scope, method, dates, findings and follow-up are published. A short statement that a test took place is the provider’s claim; the full report is the evidence, and even that evidence is a snapshot.

Sources

• Penetration testing: how to get the most from penetration testing (ncsc.gov.uk, published 8 August 2017, reviewed 10 January 2022)

Many VPN websites mention a bug bounty, a responsible disclosure policy or a security contact. These are statements about process, and they are easy to confuse with evidence about how secure a service is. One technical document, RFC 9116, defines a standard file called security.txt for publishing this kind of information. Reading what that document says, and what it avoids saying, helps separate a published channel from a verified security record. This guide is general information and makes no assessment of any provider.

What RFC 9116 is

RFC 9116, published by the Internet Engineering Task Force (IETF) in April 2022, defines a machine-parsable format named security.txt. Its stated purpose is to help organisations describe their vulnerability disclosure practices so that researchers can report problems more easily. The document carries the category “Informational” and is described as not being an Internet Standards Track specification. It also says that security.txt is intended to be complementary to, and not a substitute for, other public resources an organisation maintains about its security disclosure practices.

It is a technical format, not a law. The RFC describes how the file should be structured and located, and what readers should be careful about, and it does not require any organisation to publish one or say anything about the quality of an organisation’s security.

What the file contains

For web services, the file is placed at the path /.well-known/security.txt on the domain, retrieved over HTTPS. The fields defined include:

• Contact, the method researchers should use to report vulnerabilities. This field must always be present.
• Expires, the date after which the data is considered stale and should not be used. This field must also be present, and the RFC recommends a value less than a year ahead.
• Policy, a link to the organisation’s vulnerability disclosure policy.
• Acknowledgments, a link to a page recognising researchers who reported issues.
• Encryption, Canonical, Hiring and Preferred-Languages, which cover encrypted reporting, the file’s own location, security jobs and languages.

Only Contact and Expires are mandatory. Everything else, including the disclosure policy, is optional.

What the RFC warns about

The security considerations section of the document is useful for anyone reading a provider’s file.

• Stale information. The RFC states that not having a security.txt file may be preferable to having stale information in it, because outdated contacts can mean reports are lost or sent to the wrong place. The Expires date is the signal to check.
• Compromised files. An attacker who compromises a website can alter the file or set up a redirect. The RFC advises organisations to use the Canonical field and digital signatures, and advises researchers to validate the file before using it.
• No implied permission to test. The RFC says researchers should not assume the presence or absence of the file grants or denies permission for security testing. Any permission may be set out in the disclosure policy.
• Limited scope. A file applies only to the domain or IP address from which it was retrieved, not its subdomains or parent domains. It may also apply to products and services provided by the organisation, so the scope depends on what the file or its policy says.

What a security.txt file cannot show

The format records how to report a problem. It does not record whether problems have been found, how quickly they were fixed, whether a test or audit has happened, or what an audit concluded. A provider with a tidy file could have a poor record, and a provider without one could have a strong record. The file is a statement by the organisation about itself, so it belongs in the “claimed” column, not the “independently verified” column.

The Acknowledgments page is the closest the format comes to evidence, since it lists researchers who have reported issues. It is still maintained by the organisation, and the RFC says only that it should list researchers who reported vulnerabilities and collaborated on fixes.

Questions worth asking about a VPN provider

• Is there a disclosure policy, and does it say which domains, apps and servers are in scope?
• Is the Expires date in the future, and does the contact still work as described?
• Is any claim about a bug bounty backed by a public programme page, rather than a marketing line?
• Is there a separate, independently published report on testing? See the guides on logging policies and independent audits and on a published audit and its limits.

Common questions

Does a security.txt file mean a VPN is more secure?

No. It describes a reporting channel. Security depends on how the service is built and operated, which the file does not address.

Can researchers test a provider’s servers because the file exists?

The RFC says researchers should not assume that the file grants permission to test. Any permission is a matter for the organisation’s own policy.

The bottom line

A security.txt file, as defined by RFC 9116, is a published statement of how to report vulnerabilities, with an expiry date, optional links to a policy and an acknowledgments page, and a scope limited to the domain that serves it. It is useful as a sign that a reporting route has been described, and the RFC itself cautions about stale data, tampering and over-reading permission. It is not a record of vulnerabilities found or fixed, and it does not replace independent testing reports. For a VPN provider, treat it as a claim about process, and look elsewhere for verification.

Sources

• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (rfc-editor.org, IETF, April 2022)

Every web request starts with a DNS lookup, and whichever resolver answers it can see the domain names requested. VPN providers often run their own resolvers, and two of the best-known alternatives are Cloudflare’s 1.1.1.1 and Google Public DNS. Both operators publish privacy statements describing what they log and for how long. This guide sets out what each statement says, and why a retention figure is a statement by the operator rather than independent proof. It is general information and does not rank resolvers or VPN services.

Why the resolver matters

Cloudflare’s documentation notes that most devices use a resolver supplied by the internet service provider by default, that some ISPs and third-party DNS providers log queries, and that DNS queries are typically sent in plaintext, so anyone on the network path can see which sites are being looked up even when page content is encrypted. Encrypted DNS changes the second point; it does not change who runs the resolver at the other end. The site’s guides to DNS leaks and to encrypted DNS cover the network-path side.

What Cloudflare states for 1.1.1.1

Cloudflare’s page for the 1.1.1.1 public resolver (the page header shows it as updated on 6 May 2026) lists commitments in its own words. Cloudflare states that it:

• will not sell or share users’ personal data with third parties, or use it to target advertising;
• will not store the source IP address in non-volatile storage, apart from randomly sampled network packets from at most 0.05% of traffic, used for troubleshooting and denial-of-service mitigation;
• anonymises source IP addresses by truncation, and deletes the truncated address within 25 hours;
• keeps limited transaction and debug logs, which are deleted within 25 hours, and shares them with no third party other than APNIC, which gets limited access to anonymised data for research.

The same page lists the log fields, which include the queried name and type, response code, data centre and country, and says aggregated statistics, such as counts of requests by region, may be stored indefinitely. It also says Cloudflare retained one of the top four accounting firms to audit its practices and publish a report, which is linked from its certifications page.

What Google states for Public DNS

Google’s privacy page for Public DNS (last updated 3 September 2024 according to the page) describes two kinds of log:

• Temporary logs are the only logs that store both the device’s IP address and the DNS query. They are subject to deletion within 24 to 48 hours, and may be kept longer solely to resolve security and abuse issues.
• Permanent logs are a sample of the temporary logs in which the IP address is replaced by a country, region and city location, no more specific than 1 square kilometre and 1,000 users. They record fields such as the requested domain name, request type, transport protocol and response code.

Google states that it does not use personal information from the service to target ads, and does not correlate Public DNS log data with other Google services except to address security and abuse.

Reading these as claims

Both pages are the operators’ own descriptions. A few distinctions help when reading any resolver or VPN logging statement, including a VPN provider’s DNS terms:

• Stated retention is a policy. Periods such as 25 hours or 24 to 48 hours describe what the operator says it does. The statements do not, on their face, say what happens if a legal demand arrives inside the retention window, and this guide makes no claim about that.
• Exceptions are part of the claim. Cloudflare’s sampled packets and Google’s longer retention for security and abuse are carve-outs in the text, so a headline such as “deleted within a day” is not the whole statement.
• An audit is only as useful as its scope. Cloudflare cites an external accounting-firm audit. Whether such a report covers every commitment listed on the page, and for what period, can be confirmed only by reading the report itself. The guide on logging policies and independent audits explains the same questions for VPN audits.
• Anonymised is not the same as absent. Both operators keep aggregated or location-level data in some form, and say so.

Where a VPN fits

Which resolver answers while a VPN is connected depends on how the VPN app and the device are configured, and on whether any queries leak elsewhere. That is why a DNS leak test is a separate check from reading a privacy statement. A provider’s own resolver adds a further party whose statement must be read: the VPN company. Switching to a public resolver can change which statement applies, but it does not make the logging question disappear.

Common questions

Does encrypted DNS stop the resolver seeing my lookups?

No. Encryption protects the path between the device and the resolver. The resolver itself still receives the query, which is why its logging statement matters.

Is a shorter retention period always better?

A shorter stated period reduces the time data is held under the operator’s policy, but the exceptions, the scope of any audit and the operator’s legal environment all affect how much weight the statement deserves.

The bottom line

Cloudflare and Google both publish specific, time-bound logging statements for their public resolvers, and the details differ: Cloudflare states 25-hour deletion of its logs, while Google states 24 to 48 hours for temporary logs and keeps location-level sampled logs. Each is the operator’s own claim, and the independent element, such as the external audit report Cloudflare refers to, needs to be read directly to see what it covers. The same approach applies to a VPN provider’s DNS and logging terms: separate what is stated from what has been independently checked.

Sources

• 1.1.1.1 Public DNS Resolver: Cloudflare’s commitment to privacy (developers.cloudflare.com)
• Your Privacy: Google Public DNS (developers.google.com)