BYOD and Cyber Essentials, the 15-Minute Scope Decision Tree

Net Sec Group is an IASME and NCSC certification body. Across our 800-plus engagement history, BYOD scoping is the single highest-frequency ambiguity we see on scoping calls. Founders arrive thinking BYOD is binary (in or out) and find the actual rule depends on the data the device touches and the path it takes. This article is the 15-minute Cyber Essentials BYOD decision tree, six yes/no nodes, with the IASME rule behind each and the practitioner answer.

The article sits on the scope-decisions hub. For the deeper implementation detail on BYOD policy and device classification, the netsecgroup.io BYOD Policy Implementation Guide and BYOD Device Classification are the technical references.

Why BYOD scope is hard to call without a decision tree

The IASME rule for BYOD is a single sentence: a personal device that handles in-scope data is in scope. The hard part is determining what counts as "handles in-scope data" and what counts as "out of scope by virtue of the access path". Three founders with broadly similar setups arrive at three different scope statements because the access path differs. The decision tree below makes that path explicit.

What the tree does not do: it does not replace the netsecgroup.io BYOD policy guide. The tree decides whether a device is in scope; the policy guide tells you how to evidence the in-scope devices once you know.

The 6-node decision tree

Run the tree once per device class (employee phones, employee laptops, contractor phones, contractor laptops, founder hardware, customer devices). Each device class lands at one of three outcomes: out of scope, in scope as a managed device, or in scope as a BYOD device with specific evidence requirements.

Node 1: Does the device access organisational data outside a sandboxed app?

The IASME rule: in-scope data accessed by the device makes the device in scope.

Practitioner answer: this is the parent question. If the answer is no (the device never touches organisational data, ever), the device is out of scope and the tree ends. The recurring cases where the answer is genuinely no: a customer phone, a personal device of a household member, a contractor's personal device on a non-corporate engagement.

If yes, continue to Node 2.

Node 2: Does the device access data only via a sandboxed container that wipes on disconnect?

The IASME rule: a Mobile Application Management container with no native data sync, no document download to local storage, and remote-wipe capability on disconnect, can scope the device out of the device-level controls (the device's own configuration becomes immaterial because the data never leaves the container).

Practitioner answer: this is the case where the personal device runs Microsoft Intune App Protection Policies (Microsoft 365 mobile apps) or Google Workspace Advanced Mobile Management (Workspace mobile apps), with no native-app sync, and the container can be remotely wiped without wiping the rest of the device. The device is out of scope as a device; the container is in scope as a configuration. Evidence: the App Protection Policy configuration export plus a screenshot showing the policy applied to the user.

If yes and the container terms hold, the device is typically out of scope as a device, evidenced via the App Protection Policy export. Confirm with the assessor in the scoping call; assessor agreement is the assured path here.

If no (native app, browser without container, or full data sync to device), continue to Node 3.

Node 3: Is the device used by an employee or contractor, or by a customer?

The IASME rule: customer devices accessing customer-facing data through your platform are out of scope. The IASME requirement covers your organisation's devices, not your customers'.

Practitioner answer: a customer phone using your customer-facing app to view their own account is out of scope. A contractor phone that has been issued a company mailbox or user account in your identity provider is treated like an employee device. For contractor laptops on virtual desktop infrastructure, see the Windows 365 Contractor Scope reference. For the broader employee-device picture in a small organisation, the microbusiness scope playbook covers the worked examples.

If customer, the device is out of scope. Tree ends.

If employee or contractor, continue to Node 4.

Node 4: Is the device used for cloud admin work?

The IASME rule: every administrator account on every cloud service in scope has multi-factor authentication enforced. The administrator's device is in scope by virtue of the privileged actions it performs.

Practitioner answer: if an employee or founder uses their personal device to log into Microsoft 365 admin, Google Workspace admin, AWS console, Azure portal, or any other in-scope cloud admin function, the device is in scope and MFA is mandatory on every login. The cleanest decision here is to issue a managed device for cloud admin work and take this branch out of scope ambiguity entirely. The fastest BYOD scope decision we see is exactly this: company-issue a laptop for the founder's admin work, declare the personal device free of admin functions, and the personal device drops out of the in-scope path.

If admin device, the device is in scope as a managed device, with MFA evidence required. Tree continues through Node 5 (MDM and baseline configuration evidence still required for an unmanaged personal admin device) and Node 6 (OS support check).

If not admin device, continue to Node 5.

Node 5: Is the device enrolled in MDM and enforcing the baseline configuration?

The IASME rule: in-scope devices have the firm's standard build, patching, and malware-protection controls in place, evidenced.

Practitioner answer: a BYOD laptop or phone that is enrolled in Microsoft Intune, Jamf, Mosyle, Google Endpoint Management, or another MDM, with the corporate build profile applied, is treated like a managed device for evidence purposes. The personal owner accepts the configuration as a condition of access. Evidence: the MDM enrolment record and configuration export.

A BYOD device not enrolled in MDM, accessing in-scope data through a native app, is in scope as a BYOD device with full evidence requirements. The applicant must produce per-device evidence (host-based firewall on, anti-malware running, OS supported, patches current). For mobile-device specifics, see the Mobile Device Protection for Cyber Essentials reference. The cloud-only business scope spoke covers the parallel evidence pattern for cloud-only firms with no on-premise estate. At CE Plus tier this also affects sampling: BYOD devices in scope are sampled per the IASME formula alongside corporate-owned devices.

If MDM-enrolled, continue to Node 6.

If not MDM-enrolled and the device handles in-scope data through a native app or full data sync, the device is in scope as a BYOD device with applicant-produced per-device evidence. Continue to Node 6 for OS support check.

Node 6: Is the operating system supported and within the patching window?

The IASME rule: in-scope devices run a vendor-supported operating system with critical and high-severity patches applied within 14 days of vendor release.

Practitioner answer: this is the single highest-frequency BYOD failure cause. A personal Android phone on an OEM build that the manufacturer no longer supports (typical 2 to 3 year old budget Android), an old iPad on iPadOS no longer receiving updates, a personal laptop running an end-of-life Windows or macOS release. All fail this node.

If yes (OS supported, patches current), the device passes the tree.

If no, the device fails CE on this control. The fix paths are: replace the device, upgrade the OS where possible, or remove the device from in-scope use (route the data path through a different device).

The three outcomes of the Cyber Essentials BYOD decision tree, summarised

| Outcome | Devices | Evidence requirement | |---|---|---| | Out of scope | Customer devices, devices with no organisational-data access, devices using sandboxed-container access only | App Protection Policy config (for sandboxed) | | In scope, managed | Employee/contractor laptops in MDM with corporate build, founder's company-issued laptop for admin work | Standard managed-device evidence pack | | In scope, BYOD | Employee/contractor personal devices accessing data via native app without MDM, or with MDM but vendor-unsupported OS | Per-device firewall, anti-malware, OS, patching evidence |

A worked example, 4-person agency

A 4-person agency on Microsoft 365, three employees on company-issued MacBooks plus the founder using their personal MacBook for admin work, all four with personal iPhones for email.

Founder's personal MacBook: Node 1 yes, Node 2 no (native macOS Mail app, full data sync), Node 3 employee, Node 4 yes (admin device). Outcome: in scope as managed device, with MFA evidence. The fastest fix is to issue a company MacBook to the founder; the personal MacBook drops out of the in-scope path.

3 employee MacBooks: company-issued, in MDM, OS supported. Outcome: in scope as managed devices.

4 personal iPhones for email: Node 1 yes, Node 2 yes if the firm has Intune App Protection Policies on the Microsoft 365 mobile apps with no native-mail sync. Outcome: out of scope as devices, App Protection Policy is the in-scope evidence. If the firm uses native Mail.app on iPhone instead, Node 2 is no; tree continues to Node 3 (employees), Node 4 (no admin from phone), Node 5 (not MDM-enrolled), Node 6 (iOS supported and patches current). Outcome: in scope as BYOD with per-device evidence.

The founder gets a clear decision in under 15 minutes: company-issue a MacBook for admin, configure App Protection Policies on iPhones, evidence pack reduces by half.

Common questions

Can I declare BYOD out of scope by writing a "no BYOD" policy?

Only if the policy is enforced. A "no BYOD" policy that no one follows is not the IASME requirement; the IASME requirement is the actual practice. If users in fact use personal devices, the policy is irrelevant. The cleanest path is either to enforce the no-BYOD rule technically (Conditional Access blocking unmanaged devices) or to bring the BYOD into scope and evidence it.

What is a Mobile Application Management container in plain language?

It is an app-level configuration that wraps the data inside a sandboxed shell, wipeable independent of the rest of the device. Microsoft's name for this is Intune App Protection Policies; Google's is Workspace Advanced Mobile Management with app-level controls. Both let users keep their personal device personal while corporate data lives in a removable container.

What if a contractor's personal laptop has an unsupported OS?

The same rule applies as for employees. If the laptop accesses in-scope data, it is in scope; an unsupported OS fails the control. The fix is to issue the contractor a company laptop for the engagement window, or to require the contractor to upgrade the OS as a condition of access.

Does Conditional Access block unmanaged devices count as a control?

Yes. A Conditional Access policy that blocks unmanaged devices from accessing in-scope cloud services takes the unmanaged personal devices out of the in-scope path entirely. The Conditional Access configuration becomes the evidence; the personal devices themselves do not need to be enrolled or evidenced. This is the cleanest BYOD scope decision available on Microsoft 365 tenants with Entra ID P1.

Can I use Microsoft Authenticator on a personal phone for MFA without bringing the phone into scope?

Yes, on the practitioner reading that an authenticator app is a possession factor, not an organisational data path. The phone must still pass Node 1 (no other organisational data on the device) for this to hold. The MFA factor is in scope; the phone hosting it is not, provided the phone is otherwise out of scope.

Where do we book?

Book a Cyber Essentials assessment with Net Sec Group. The booking form lets you describe the BYOD profile in scope; the assessor returns a confirmed scope statement and engagement timeline.

Reference material

Where this fits on this site

This article is the BYOD-decisions spoke under the scope-decisions hub. The other scope-decision spokes are the microbusiness scope playbook, the cloud-only business scope, and Cyber Essentials without an IT team. Once the scope is settled, the timelines hub indexes the three engagement-speed paths.