Design MDM Compliance Policies for 4 Device Types

A compliance policy is the MDM's definition of "acceptable." It is a set of conditions a device must meet — encrypted, passcode set, OS at or above a minimum, not jailbroken — and a consequence when it fails. The hard part is not the syntax; it is judgment. The same control intent produces different enforced settings depending on whether the device is a corporate laptop, a corporate phone, or a personal phone you have limited rights over.

In this exercise you will design compliance requirements for four device types in a single company: a regulated SaaS startup of ~300 people that stores customer PII. For each, decide what the policy should require and what should happen on failure. Each scenario has one best answer, and the explanation walks through the tradeoffs you will use when writing real device policies.

Realizing you can't just wipe an employee's personal phone

The four device types

A. Corporate macOS laptop — issued to engineers and most staff; supervised via Apple Business Manager; full control surface available.
B. Corporate Windows laptop — issued to sales and operations; Autopilot-enrolled; managed by Intune.
C. Corporate-owned iPhone — issued to executives and on-call staff; supervised; holds email and Slack.
D. BYOD personal phone — employees' own devices; user-enrolled; access limited to email and Slack via managed apps.

Scenario 1: Encryption requirement across the four types

Quick check

You are writing the encryption clause of each device type's compliance policy. Which approach correctly reflects what you can enforce?

Require and enforce full-disk encryption (FileVault/BitLocker) on A, B, and C as a hard compliance gate; on D (BYOD), require device-level encryption where the OS reports it and rely on managed-app containerization for company data

Require full-disk encryption identically on all four, including remote-wiping any BYOD phone that fails

Skip encryption on phones entirely since mobile OSes are encrypted by default and it never needs verification

Only enforce encryption on the macOS and Windows laptops; phones cannot be evaluated for encryption at all

Scenario 2: OS update / patch policy

Quick check

Engineering pushes back: forcing immediate OS upgrades breaks their toolchain on update day. What patch-compliance approach balances security and operational reality across the corporate devices?

Force every device to install major OS updates the day they are released, no exceptions

Define a minimum acceptable OS version and a deadline (e.g., security updates within 14 days, with a short managed deferral window), mark devices non-compliant past the deadline, and allow a brief, documented exception path for engineering

Let users update whenever they want and report whatever version they happen to run

Only track the OS version but never set a minimum or a deadline

Scenario 3: Screen lock and passcode

Quick check

What passcode/lock requirement is appropriate per device type?

No passcode on laptops (they are in offices) and a 4-digit PIN on all phones

Enforce auto-lock with a timeout and a minimum password/passcode complexity on A, B, and C; on D, enforce a passcode/biometric as a condition of accessing the managed apps even though you do not control the whole device

Require a 20-character password on every device including phones, to be safe

Rely on each user to set their own lock settings and trust them to comply

Scenario 4: Jailbreak / rooting and integrity

Quick check

How should device-integrity (jailbreak/root detection) factor into the compliance policy, especially for the phones?

Ignore it — jailbreaking is rare and not worth checking

Mark any device that fails integrity/jailbreak-root detection as non-compliant and block its access to company data, on both corporate (C) and BYOD (D) phones

Only check integrity on corporate phones, since BYOD devices are the user’s responsibility

Detect jailbreak but take no action beyond logging it

Scenario 5: The consequence of non-compliance

Quick check

A device drifts out of compliance (e.g., OS falls below the minimum). What should the policy do, to be both effective and auditable?

Immediately wipe the device the moment it becomes non-compliant

Send the user a notification with a grace period to self-remediate, auto-remediate where the MDM can, and after the grace period block access to company data via Conditional Access — with every state change logged

Do nothing automated; have IT manually email people once a quarter

Mark it non-compliant in a dashboard but never restrict access

Putting it together: the policy matrix

A finished design is best expressed as a matrix — device types down one axis, control areas across the other. For this company it would look roughly like:

Control	A. Corp macOS	B. Corp Windows	C. Corp iPhone	D. BYOD phone
Encryption	FileVault enforced (gate)	BitLocker enforced (gate)	Data protection required (gate)	Verify if reported; protect via app container
OS minimum + deadline	Min version, 14-day deadline	Min version, 14-day deadline	Min iOS, 14-day deadline	Min iOS to use managed apps
Passcode + auto-lock	Enforced, ≤15 min, complexity	Enforced, ≤15 min, complexity	Enforced passcode + biometric	Required to open managed apps
Integrity (jailbreak/root)	n/a	n/a	Block on failure	Block on failure
Non-compliance action	Notify → remediate → block access	Notify → remediate → block access	Notify → remediate → block access	Block managed-app access

Two patterns to notice. First, the intent is identical across device types (encrypt, patch, lock, verify integrity, enforce a consequence), but the enforced mechanism changes with how much control you legitimately have — total on supervised corporate hardware, app-scoped on personal devices. Second, the non-compliance consequence ties back to access: the policy only matters because failing it eventually cuts off company data, which is the bridge into Conditional Access in Module 3.3.

How to use this in practice

When you write or review a device-compliance policy as a GRC Engineer, work the same five questions you just answered for every device type: encryption, patch level, passcode/lock, integrity, and the consequence of failure. Then write down the rationale for each difference — why BYOD encryption is verified-not-enforced, why engineering gets a deferral window. That documented rationale is what turns a pile of MDM toggles into a defensible, auditable policy, and it is exactly what an auditor asks for when they see two device groups treated differently.