Writing a mobile device policy people will actually follow
Most device policies are unenforceable, unread, or both. A short policy backed by technical controls beats a long one backed by good intentions.
Most mobile device policies we are shown have three properties in common. They are long, they were written by someone who did not have to enforce them, and the people they apply to have not read them.
None of that is a drafting failure. It is what happens when a policy is written to cover a risk register rather than to govern behaviour, and when nothing in the environment enforces what the document says.
The test a policy has to pass
Two questions, applied to every clause:
Can this be enforced by a control? If yes, the control is the real policy and the clause is documentation of it. Write it that way.
If not, would we actually do anything if it were breached? If the honest answer is no, delete the clause. An unenforced rule teaches people that the rules are optional, and it does that to the rules you do enforce.
Most device policies lose half their length to that test and get better.
What the policy has to settle
Who owns the device, per cohort. Corporate-owned, corporate-owned with personal use permitted, or personally owned. The ownership model decides what you may do to the device, so it is the first clause, not an appendix.
What the organisation can and cannot see. State it precisely, and make it true. On a work profile or user enrolment you genuinely cannot see personal applications, photos, messages or location, and saying so plainly buys more compliance than a page of obligations. Overstating your visibility destroys trust the first time someone finds out.
What happens on departure, and to whose data. Which data is removed, by what mechanism, and what the person keeps. Settle the phone number question here too, because it is the one that generates a dispute.
What the person must do. Keep it to the handful of things that actually matter and that a control cannot enforce for them: report a lost or stolen device promptly, do not disable managed protections, do not enrol a jailbroken or rooted device, do not use the device for work you have been told to do elsewhere.
What is off-limits. Short, specific and defensible. “Do not forward organisational mail to a personal address” is enforceable and clear. “Use good judgement” is neither.
The classification boundary. What may be handled on a mobile device and what may not. If the answer is currently “nothing above OFFICIAL” because markings cannot be enforced on the handset, say that — and note that it is a technical limitation with a fix rather than a permanent rule, because otherwise it will still be there in five years.
Personal use, stated honestly. If personal use is permitted, say so with the boundaries. If it is prohibited on a device someone carries everywhere, expect the policy to be ignored and to lose credibility on everything else.
Cost. Who pays for the plan, for excess data, for damage, and for a replacement. Unstated, this becomes an argument with an individual under pressure.
Write it for the person, not the auditor
The audience is a staff member reading it once, on their phone, on their first day.
- One page for what they have to do. Everything else in an annexe.
- Plain sentences and active voice. “We can remove work data from your phone. We cannot see your photos.”
- Reasons attached to the rules that seem arbitrary — people follow a rule they understand and route around one they do not.
- Signed acknowledgement at issue, recorded. Not for the auditor: because it is the moment the person actually reads it.
Back it with controls, or expect it to be theatre
A policy clause with a matching control is a rule. Without one it is a hope. The pairs worth having:
| Policy says | Control that makes it true |
|---|---|
| Devices must be enrolled | Access requires a compliant device |
| Devices must be current | Enforced minimum OS version, with a deadline |
| No jailbroken devices | Detection that blocks access, not one that logs |
| Work data stays in work apps | Managed app boundaries |
| Report a lost device promptly | Remote lock and selective wipe, tested |
| No unapproved applications | Managed catalogue with an allow-list posture |
Where a clause has no control, either accept that it depends on goodwill and say so internally, or find the control.
Review it when something changes, not annually
An annual review is a calendar entry that produces a version number. The reviews that matter are the ones triggered by change: a new ownership model, a new platform capability, an incident, a change in what the fleet is allowed to handle.
Put the trigger list in the document. It is more useful than a review date.
The short version
Short, honest, enforced. State what you can see, what you cannot, and what happens when someone leaves — then make sure a control stands behind every rule you intend to keep.
More on advisory work and policy, and on how we run fleets.