BYOD Policy Template: Enrolment, Separation of Data and Offboarding

When staff read work email or open company files on their own phones and laptops, the organisation owns the data but not the device, and a BYOD policy has to protect one without overreaching into the other. This template sets out how personally owned devices are enrolled, how corporate data is kept separate, what the organisation can and cannot see, and how access and data are removed when a device is lost or a person leaves. It also covers a risk most BYOD policies miss: sign-in tokens and app sessions cached on personal devices, which keep working after a password change. Adapt the placeholders and have it reviewed by HR, legal and your data protection officer, because BYOD touches employment and privacy law.

How to use this template

• Replace text in square brackets, such as [Organisation], [DPO] and [90 days], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a documented exception may be justified.
• Decide first which enrolment model each device type uses (section 4.2). The UK NCSC treats the degree of management, rather than ownership, as the central BYOD question: a personal device that is fully managed is effectively a corporate device.
• Publish the privacy commitments in section 4.5 before enrolment opens: the NCSC warns that intrusive schemes push staff towards shadow IT.
• Use it with the Remote Access Policy Template and the Data Classification Policy Template.

1. Purpose

This policy sets the conditions under which personally owned devices may access [Organisation] data and services. Its aim is to protect that data on devices [Organisation] does not own, respect the owner's privacy, and remove access and data promptly when a device is lost, compromised or no longer used for work.

2. Scope

This policy applies to all workers, including contractors, who use a personal smartphone, tablet, laptop or desktop to access [Organisation] email, collaboration tools, applications, files or networks, through apps, browsers, VDI or remote access tools.

Out of scope: personal devices used only for native voice, native text or an MFA app, matching the UK Cyber Essentials v3.2 boundary. Corporate-owned devices are covered by the [Endpoint Security Policy].

3. Roles and responsibilities

4. Policy statements

4.1 Eligibility

1. BYOD access is [voluntary / available to roles listed in Annex A]. Staff who decline BYOD must be offered [a corporate device / an alternative means of access] for any work they are required to do.
2. Only devices running an operating system version still receiving security updates from its vendor, listed in the [supported platforms list], may be used. Jailbroken or rooted devices must not be used.
3. Devices must have a screen lock of at least [6-digit PIN or biometric with PIN fallback] and device encryption enabled.

4.2 Enrolment models and access tiers

1. [Organisation] uses the least intrusive model that protects the data each role needs, as set out below and in the [BYOD technical standard].
2. App protection without device enrolment is the default for smartphones and tablets. Corporate data must only be accessed in managed apps that enforce [Organisation] app protection policies.
3. Work profile or user enrolment (for example Android work profile or Apple account-driven User Enrollment) must be used where a role needs certificates, per-app VPN, Wi-Fi profiles or managed app distribution.
4. Full device management of a personal device must not be required. Staff who need it must be offered a corporate device instead.
5. Personal laptops and desktops must access [Organisation] data only through [VDI, DaaS or enterprise browser] unless approved under section 5.
6. Access to data classified [Restricted] or above from a personal device is prohibited.

4.3 Data separation

1. Corporate data must stay inside managed apps, the work profile or the remote session. App protection policies must prevent cut, copy and paste from managed apps to personal apps, prevent saving copies of organisation data to personal storage, and restrict data transfer to managed apps.
2. Corporate data in managed apps must be encrypted, and access to managed apps must require an app PIN or biometric after [30 minutes] of inactivity.
3. Screenshots and screen recording must be blocked in work apps where the platform supports it.
4. Users must not forward corporate email to personal accounts, sync corporate files to personal cloud storage, or back up corporate data to personal backups.

4.4 Access conditions and cached tokens

1. Access to [Organisation] services from personal devices must be granted only when the identity provider confirms, at each sign-in, that the app is protected by policy and the device meets the minimum operating system, patch and integrity requirements.
2. Managed apps must block access on devices that fail integrity checks (for example a jailbroken or rooted device) and after an offline period of [72 hours] without a policy check.
3. Sign-in sessions on personal devices must be limited to [7 days] before re-authentication, and refresh tokens must be revocable centrally.
4. Where the platform supports it, tokens must be bound to the device they were issued to, so that a token copied from the device cannot be replayed elsewhere.
5. Users must not store [Organisation] passwords, API keys, SSH keys or recovery codes in personal password managers or notes apps, and must not use personal devices to hold credentials for service accounts or other non-human identities.
6. Administrative and privileged access from personal devices is prohibited.

4.5 Privacy of the device owner

1. [Organisation] will only collect the device information listed in the [BYOD privacy notice], limited to what is needed for security: device model, operating system version, compliance state, managed app inventory and a device identifier.
2. [Organisation] will not access, collect or monitor personal email, messages, photos, contacts, browsing history in personal apps, personal app inventory, or device location, and the management configuration must be technically incapable of doing so where the platform allows.
3. [Organisation] will not perform a full device wipe of a personal device. Only corporate data and the work area will be removed.
4. Any change to the data collected requires [DPO] approval and notice to enrolled staff before it takes effect.
5. Owners may withdraw from BYOD at any time, which removes corporate access and data.

4.6 Lost, stolen or compromised devices

1. Owners must report a lost, stolen or suspected compromised device to [service desk] within [4 hours].
2. On a report, [IAM team] must revoke the user's sessions and refresh tokens and [IT endpoint team] must issue a selective wipe within [1 hour].
3. Where malware is suspected, the user's passwords must be reset and MFA methods reviewed, as infostealers capture credentials and cookies outside managed apps.

4.7 Offboarding and selective wipe

1. On a leaver's last working day, [IAM team] must disable the account, revoke all sessions and refresh tokens, and remove the user's registered devices from [identity provider].
2. [IT endpoint team] must issue a selective wipe of corporate data or remove the work profile on every personal device registered to the leaver, and confirm completion. Apps that have not checked in must be retried until they do or until [30 days] have passed.
3. Leavers must confirm that they hold no [Organisation] data on personal devices or accounts.
4. Devices that have not checked in for [90 days] must be removed from management and their access revoked.

5. Exceptions

Exceptions, such as access to a specific internal application from a personal laptop outside VDI, must be requested through [exception form], assessed by [Security team] and [DPO] where personal data collection changes, and approved by [CISO]. Each exception must name compensating controls and expire within [6 months]. No exception may impose full management or full wipe on a personal device.

6. Compliance and monitoring

[IT endpoint team] will report the following to [risk committee] [quarterly]:

Devices that do not meet this policy may lose access to [Organisation] services without notice. Breaches by staff may be handled under [disciplinary procedure].

7. Review and approval

This policy is owned by [CISO] and approved by [approving body] after consultation with [HR], [Legal] and [DPO]. It is reviewed at least annually, and whenever the management platform, the data collected from devices or the supported platforms change.

Implementation guidance

Choosing the enrolment model

• App protection for most phones: app protection policies protect corporate data inside managed apps without enrolling the device; management follows the user identity. In Microsoft Intune, for example, settings include "Restrict cut, copy, and paste", "Save copies of org data", an app PIN and conditional launch checks (minimum OS version, Play Integrity verdict, offline grace period). Pair them with the Conditional Access grant "Require app protection policy"; Microsoft is retiring the older "Require approved client app" grant.
• Work profile or user enrolment when you need more: the Android work profile isolates work apps and data and lets administrators wipe work data only. Apple account-driven User Enrollment limits IT to the organisation's accounts and a restricted set of settings, never the personal account.
• Laptops through a remote session: desktop app protection is narrower, so VDI or an enterprise browser is usually more practical. See the Virtual Desktop (VDI) and DaaS Security Guide and the Enterprise Browser and Browser Security Guide.
• Small organisations: start with tiers A and B; larger or regulated organisations add tier C for specific roles.

Why wipe scope and tokens matter

A full device wipe factory resets the device and removes personal data, so section 4.5.3 prohibits it. Selective wipe removes only corporate app data; in Intune, apps check for a pending wipe about every 30 minutes and at launch, so an offline device keeps its data until it reconnects. Wiping data does not end sessions, so revoke tokens in the identity provider at the same time. Token binding, such as Microsoft Entra token protection, reduces replay but covers limited apps and platforms. See the Token and Session Security Guide and the Session Hijacking and Cookie Theft Guide.

Unmanaged personal and contractor devices are a known source of stolen credentials. In the Snowflake campaign, infostealer logs supplied the passwords used,, some from contractors' laptops. See the Snowflake Breach 2024.

Rolling it out

1. Find current use: review sign-in logs for unmanaged devices and legacy mail clients that bypass app protection.
2. Complete the DPIA and privacy notice: confirm the configuration collects only what section 4.5 allows.
3. Build policies in report-only mode: create the app protection and access policies, run them in report-only or warn mode for [2 weeks] with an IT pilot group, and review blocked sign-ins.
4. Pilot with a business group: enrol a volunteer group, test selective wipe on a test device, and time the lost device process end to end.
5. Enforce in rings: extend to all users department by department. Keep a time-limited exclusion group as the rollback path, reviewed weekly.
6. Join it to the leaver process: add token revocation and selective wipe to the HR leaver workflow. See the Employee Offboarding Security Guide.

Common failure patterns

• Wiping data but not sessions: the device is wiped, yet a browser session or refresh token on another personal device still works.
• Legacy protocols left open: unmanaged mail clients bypass app protection.
• Over-collection: enrolment profiles that collect personal app inventory or location, which damages trust and data minimisation.
• Credentials outside managed apps: API keys and service account passwords stored in personal notes apps, out of reach of any wipe.

Framework mapping

Standards and references

• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• NIST: SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
• NCSC: Device Security Guidance, Bring Your Own Device
• NCSC: Cyber Essentials Requirements for IT Infrastructure v3.2
• Microsoft Learn: App protection policies overview
• Microsoft Learn: Conditional Access grant controls
• Apple: User Enrollment and device management
• Google: Android Enterprise work profile requirements

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Mobile Device Security Guide · Device Trust and Posture Guide · ZTNA Guide · SASE and SSE Guide · Conditional Access Guide