Small businesses can use this secure remote access checklist to review VPN or ZTNA design, MFA, endpoints, network segmentation, logging and incident response. Copy the practical template into your onboarding or audit document, then revisit it whenever people, systems or threats change.
Overview
Remote access is not a single product. It is a chain of controls that starts with a user identity and ends with the application, server or data that person is allowed to reach. A business VPN can create an encrypted connection to a network, while a Zero Trust Network Access (ZTNA) service can apply access decisions per user, device and application. Neither approach removes the need for strong authentication, managed devices, sensible permissions and useful monitoring.
The right design depends on what your organisation is protecting. A small office with a few internal applications may need a carefully configured remote-access VPN. A business with cloud applications, contractors and several device types may benefit from application-level access controls. Read our guide to ZTNA versus VPN and compare the design implications before selecting a platform.
Use the checklist below as a baseline, not as a certification exercise. Record the owner for each control, the date it was last tested and any exception that remains open.
- Scope: List the users, devices, applications, networks and data covered by remote access.
- Ownership: Assign an accountable person for identity, endpoints, network controls, logging and incident response.
- Evidence: Keep configuration records, access reviews, test results and incident notes in a restricted location.
- Exceptions: Document any legacy system, unmanaged device or temporary access path that does not meet the baseline.
What to track
1. Network segmentation and access scope
Start by mapping what a remote worker can reach after authentication. Avoid treating a successful VPN login as permission to access the entire corporate network. Separate user devices, servers, administration interfaces, backups and sensitive data where practical. Apply the narrowest route and firewall rule that supports the job.
For each application, record its owner, hosting location, required ports or routes, user groups and business purpose. Remove broad rules that were created for testing or convenience. If a system cannot be segmented immediately, record it as a remediation item with a target date. For network design decisions, see client VPN versus site-to-site VPN.
2. VPN or ZTNA selection
Compare the access model with the environment rather than choosing on brand familiarity alone. Track whether the solution supports individual accounts, central identity integration, MFA, device checks, least-privilege policies, administrative separation, audit logs and rapid access revocation.
For a VPN, document the protocol, client versions, encryption settings, DNS handling, split-tunnelling decision and kill-switch behaviour. Protocol choices should be tested against your operating systems and applications; our VPN protocol comparison covers the main design considerations. For ZTNA, document which applications are published, which signals affect access and how policy failures are investigated.
3. MFA and account lifecycle
Require MFA for remote access and administrative accounts, using the strongest practical method supported by your identity platform. Enrol users through a controlled process, provide recovery codes or an alternative recovery procedure, and ensure help-desk staff cannot reset factors without verifying the request.
Track joiners, movers and leavers. New starters should receive only the access required for their role. Role changes should trigger an access review, and departures should result in prompt account disablement, session revocation and removal from remote-access groups. Include service accounts and emergency accounts in the register, with separate ownership and review dates. This VPN account security checklist provides a useful companion review.
4. Endpoint hardening
Remote access is only as trustworthy as the device using it. Define a minimum standard for supported operating systems, security updates, disk encryption, screen lock, malware protection, local firewall settings and device management. Decide whether personal devices are permitted and, if so, which applications and data they may access.
Use device compliance checks where available, but do not assume that a compliant device is permanently safe. Require re-evaluation after significant changes such as loss of management, a disabled security control or an expired certificate. Train users to report lost devices, suspicious prompts and unexpected MFA requests.
5. Logging and incident response
Record successful and failed sign-ins, MFA events, account changes, policy decisions, administrative actions, device posture failures and unusual connection patterns where your platform supports them. Synchronise time sources so events can be compared across systems. Restrict log access and define how long records should be retained according to business, contractual and regulatory requirements.
Your incident plan should answer five practical questions: who can disable an account, who can revoke sessions, who can block a device or address, where evidence is preserved, and who communicates with affected staff or customers? Test the plan with a short tabletop exercise rather than waiting for a real compromise.
Copyable onboarding template
Use this as a starting record for each remote worker:
- User, role and manager: ____________________
- Applications and networks required: ____________________
- Access model: VPN / ZTNA / other: ____________________
- MFA enrolled and recovery process confirmed: yes / no
- Device owner, operating system and management status: ____________________
- Endpoint baseline checked on: ____________________
- Access expiry or review date: ____________________
- Exceptions and approving owner: ____________________
- Last access and log review: ____________________
Cadence and checkpoints
A recurring review is more useful than a one-time deployment sign-off. Use a simple schedule that matches the size and risk of the environment.
At every onboarding or role change
Confirm the requested applications, manager approval, MFA enrolment, device status and expiry or review date. Test access from the user’s normal location and confirm that unnecessary internal resources are not visible.
Monthly
Review failed logins, unusual sign-in locations or times, dormant accounts, inactive devices, pending leavers and repeated policy failures. Check that logs are arriving and that alert ownership is clear. Review temporary exceptions rather than allowing them to become permanent.
Quarterly
Reconcile remote-access users with the HR or identity record. Review privileged access, firewall and application policies, VPN or ZTNA client versions, endpoint compliance and recovery procedures. Sample a few users and verify that their actual access still matches their role.
After a material change
Repeat the relevant checks after a major network redesign, identity-provider change, new remote-access product, significant vulnerability, merger, office move or security incident. Configuration examples and vendor notes should be reviewed when the product or protocol changes, not only on the calendar.
How to interpret changes
Do not treat every failed login as an incident, or every successful login as evidence that the design is working. Look for patterns and context. A rise in failures may indicate password spraying, a user training issue, a broken identity integration or a newly enforced policy. Repeated access from an unfamiliar device may reflect legitimate travel, device replacement or account misuse.
Prioritise changes that increase reach or reduce visibility. Examples include a new rule allowing access to a broad network range, a disabled MFA requirement, an unmanaged device gaining access, missing logs, a dormant privileged account or a temporary exception without an owner. These deserve investigation even when no confirmed breach exists.
Use test results to improve controls. If a user can connect but cannot reach a required application, check routing, DNS, policy order and application dependencies before weakening the entire security boundary. If performance is poor, measure the affected application and connection path before enabling broad split tunnelling. Any exception should state what is being accepted, why it is needed and when it will be reviewed. For related privacy checks, see this VPN privacy audit checklist.
When to revisit
Set the next review date before closing the current one. At minimum, revisit this checklist monthly for operational signals and quarterly for access, policy and ownership reviews. Revisit it immediately after a suspected breach, lost device, unexpected MFA prompt, major vulnerability, identity-system change or change in the applications exposed to remote workers.
Keep a small change log with four fields: date, change, security effect and follow-up owner. Review UK data-protection and security guidance through the relevant official sources when your processing, suppliers or access model changes; this article is practical guidance rather than legal advice. Refresh compliance links at least annually, or sooner when regulator guidance changes.
To complete the next review, take these five actions:
- Export or record the current remote-access users, groups, devices and exposed applications.
- Test MFA, account disablement, session revocation and endpoint compliance with a controlled account.
- Review segmentation and remove one unnecessary route, rule or permission if identified.
- Check that logs cover authentication, policy decisions and administrator actions, then run a short incident exercise.
- Record exceptions, assign owners and set the next monthly and quarterly checkpoints.
Remote access security improves through repeated verification. A checklist that is owned, tested and updated will provide more protection than a carefully written policy that no one revisits.
