Secure Remote Work for Regulated Teams: The Definitive Guide

Written byHubSecure Editorial Team

Security and compliance guides for IT leads, operations managers, and risk officers at regulated firms.

Reviewed byHubSecure Security & Compliance Review

Reviewed against ISO 27001, NIST CSF, FCA operational resilience guidance, and GDPR remote working requirements.

Last updatedJuly 11, 2026

Updated to reflect current ZTNA market maturity, FCA hybrid working expectations, and 2026 cyber incident reporting requirements.

The new reality of regulated remote work

The regulated professions were among the last to embrace remote working, and for understandable reasons: client confidentiality, information security, supervision obligations, and regulatory expectations all create real complexity when staff are not in the same building as the systems and documents they work with. But the shift has happened. The question is no longer whether regulated work happens remotely — it does. The question is whether the controls that protect it have kept pace with how the work is done.

Most have not. The remote working arrangements that were deployed at speed in 2020 were emergency measures — functional but not robust. They were typically VPN access bolted onto existing infrastructure, video calls via whatever platform staff had on their phones, and an implicit understanding that the usual information security rules still applied even though the usual enforcement mechanisms did not. Five years later, many firms are still operating on those emergency foundations, now quietly calcified into unofficial policy.

Regulators are increasingly explicit that this is not acceptable. The FCA's operational resilience framework expects firms to maintain the same service and compliance standards from any location. GDPR's security obligations — appropriate technical and organisational measures to protect personal data — apply regardless of where processing takes place. And the practical reality is that remote environments introduce attack surfaces and compliance risks that simply do not exist in a managed office: home WiFi networks, personal devices, uncontrolled physical environments, and the gravitational pull of convenience tools that are not on the approved list.

Device security: MDM, encryption, and remote wipe

The device is the perimeter in a remote working environment. In an office, physical access controls, network segmentation, and the proximity of IT staff provide a backstop. At home or in a coffee shop, the device itself is often the only layer standing between your client data and the network it is connected to.

Mobile Device Management (MDM)

Every device used to access firm systems and data — laptops, tablets, smartphones — must be enrolled in a Mobile Device Management solution. MDM gives your IT team the ability to:

• Enforce configuration baselines — operating system version, encryption status, screen lock settings, firewall status, approved application list
• Push security policies remotely — require OS updates, push certificate renewals, enforce password complexity requirements
• Monitor compliance status — receive alerts when devices fall out of compliance (unenrolled devices, overdue OS updates, disabled encryption)
• Wipe devices remotely — remove firm data from a device that is lost, stolen, or used by a departing employee, without physically possessing the device

Leading MDM platforms include Microsoft Intune (tightly integrated with Microsoft 365 and Entra ID), Jamf (Apple-first), and Kandji. For most regulated firms already using Microsoft 365, Intune is the path of least resistance and the most cost-effective option.

Encryption at rest

Full-disk encryption must be enforced on all firm devices. On Windows, this means BitLocker enabled and key escrowed to the firm's Entra ID or Intune instance. On macOS, it means FileVault enabled and recovery key escrowed. Encryption ensures that if a device is physically lost or stolen, the data on it cannot be accessed without the encryption key — which the thief does not have.

Encryption at rest does not protect data while the device is powered on and unlocked. It protects it when the device is powered off or the drive is removed. This is why screen lock (automatic, after no more than five minutes of inactivity) and strong authentication are equally important.

Remote wipe capability

MDM provides remote wipe — the ability to factory-reset a device or selectively remove firm data (without wiping personal data) from any enrolled device. Remote wipe must be tested before you need it, not after. Your incident response procedure for a lost or stolen device must include a defined timeframe within which remote wipe is initiated — typically within two hours of the loss being reported.

Personally owned devices (BYOD)

Personally owned devices present a particular challenge. Staff have a reasonable expectation of privacy on their personal devices; firms have an obligation to protect client data that the device may access. The cleanest solutions are:

• Firm-provided devices only: No personal devices access firm systems. All staff receive a firm-managed device. This is the most secure approach and the easiest to enforce and audit.
• Virtual desktop infrastructure (VDI): Staff access a virtualised desktop environment in which firm data is processed; nothing is stored on the local device. The personal device is merely a screen and input device — all processing and storage happens in the firm's controlled environment. Appropriate for firms with budget for VDI infrastructure.
• MDM with selective wipe on BYOD: Personal devices are enrolled in MDM, but only for the management of a corporate partition. Selective wipe can remove firm data without touching personal data. This requires careful communication with staff about what MDM can and cannot see on personal devices, and clear consent.

Network security: VPN vs ZTNA and the home WiFi problem

The problem with home WiFi

A staff member's home WiFi network is, from a security perspective, an untrusted network. It is shared with household members. The router is likely running firmware that has not been updated in years. The password may be the default that came printed on the label. Other devices on the same network — smart TVs, IoT devices, games consoles — are potential pivot points for an attacker who gains access to the network. None of this is under your control.

The correct approach is to treat home WiFi as equivalent to a public WiFi network: untrusted, potentially hostile, and requiring the same controls you would apply if the staff member were working from a coffee shop. Every connection from a home network to firm systems should be encrypted in transit, and access to sensitive systems should require authentication that does not depend on network location.

VPN: what it does and what it does not do

A Virtual Private Network (VPN) creates an encrypted tunnel between the remote device and the firm's network. Traffic within that tunnel is protected from interception on the local network. VPNs are effective at protecting data in transit and at preventing local network eavesdropping.

What a VPN does not do: it does not verify that the device connecting through it is secure and compliant. Once a device authenticates to the VPN, it typically has broad access to everything on the firm's network — just as if it were a device in the office. This "once inside, trusted everywhere" model is the fundamental weakness of VPN-based remote access. A compromised device authenticated to the VPN has the same access as a clean device. This is why VPNs alone are not sufficient for high-security environments, and why ZTNA has emerged as the architectural successor.

Zero Trust Network Access (ZTNA)

Zero Trust Network Access is an architectural approach based on the principle that no user, device, or network connection should be automatically trusted — every access request must be authenticated and authorised based on who is asking, from what device, in what state, for what resource.

In a ZTNA model:

• Access is granted to specific applications and resources — not broad network access
• Every access request is evaluated against policy: is the user authenticated with MFA? Is the device enrolled in MDM and compliant? Is the access request consistent with the user's normal patterns?
• Lateral movement is prevented — a compromised account or device cannot freely access other systems on the network, because there is no implicit trust granted by being "inside" the perimeter
• Access is logged at the application level — every access event is recorded, providing the audit trail that compliance requires

ZTNA platforms include Cloudflare Access, Zscaler Private Access, Microsoft Entra Private Access, and Palo Alto Prisma Access. For firms already on Microsoft 365 and Entra ID, Microsoft's ZTNA capabilities are increasingly competitive and deeply integrated with the existing identity stack.

Capability	Traditional VPN	ZTNA
Encrypts data in transit	Yes	Yes
Device compliance verification	Basic (certificate)	Full MDM posture check
Access scope	Broad network access	Per-application, least privilege
Lateral movement prevention	No	Yes
Application-level audit logging	Limited	Yes
Works without a perimeter	No	Yes
Implementation complexity	Lower	Higher
Suitable for <50 staff	Yes	Yes (cloud-native options)

Data handling, classification, and DLP

Data classification

Your staff cannot protect data they cannot categorise. A data classification scheme defines how data should be handled based on its sensitivity — typically across three or four tiers:

• Public: Information that is intentionally public or would cause no harm if disclosed — marketing materials, published reports, job postings
• Internal: Information that should only be accessed by firm staff — internal policies, operational procedures, staff directories
• Confidential: Client data, financial data, personnel data, strategic plans — information whose disclosure could cause harm to clients, staff, or the firm
• Restricted / Highly Confidential: Information subject to legal privilege, specific regulatory requirements, or whose disclosure would cause serious harm — matter documents in litigation, AML reports, M&A work product, personal health information

Classification should be applied at document and email level where practical. Microsoft 365 sensitivity labels, integrated with Purview, provide a workable mechanism for automated and user-applied classification that then drives DLP policy enforcement.

Data Loss Prevention (DLP)

Data Loss Prevention tools monitor and control the movement of data — preventing staff from sending client files to personal email, uploading confidential documents to personal cloud storage, or printing sensitive data without a logged record. DLP is not a surveillance tool; it is a policy enforcement mechanism.

Key DLP controls for remote regulated teams:

• Block or alert on email forwarding of classified data to external personal email addresses
• Block upload of classified data to non-approved cloud storage (personal Dropbox, personal Google Drive)
• Block copy-paste from firm applications to personal applications where technically feasible
• Require justification for printing classified documents (in managed print environments)
• Alert on unusual bulk download or export activity that may indicate exfiltration

Approved application list

Every regulated firm should maintain and enforce an approved application list — the tools that are authorised for use with firm data, have been through a procurement security review, and are covered by appropriate data processing agreements. Any application not on the list is not approved for use with firm data. This needs to be stated clearly in your policy, communicated to staff, and enforced through MDM (blocking installation of unapproved apps on firm devices) and DLP (blocking data transfer to unapproved services).

Communication security and shadow IT

The shadow IT problem

Shadow IT refers to applications and services used by staff without IT approval or awareness. In a remote working environment, shadow IT proliferates because the friction of doing things the "proper" way is higher — you cannot walk down the corridor to ask IT for help, and the approved tools may feel slower or less convenient than the consumer alternatives staff use in their personal lives.

Common shadow IT in regulated firms includes:

• Personal WhatsApp for client communications (not encrypted at rest on firm systems, no audit trail, data stored in staff member's personal account)
• Personal Gmail or Outlook.com for work emails (completely outside firm control and DLP)
• Personal Dropbox or Google Drive for sharing or storing work files (outside data residency controls, no access audit, no DLP)
• Consumer video conferencing tools (Zoom personal accounts, FaceTime) for client meetings (no meeting recording in firm-controlled storage, no attendee verification)
• AI assistants and generative AI tools that process client data through third-party APIs without a DPA in place

Shadow IT is not primarily a technology problem — it is a workflow problem. Staff reach for unapproved tools because the approved tools are inadequate, unavailable, or more inconvenient. The correct response combines policy enforcement with genuine improvement of the approved tool experience: if staff are using WhatsApp for client communications because your firm's approved messaging platform is inferior, fix the approved platform rather than just banning WhatsApp.

Governed messaging for client communications

Client communications must occur through channels that provide: end-to-end or transport encryption; message retention under firm control; access logging; the ability to export communications for regulatory inspection; and data storage that meets your data residency obligations. Consumer messaging apps meet none of these requirements. Your firm needs an approved client communication platform — whether that is a secure client portal, a governed messaging layer, or a firm-managed email system with DLP — and that platform must be the only channel through which client communications happen.

Client meetings: video security and recording consent

Platform security requirements

Your video conferencing platform for client meetings must meet a higher standard than the consumer tools staff use for personal calls. Requirements include:

• End-to-end encryption: Ideally E2EE for all meetings involving privileged or sensitive client information. At minimum, transport encryption (TLS) for all connections
• Meeting access controls: Waiting rooms or lobby controls that prevent unverified participants from joining; password protection for all external meetings; host control to remove attendees
• Recording storage under firm control: If meetings are recorded, recordings must be stored in firm-controlled storage, not in the platform's cloud storage which may not meet your data residency or data processing requirements
• Data residency: For EEA clients, client meeting data processed through a US-headquartered video platform may constitute a cross-border data transfer that requires SCC documentation
• Identity verification: For high-sensitivity meetings, consider requiring authenticated login rather than a link-based join, to ensure participants are who they claim to be

Recording consent obligations

Recording a client meeting without consent is, in most jurisdictions, an unlawful interception of communications, a potential criminal offence, and almost certainly a breach of your professional obligations. Before recording any client meeting:

• Obtain explicit consent from all participants at the start of the meeting — not buried in terms of service, but stated clearly and acknowledged verbally or in chat
• Inform participants of the purpose for which the recording will be used — for internal training? For file notes? For sharing with absent colleagues?
• Inform participants of how long the recording will be retained and who will have access to it
• Provide a mechanism for participants to object to recording — if a client objects, you must either not record or provide the meeting in an unrecorded format

These requirements flow from GDPR (for EEA participants), the Investigatory Powers Act 2016 (for UK participants), and parallel legislation in other jurisdictions. Automatic recording of all calls without per-call consent is typically not permissible in regulated professional services contexts, even when notice is provided in terms of engagement.

Physical security: clean desk and screen privacy

Physical security is the layer of remote working security most frequently overlooked because it is invisible to technology controls. No MDM, VPN, or DLP tool can prevent a client's personal data from being seen by a household member walking past an unlocked screen, or prevent a confidential document left on a desk from being read by a visitor.

Clean desk in a home office context

The clean desk principle — no confidential documents left unattended at an unlocked workstation — must be adapted for the home working environment. This means:

• Printed client documents must be stored in a locked drawer or cabinet when not in use, and shredded (cross-cut) when no longer needed — not placed in household recycling
• Screens must auto-lock after a defined idle period (five minutes maximum) and manual lock must be habit before any absence from the desk
• Client calls and video meetings should not take place in shared rooms where household members may overhear client information
• Physical mail received at a home address that contains client or business information must be treated with the same security as office mail — stored securely, not left in shared household spaces

Screen privacy

Privacy screens — physical filters that restrict viewing angles so only the person directly in front of the monitor can see the screen — are inexpensive and effective for staff who work in shared spaces or co-working environments. For staff who regularly work from cafes, trains, or open-plan co-working spaces with client data on screen, privacy screens should be mandatory, not optional.

Audit readiness while remote

Audit readiness means being able to demonstrate, on demand and retrospectively, what happened to client data — who accessed it, when, from where, what they did with it, and whether they were authorised to do so. In an office environment, physical access controls, shared systems, and proximity to IT provide a baseline of visibility. In a remote environment, that visibility must be explicitly built into your tooling and processes.

The controls that make remote work auditable are:

• Centralised identity and access management: All access to firm systems is gated through a single identity provider (Microsoft Entra ID, Okta, etc.) that logs every authentication event — user, device, time, location, and whether MFA was used
• Application-level audit logging: Every action within client-facing and compliance-critical applications is logged at the user level, not just the session level. Who opened a file, who exported it, who shared it — all logged with timestamps
• Immutable log storage: Audit logs must be stored in a tamper-evident system that staff cannot modify. Logs stored in the same system that staff use for daily work are not audit logs — they are notes
• Defined log retention: Audit logs must be retained for a period consistent with your regulatory requirements — typically a minimum of six months for active monitoring and three to seven years for archival, depending on the type of regulated activity
• Regular log review: Logs that are collected but never reviewed provide forensic value after an incident but no preventive value. A defined process for regular log review — automated alerting for anomalies, periodic manual review of access patterns — is part of a functioning audit programme

Remote work policy template outline

Every regulated firm with remote workers needs a written remote work policy that has been reviewed, approved by senior management, and communicated to all staff. The following outline covers the essential sections. Each section should include the specific rules that apply, who is responsible for enforcing them, and the consequences of non-compliance.

1. Scope and applicability — who the policy applies to; what work locations it covers (home, co-working, travel); what it does not cover
2. Approved devices — which devices are permitted; MDM enrollment requirements; personally owned device policy (BYOD rules or prohibition)
3. Network security — VPN or ZTNA requirements; home WiFi minimum requirements; prohibition on public WiFi without VPN; travel security requirements
4. Data classification and handling — classification scheme; rules for handling each classification level remotely; printing restrictions; approved storage locations
5. Approved applications — approved tool list; process for requesting approval for new tools; explicit prohibition on personal email, personal cloud storage, and unapproved messaging apps for work purposes
6. Client communications — approved channels for client contact; prohibition on personal communication channels; video meeting security requirements; recording consent requirements
7. Physical security — clean desk requirements; screen lock requirements; screen privacy in public locations; visitor and household member controls during client calls
8. Incident reporting — what constitutes a reportable security incident; how to report (contact, channel, timeframe); obligation to report lost or stolen devices within a defined timeframe
9. Monitoring and compliance — disclosure of what monitoring takes place on firm devices; how compliance with the policy is checked; consequences of non-compliance
10. Review cycle — who owns the policy; how often it is reviewed; how changes are communicated

Onboarding remote staff securely

Remote onboarding is a security high-risk moment. It is the point at which a new employee's identity is least verified, the employment relationship least established, and access to firm systems most broadly granted for the first time. The risk of social engineering attacks (fake employee onboarding), credential harvesting, and insider threat is all elevated in the first weeks of employment — and remote onboarding removes many of the in-person controls that would otherwise mitigate these risks.

Secure remote onboarding requires:

• Identity verification before access is granted: The new employee's identity must be verified before their credentials are created and access is granted — not as a parallel process. This typically means a video call during which they present their identity documents to the HR lead, or use of an electronic identity verification service that produces a documented result.
• Device shipped to verified home address: The firm device must be shipped to the address confirmed during the pre-employment identity verification — not to an address provided by the new employee after hire. The shipping confirmation provides the audit trail.
• Phased access provisioning: New employees should not be granted access to all systems on day one. Access should be provisioned progressively as each system access is required and the employee has been briefed on the security requirements for that system.
• Security awareness before any access: The remote work policy, information security policy, and data handling requirements must be read and acknowledged by the new employee before their accounts are activated and devices are shipped — not at some point during their first week.
• Buddy or manager check-in during first two weeks: New remote employees should have daily or every-other-day check-ins during their first two weeks, partly for integration but also to establish the routine of raising questions — including security questions — with their manager rather than attempting to solve problems themselves in ways that may introduce risk.

Implementation timeline

For a firm of 10–50 people implementing or overhauling secure remote work controls from scratch, the following timeline reflects a realistic phased approach. Larger firms or those with existing tooling may compress some phases.

Secure remote work policy checklist

Frequently asked questions

Our staff want to use personal smartphones to check work email while travelling. Is this permissible?

It can be, under the right controls — but not by default. Accessing firm email on a personal smartphone without MDM enrollment and without MFA means that if the phone is lost, anyone who picks it up has access to your firm's email. At minimum, personal smartphones used for work email must have screen lock enabled, and the email application must be configured to allow remote wipe of the work account separately from the personal data on the device. Many MDM platforms support this through a "managed email profile" approach. The cleaner solution is to issue firm devices or to require MDM enrollment of personal devices as a condition of any work use.

How do we handle it when a staff member leaves and their firm laptop cannot be returned immediately?

When a staff member leaves, their access must be revoked immediately — on their last day, or earlier if the departure is involuntary. This means disabling their account in your identity provider, which cascades to all connected systems. The device itself should follow — shipped back within an agreed timeframe (five to ten business days is typical) — and a remote wipe should be initiated if it is not returned within that period. Never rely on a departing employee to delete firm data themselves. The MDM remote wipe provides certainty that data has been removed regardless of what the employee has or has not done. This sequence — access revoke first, device return second, remote wipe as fallback — should be documented in your offboarding procedure.

We are a small firm and cannot afford enterprise ZTNA solutions. What is the minimum viable secure remote access setup?

For a small firm without the budget for full ZTNA, the minimum viable configuration is: a reputable business-grade VPN (not a consumer VPN) with MFA enforced; all devices enrolled in MDM with encryption and screen lock enforced; Microsoft 365 or Google Workspace with Conditional Access policies that block access from non-compliant devices; and DLP configured to prevent email forwarding of sensitive data to personal addresses. This is not as robust as ZTNA, but it addresses the most common attack surfaces for small firm remote workers. Many of these controls are available within Microsoft 365 Business Premium or Google Workspace Business Plus at a cost that most small firms can justify as part of their IT budget.

Do we need to disclose to clients that our staff work remotely?

In most cases, there is no statutory obligation to disclose to clients that staff work from home. However, your data protection obligations require you to have appropriate security measures in place wherever processing occurs — and your professional obligations require you to maintain client confidentiality regardless of where work is done. Some clients, particularly institutional clients or those with their own strict information security policies, may have contractual requirements about where their data is processed and by whom. Review your client contracts and data processing agreements. If a client's data is being processed in a home environment and that raises questions about your contractual commitments (for example, a data processing agreement that specifies an office address as the processing location), you should seek legal advice on whether disclosure or amendment is required.

What should we do if a staff member reports that their device has been lost or stolen?

Treat it as a potential data breach from the moment of report. Initiate remote wipe immediately through MDM. Revoke the staff member's credentials and issue new ones after verifying their identity through a secondary channel. Assess what data may have been on the device or accessible through the device. If client personal data or firm confidential data was at risk, assess whether you have a reportable data breach under GDPR (notification to the supervisory authority within 72 hours if the breach is likely to result in risk to individuals) or other applicable breach notification requirements. Document the entire chain of events — when the loss was reported, when remote wipe was initiated, the result of the wipe attempt, and the breach risk assessment. Even if you conclude no notification is required, you must document that conclusion and the reasoning behind it.

Reviewed for regulated teams

Prepared by the HubSecure editorial team for IT managers, compliance officers, and operations leads at law firms, accounting practices, and financial services firms managing remote or hybrid teams. This guide is for informational purposes and does not constitute legal or information security advice. Consult qualified professionals for advice specific to your organisation.

Authors · Reviewers · Editorial policy