BYOD Security Policy

Document Number: ISMS-POL-BYOD-01

Classification: L1 — Policy (Domain)

Version: 0.3.1

Effective Date: March 1, 2026

Author: Lucas Shin — Security Director

Approved By: Richard — CISO

Next Review Date: February 2027

Parent Policy: Information Security Policy (ISMS-POL-ISP-01)

Base Solution: Microsoft 365 Business Premium

Security Control Baseline: Entra ID P1 + Conditional Access + Intune + Defender

1. Purpose

This policy defines the security requirements, principles, and governance structure for the use of personally-owned devices (BYOD) to access corporate data and services.

It serves as the upper-level policy document that governs four subordinate operational procedures:

1. Device Lifecycle Procedure
2. Patch Management Procedure
3. Access Control & Data Protection Procedure
4. Monitoring & Incident Response Procedure

2. Scope

2.1 Applicable Devices

• macOS (MacBook, Mac Mini) — personal devices used for work
• Windows — personal devices used for work (subject to platform-specific restrictions; see §3.2)
• iOS / iPadOS — personal mobile devices (see §3.4)
• Android — personal mobile devices (see §3.4)

2.2 Applicable Users

• All employees assigned Microsoft 365 Business Premium licenses
• Contractors and temporary staff only if enrolled through the Device Lifecycle Procedure (see also: Human Resource Security Policy, ISMS-POL-HR-01)

2.3 Out of Scope

• Corporate-owned devices (covered under separate policy)
• Users on non-Premium licenses (Basic, Standard, Exchange P1) — governed by Security Defaults only; see M365 Workspace & Access Policy (ISMS-PROC-M365-01) for tier-appropriate controls
• Guest/external accounts (see: Supplier & Third-Party Security Policy, ISMS-POL-STP-01)

2.4 Asset Management Cross-references

• BYOD device asset scope: BYOD devices are not registered in the Information Asset Register. They are tracked for access control purposes (compliance, offboarding, audit, stale device cleanup). See Information Asset Identification — Standard Definition (ISMS-STD-ASM-01) §3 (scope exclusion) and §6.5 (BYOD/personal software rationale)
• Endpoint device discovery: Platform-specific inventory sources (Intune Devices for ADUE; Entra ID Registered Devices + APP reports for Windows MAM-only) are defined in Asset Management Policy (ISMS-POL-ASM-01) §3.3 and §4.3.2
• Device inventory review procedure: Device Lifecycle Procedure (ISMS-PROC-BYOD-01) §6

3. Security Architecture Principle

This policy adheres to the Zero Trust principle: security is enforced by controlling the gateway (App/Browser) that accesses corporate data, rather than controlling the entire device.

Key Design Decisions

• Logical isolation between personal and work data (User Enrollment on Apple, Work Profile on Android)
• No full device control — company cannot see personal apps, photos, browsing history, or location
• Conditional Access as the primary enforcement point — non-compliant devices are blocked at the authentication layer
• Compensating controls (Updatest screenshots) for apps outside Intune management scope

3.1 macOS BYOD — ADUE Architecture

macOS BYOD uses ADUE (Account-Driven User Enrollment) with a dedicated APFS Managed Volume for OS-level data isolation, and native M365 apps deployed via VPP. APP (App Protection Policy) is not supported on macOS — clipboard residual risk is accepted with compensating controls (user education, NDA, M365 audit logging).

Detailed platform architecture: See ISMS-CONF-BYOD-01 §2.1

3.2 Windows BYOD — Platform-Specific Restrictions

Windows BYOD operates under Managed Edge only (M365 web apps). Office desktop apps are blocked — Business Basic at licence level, Business Premium at CA level. Edge APP enforcement: download/save-as/print blocked; copy/paste intentionally allowed (macOS parity, pending CISO approval). Device registers as Entra Registered (no MDM).

Detailed platform restrictions and blocking conditions: See ISMS-CONF-BYOD-01 §2.2. For the Full MDM Exception Path, see §3.3 below.

3.3 BYOD Full MDM Exception Path — Windows Desktop App Access

3.3.1 Eligibility and Approval

• Available to Business Premium licence holders only (desktop app licence required)
• User must submit a written request to the Security Director with business justification
• Security Director evaluates and approves based on operational necessity
• Approval is recorded in the exception register (see Section 8)

3.3.2 Opt-in Consent Agreement

Prior to enrolment, the user must sign a BYOD Full MDM Consent Form covering:

• Entra Join + Full MDM enrolment: acceptance that the device will be bound to the organisation's directory and enrolled in Intune Full MDM
• BitLocker encryption: consent to full-disk encryption with the recovery key escrowed to Entra ID (company retains Final Say over storage)
• Full Wipe acknowledgment: understanding that if Selective Wipe fails upon offboarding, a Full Wipe (factory reset) will be performed using the escrowed BitLocker recovery key
• Personal data disclaimer: the company is not responsible for loss of personal data resulting from Full Wipe
• Standard User enforcement: acceptance that local administrator rights will be revoked

This consent is separate from and in addition to the standard BYOD User Consent Form referenced in Section 5.3.

3.3.3 Mandatory Technical Controls

Upon enrolment, the following controls are applied via Intune: Entra Join, Full MDM, BitLocker + Key Escrow, OneDrive KFM, Standard User enforcement, and CA Compliant Device grant.

Detailed control specifications: See ISMS-CONF-BYOD-01 §2.3

3.3.4 Personal Use

• Personal use of the device is permitted, consistent with BYOD principles
• The device remains personally owned; the company gains elevated management jurisdiction, not ownership
• Users may install personal applications via Microsoft Store
• Personal browsing and personal app usage are not monitored or restricted

3.3.5 Offboarding Procedure

Upon termination, role change, or user-initiated opt-out:

1. Selective Wipe — remove corporate apps, accounts, and policies from the device
2. If Selective Wipe fails (e.g., device offline, local account recovery) → Full Wipe using the escrowed BitLocker recovery key, as consented in the Opt-in Agreement
3. Entra ID cleanup — remove device registration and purge BitLocker recovery key
4. Exception register update — record the offboarding date and method

Policy clarification: The availability of Full Wipe in this exception path is a departure from the standard BYOD privacy boundary (Section 6), which limits remote actions to Selective Wipe only. This departure is justified by the user's explicit Opt-in Consent and is documented in the exception register.

3.4 iOS/iPadOS & Android BYOD — Mobile Platform Architecture

Mobile platforms provide both app-level (APP) and OS-level (ADUE/Work Profile) data protection — the only platform combination where full DLP is available. APP enforces copy/paste blocking, save-as restriction, download prevention, and screenshot blocking. No residual clipboard risk on this platform.

Detailed mobile architecture: See ISMS-CONF-BYOD-01 §2.4

🏗️ System Architecture Overview

System architecture diagram: See Annex A below. Detailed platform-specific descriptions: ISMS-CONF-BYOD-01 §2.1–§2.4

4. Roles and Responsibilities

5. Acceptable Use

5.1 Permitted

• Access corporate email, Teams, SharePoint, and approved SaaS tools via managed apps or Managed Edge
• Use personal apps and data on the same device (logically isolated from work domain)
• Perform work on personal Wi-Fi or mobile data networks

5.2 Prohibited

• Access corporate data via unmanaged browsers (Safari, Chrome, Firefox, etc.)
• Copy/paste corporate data into personal apps (enforced by APP on iOS/Android managed apps only; macOS: APP not supported — policy-enforced only, see §3.1; Windows BYOD: technically enforceable via Edge APP but intentionally allowed — same risk rationale as macOS, pending CISO approval, see §3.2)
• Screenshot or screen record corporate app content on mobile (enforced by MAM policy; see also: Communications & Media Security Policy, ISMS-POL-COM-01)
• Share corporate credentials with any third party
• Jailbreak or root a device enrolled in BYOD management
• Disable or circumvent Intune enrollment or Compliance Policy

5.3 User Acknowledgment

• All users must sign the BYOD User Consent Form prior to enrollment
• The consent form covers: scope of management, data visibility boundaries, remote wipe conditions, and acceptable use terms
• Consent must be renewed annually or upon significant policy change

For the full onboarding and consent management process, see Human Resource Security Policy (ISMS-POL-HR-01).

6. Privacy Boundary Definition

BYOD requires a clear boundary between what the company can and cannot see or control on a personal device.

6.1 What the Company CAN See / Control

6.2 What the Company CANNOT See / Control

Note: This boundary is enforced by Apple User Enrollment and Android Work Profile at the OS level. The company technically cannot bypass this isolation.

6.3 Data Ownership vs Management Jurisdiction

Data ownership is determined by the account context used to create or access the data — not by the storage location (Managed Volume). The ADUE Managed Volume and MAM policies define management jurisdiction (technical control scope), not ownership rights.

Detailed ownership framework and determination rules: See ISMS-CONF-BYOD-01 §3.1

6.4 MAM Control Scope

MAM prevents corporate data from leaving the managed boundary but does not prevent personal data from entering it. MAM cannot control which accounts a user signs into, block personal SaaS access within Managed Edge, or distinguish between corporate and personal accounts on the same SaaS.

Detailed MAM capability matrix: See ISMS-CONF-BYOD-01 §3.2

6.5 Selective Wipe and Personal Data Notice

Upon Selective Wipe, all data within the Managed Volume is deleted regardless of ownership. Users accessing personal SaaS through Managed Edge may lose cached personal data. This notice must be included in the BYOD User Consent Form (§5.3).

Detailed wipe behavior: See ISMS-CONF-BYOD-01 §3.3

7. Non-Managed Application Security (Non-M365 App Security Controls)

Scope: This section controls the access paths and methods for non-M365 apps that fall outside the direct control scope of APP (App Protection Policy) on BYOD devices. The core objective is to extend the gateway control principle of §3 (corporate information asset access through managed apps/browsers) to non-M365 apps. Per-app account operation policies, data context isolation, AI data sovereignty, and other app/data governance rules are defined in Application & Data Governance Policy (ISMS-POL-ADG-01).

7.1 Scope of Application

Defines security controls for non-M365 apps that hold or process corporate information assets but are not directly protected by Intune App Protection Policy (APP). (On macOS, APP itself is not supported on the platform; therefore all non-M365 apps — including VPP-deployed apps — are in scope.)

Examples:

• Knowledge management tools (Notion, etc.) — holds corporate documents, policies, project data
• Development asset management (GitHub, etc.) — holds source code, technical documentation
• Design tools (Figma, Adobe, etc.) — holds client deliverables, design assets
• Generative AI (Claude, Gemini, etc.) — data leakage risk when corporate data is entered

Exclusion: M365 apps (Teams, Outlook, Edge, etc.) are directly controlled by the platform-specific architecture in §3 (APP, CA, Managed Volume, etc.) and are therefore out of scope for this section.

7.2 Control Principles

1. Enterprise App Registration and SSO — Prioritise SSO-capable products; register as Entra Enterprise App with Admin Consent
2. Managed Edge Routing Principle — Corporate-account web access via Managed Edge; platform-specific DLP scope varies
3. Native App Access Restrictions — SSO availability depends on authentication implementation (WAM broker vs embedded webview)
4. Account Separation Principle — Separate Corporate and Personal accounts; detailed rules in ISMS-POL-ADG-01
5. Information Asset Classification Linkage — Apply SaaS assessment criteria per ISMS-POL-STP-01 §3

Detailed control implementation and platform-specific DLP scope: See ISMS-CONF-BYOD-01 §4.1

7.3 Compensating Controls

Compensating controls include: quarterly account separation compliance verification, annual app security configuration checks, policy-enforced data leakage prevention, and mandatory Enterprise/Team plans for AI service corporate data input.

Detailed compensating control matrix: See ISMS-CONF-BYOD-01 §4.2

Cross-reference: For detailed per-app account operation policies, data context isolation, and AI data sovereignty, refer to Application & Data Governance Policy (ISMS-POL-ADG-01).

8. Exception Handling

8.1 When Exceptions Apply

• A user requires an app not available via VPP/managed deployment (see also: Supplier & Third-Party Security Policy, ISMS-POL-STP-01 for SaaS tool assessment)
• A device cannot meet compliance requirements due to hardware/OS limitations
• A temporary operational need requires deviation from this policy (see also: Business Continuity Policy, ISMS-POL-BCP-01)

8.2 Exception Process

8.3 Exception Constraints

• Maximum duration: 90 days (renewable with CISO re-approval)
• All exceptions must have documented compensating controls
• Exception register reviewed quarterly as part of management review

9. Compliance Mapping

10. Document Control

Review Schedule

• Quarterly: Exception register review, procedure effectiveness check
• Annually: Full policy review as part of ISO 27001 ISMS management review cycle
• Ad-hoc: Upon significant changes (new platform, licensing change, security incident)

Annex A — System Architecture Overview

The following diagram illustrates the end-to-end BYOD security architecture across all supported platforms. For detailed platform-specific technical descriptions, see ISMS-CONF-BYOD-01 §2.

graph TD
    User["Employee Personal Device"]

    subgraph "macOS BYOD — ADUE (§3.1)"
        UE_mac["ADUE User Enrollment"] -->|"Managed Volume"| Apps_mac["Native M365 Apps (VPP)"]
        Comp_mac["Compliance Policy"] -->|"Monitoring"| OS_mac["OS/App Version Check"]
    end

    subgraph "Windows BYOD — Default Path (§3.2)"
        ER["Entra Registered + MAM"] -->|"Edge Only"| EdgeOnly["Managed Edge — M365 Web Apps"]
    end

    subgraph "Windows BYOD — Full MDM Exception (§3.3)"
        EJ["Entra Join + Full MDM"] -->|"Opt-in + Approval"| FullCtrl["Desktop Apps Permitted"]
        FullCtrl --> Controls["BitLocker + KFM + Standard User"]
    end

    subgraph "iOS/Android BYOD — APP + ADUE/Work Profile (§3.4)"
        UE_mobile["ADUE / Work Profile"] -->|"Logical Isolation"| Apps_mobile["Managed M365 Apps"]
        APP_mobile["App Protection Policy"] -->|"Full DLP"| Apps_mobile
        Comp_mobile["Compliance Policy"] -->|"Monitoring"| OS_mobile["OS/App Version Check"]
    end

    subgraph "Access Control — Entra ID"
        CA["Conditional Access"] -->|"Compliance Check"| Decision{"Compliant?"}
        Decision -->|"Yes"| Access["M365 and SaaS Access Granted"]
        Decision -->|"No"| Block["Access Blocked and Patch Prompted"]
    end

    subgraph "Self-Hygiene"
        Updatest["Updatest App"] -->|"User Action"| Manual["Personal App Update"]
        Log["Evidence Records"] -->|"Weekly Submission"| Admin["Security Audit Evidence"]
    end

    User --> UE_mac
    User --> ER
    User --> EJ
    User --> UE_mobile
    Apps_mac --> OS_mac
    OS_mac --> CA
    EdgeOnly --> CA
    Controls --> CA
    Apps_mobile --> OS_mobile
    OS_mobile --> CA

[End of Policy Document]