This practical guide shows UK organisations what to document when employees use a VPN or similar secure remote access service to reach business systems. It provides a repeatable DPIA structure, an annual access-control review, and monthly or quarterly checkpoints for authentication, devices, suppliers, logging, retention, incidents and offboarding. It is an operational guide, not legal advice; confirm the current requirements and terminology with your privacy adviser and the latest guidance from the relevant UK regulator.
Overview
A VPN is a technical control, not a complete compliance solution. It can create an encrypted connection between an employee’s device and a company network or service, but it does not by itself establish that the user is authorised, the device is safe, access is limited, or personal data is handled lawfully. A UK GDPR review should therefore document the complete remote-access arrangement rather than simply record that “a VPN is in use”.
Start by defining the processing activity. A useful description might be: “Remote employees access specified business applications and network resources from managed or approved devices using an authenticated remote-access service.” Record which systems are involved, what categories of personal data may be viewed or transferred, who uses the service, and why remote access is necessary.
Keep legal decisions separate from operational decisions. The organisation should identify its lawful basis, transparency obligations, controller and processor roles, and any special-category or criminal-offence data considerations through its normal privacy process. IT should then document the controls that support those decisions, such as multi-factor authentication, device checks, least-privilege groups, session logging and account removal. A DPIA may be appropriate where the proposed processing is likely to create a high risk to individuals, but the organisation should assess that question using the current regulatory framework rather than treating every VPN deployment as automatically requiring one.
For context, compare the proposed design with the ZTNA versus VPN decision matrix and the secure remote access checklist for small businesses. A traditional VPN may provide broad network connectivity, while a more granular approach may restrict access to named applications. The right choice depends on the systems, users, risk and operating model.
What to track
1. Purpose, scope and data flows
Record the business purpose, user groups, locations, applications, environments and data types covered by the remote-access service. Map the main flow from employee device to VPN or access gateway, identity provider, internal network, cloud application and logging platform. Note where authentication data, device identifiers, IP addresses, connection timestamps and activity logs are created.
For each data item, record whether it is necessary for security or administration, who can access it, how long it is retained, and whether it is shared with a supplier. Avoid describing the VPN as a sealed tunnel that eliminates all data-protection concerns: the gateway, endpoint, identity system and destination application may each process personal data.
2. Lawful basis, transparency and responsibilities
Document the organisation’s chosen lawful basis for the relevant processing and the reasoning behind it. Link the activity to the privacy notice, employee monitoring information and internal policies where applicable. If connection or security logs may be used for investigation, performance management or another secondary purpose, record that purpose separately and check whether the existing transparency information covers it.
Identify the controller, processor and subprocessor position for each service. Keep a supplier register containing the provider’s legal entity, processing locations, support access model, security documentation, contract status and notification route for changes. Do not assume that a vendor’s statement that it has a “no logs” policy describes every log generated by the business’s own gateway, identity provider or endpoint platform.
3. Authentication and account lifecycle
Record how users authenticate, whether multi-factor authentication is required, which factors are accepted, and how recovery is controlled. Include privileged administrators, contractors and service accounts rather than reviewing only ordinary employees. Document session timeouts, failed-login handling, device registration and the process for replacing a lost authentication device.
The access review should contain a user-by-user export or controlled report with the account owner, department, manager, role, last use, assigned groups, device status and approval date. Managers should confirm that each person still needs access and that the permission level is appropriate. A dormant account is not necessarily safe merely because it has not been used; it may still be exploitable unless disabled or removed.
4. Device posture and least privilege
Define the minimum device conditions for remote access. These might include supported operating-system versions, active security updates, disk encryption, screen-lock settings, endpoint protection, an approved configuration and the ability to revoke access when the device is lost. State whether personally owned devices are allowed and, if so, what data and applications they may access.
Review network permissions by role and application. Where practical, prefer application-specific access over unrestricted reachability across the internal network. Check split-tunnel decisions, administrative interfaces, development systems and production systems separately. The split-tunnelling guide can help teams document which traffic uses the protected route and why.
5. Logging, retention and incident response
List the events recorded by the VPN, identity provider, endpoint platform and destination systems. Typical examples include successful and failed authentication, privilege changes, configuration changes, connection start and end events, device posture failures and administrator actions. Define who reviews alerts, what constitutes an investigation trigger, and how logs are protected from unauthorised alteration.
Choose retention periods based on documented business, security, legal and regulatory needs. Avoid copying a generic period without explaining the purpose. Record the retention owner, deletion method, backup treatment and exception process. Your incident plan should cover stolen devices, credential compromise, unusual access, a misconfigured gateway, supplier notification and potential personal-data breaches. The VPN is one part of the response; identity and application logs may be needed to establish what was actually accessed.
6. Offboarding and supplier change
Set a target for removing access when employment or a contract ends, and define who owns the decision when the departure is urgent. The checklist should include VPN accounts, identity groups, certificates, recovery methods, active sessions, managed devices, privileged credentials and third-party accounts. Confirm that revocation has completed rather than relying on a ticket being closed.
For suppliers, track contract renewal dates, material service changes, new subprocessors, processing locations, authentication changes and changes to logging or retention. A platform migration or new identity provider may require a DPIA review even if the business purpose has not changed.
Cadence and checkpoints
Use a simple review calendar with named owners and evidence links. A monthly operational check can cover failed-login trends, unusual locations, inactive accounts, endpoint compliance, urgent patches, open incidents and access requests awaiting approval. It should be short enough to complete consistently and should produce actions, not just a dashboard screenshot.
Run a quarterly control review covering role and group membership, privileged access, device exceptions, split-tunnel rules, firewall or application policies, log visibility, supplier changes and unresolved risk acceptances. Sample a selection of users and compare their approved role with their actual permissions. Include at least one leaver and one joiner in the test so that the lifecycle process is checked in practice.
Complete a formal access recertification at least annually, or more often for sensitive systems. Ask managers to approve, reduce or revoke access, and require a reason for exceptions. Record the reviewer, date, evidence, decision and completion status. The review should also test whether former users, temporary accounts and shared accounts are still present.
Trigger an out-of-cycle review after a data-flow change, major supplier update, security incident, acquisition, new country of operation, new category of personal data, change to employee monitoring, or move from a VPN to a zero-trust access model. A client VPN versus site-to-site VPN comparison may help when the design itself is changing.
How to interpret changes
Do not treat every increase in VPN connections as a compliance failure. More connections may reflect recruitment, a new hybrid-working policy or a system migration. Look for changes in context: Are new users accessing more sensitive applications? Are privileged sessions increasing? Are failed logins concentrated in one group? Are devices connecting without the required posture? Is the organisation collecting more detailed activity data than it needs?
Classify findings by impact and urgency. A missing manager approval, an expired device certificate and a suspected credential compromise should not share the same queue. For each finding, record the affected users or systems, the personal-data implications, the immediate containment step, the owner, the due date and whether residual risk has been accepted.
Pay particular attention to exceptions. An exception may be justified for a specialist device or emergency access, but it should have an owner, an end date, compensating controls and a review date. Permanent exceptions usually indicate that the standard has not been designed for the actual business need.
When to revisit
Put the next review date directly into the DPIA, access register and supplier record. At minimum, revisit the operational checklist monthly or quarterly according to risk, complete a documented access recertification annually, and update the assessment whenever the data flow, technology, supplier or processing purpose changes.
Before each review, gather the latest user and group export, device-compliance report, authentication events, incident register, supplier notices and open-risk log. After the review, update the DPIA where the processing description or risk assessment has changed, refresh employee-facing information if necessary, and close or formally accept each action.
Finish with a short management summary: what changed, what personal data is involved, which controls worked, which exceptions remain, and what must happen next. This creates an audit trail that is useful to privacy, IT and security teams without pretending that a VPN alone makes remote work compliant.
For practical account controls, use the VPN account security checklist. Recheck the current UK GDPR and regulator guidance before approving a material change, and keep this article’s template aligned with your organisation’s own policies, contracts and risk appetite.
