A VPN changes part of the route and trust arrangement of a network connection. It does not automatically make every activity anonymous or every website trustworthy. Start by identifying the specific problem you want the VPN to address.
The UK’s NCSC describes VPNs as encrypted connections across an untrusted network, including access to an organisation’s services. That description explains a connection function, not a universal guarantee about a consumer service’s logging or data practices.
Describe the job the connection needs to do, such as reaching an organisation’s resources. Then draw the relevant route and identify the part the proposed VPN changes. This gives the product’s documented features a practical context in the setup.
Draw the relevant path
List your device, the VPN endpoint and the destination service. Then identify which account, software and network operator are involved. For workplace access, follow the organisation’s supported configuration instead of substituting an unrelated consumer product.
Check the documented role and protection provided by each part of the connection path.
Ask specific questions
| Requirement | What to inspect |
|---|---|
| Organisational access | The supported service and permitted use |
| Connection protection | What the documented configuration encrypts |
| Provider trust | Applicable data handling and logging terms |
| Device coverage | Which applications and devices use the connection |
| Failure behaviour | What the product says happens if it disconnects |
Actual routing and configuration need checking. Check which applications and traffic the documented configuration routes through the VPN.
Judge it against the intended use
Review the service’s documentation and applicable account terms. A VPN does not remove the need to assess the destination, protect accounts or maintain the device. If the goal cannot be stated more precisely than be safe online, define the requirement before buying a product or declaring that it has been met.
Draw a route for a specific use
For a fictional work-access example, list the device, the supported VPN connection and the organisation’s destination service. Note which documentation describes the connection and who administers it. This gives the setup a clear purpose that can be checked after configuration.
For a consumer service, replace the organisational details with the provider’s documented arrangement and the destination activity. The relevant questions then include which traffic is routed, the provider’s stated practices and the features required by the user.
Make a comparison record
| Field | What to collect |
|---|---|
| Intended use | The resource or activity involved |
| Supported devices | Exact platforms required |
| Routing | Documented treatment of the relevant traffic |
| Provider terms | Applicable data-handling information |
| Interrupted connection | Documented behaviour and available controls |
After a supported setup, check the intended activity and record the configuration used. Questions about an application outside that route need their own documented answer. Keep product claims beside the feature or connection detail they describe, so they can be assessed individually.
If the VPN is required for work, follow the organisation’s instructions and support route. A personal product comparison should remain separate from permission to change an organisation’s access arrangement.
A before-and-after route drawing can include the device, VPN provider and destination service. Place questions about access, provider practices and required features beside the relevant part. The drawing becomes a compact reference for comparing the configuration with the intended use.
Sources consulted
- Device security guidance: Virtual Private Networks — UK National Cyber Security Centre; consulted 3 November 2026.