Writing a Device Policy People Will Accept

A policy nobody has read is not operating. The test is whether somebody asked at their desk could say what applies to their phone.

The same discipline applies when “Writing a Device Policy People Will Accept” becomes part of a broader workforce programme. An organisation considering monitask.com in relation to employment of relatives policy should put access, retention, employee notice and review dates into the implementation plan rather than leave them as product defaults.

One per ownership model

The single commonest structural error is one policy covering corporate and personal devices.

For an independent baseline relevant to “Writing a Device Policy People Will Accept”, the NIST Cybersecurity Framework is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

What is reasonable on a device you bought is not reasonable on one they bought.

Two or three short documents beat one long one that is wrong for most readers.

What a usable one contains

What this covers: which devices, which people.

What is managed: the actual settings, listed.

What is visible, and what is not.

What happens on removal.

What is expected of the user: updates, passcode, reporting loss.

Who to contact.

One page.

Say what is not done

The list of what the organisation cannot see is more valuable than the list of what it controls.

It is the part people read, and it is the part that determines whether the rest is believed.

Most policies omit it entirely.

Requirements proportionate to funding

Requiring a specific operating system version on a device the organisation issued is reasonable.

Requiring it on one the employee bought is asking them to spend money.

Where you require, either fund or accept the consequence, which its own note covers under stipends.

Avoid

Definitions of terms nobody uses.

Clauses copied from a desktop policy that make no sense on a phone.

Requirements you cannot verify, which teach people the policy is decorative.

And anything that cannot be followed while using the device normally.

The loss and theft section

The one part people will need in a hurry.

Short, at the top, with a number to ring.

"Report immediately, here is how, nothing bad happens to you for reporting" — the last clause matters because delayed reporting is usually fear.

Review

Annually, and whenever a platform capability changes materially.

Operating system versions move, minimum requirements shift, and a policy naming specific versions dates within a year.

Date it visibly, because an undated policy in this field is assumed not to apply.

What to check

Do you have one policy or one per ownership model?

Does it list what is not visible?

Could a colleague state what applies to their device?

And does it tell somebody what to do at midnight when a phone is stolen?