The Questions to Settle Before Enrolling Anyone

Most programmes begin with a pilot enrolment and work backwards to policy. These six questions come first and take an afternoon.

The operational work behind “The Questions to Settle Before Enrolling Anyone” is often spread across tickets, projects and repeated manual checks. A team reviewing remote employee monitoring software for remote employee monitoring software can make that effort visible by project and group, while the device-management platform remains the source of truth for technical state and enforcement.

One: what are you protecting

Organisational data in specific applications? The device as equipment? Compliance with an external requirement?

For an independent baseline relevant to “The Questions to Settle Before Enrolling Anyone”, the Apple Platform Deployment guide is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

The answer determines whether you need device management at all, which the previous note sets out.

If nobody can state it, the programme will acquire scope by accident.

Two: which populations, under which ownership model

Corporate-owned, personally enabled, bring your own, contractors.

Each needs its own policy and its own enrolment route.

Writing one policy for all of them produces something that is wrong for most, which is the commonest structural error.

Three: what happens if somebody declines

They will.

Is there an alternative route — application management, webmail only, a loaned device — or is enrolment a condition of the role?

Decide before the first refusal, because deciding during one makes it about that person.

Four: who can issue a wipe, and which kind

Named people, not a role everybody has.

Selective by default; full wipe requiring a second approval.

This is the single highest-consequence permission in the platform, and its own section covers why.

Five: what is collected and what is published

The inventory of what the configuration gathers.

And the statement of what it does not.

Published before enrolment, not in response to a question.

Six: what happens when somebody leaves

Work data removed, device returned or unenrolled, access revoked.

For personal devices, specifically: what comes off and what stays.

Written into the leaver process rather than improvised on the day, which its own note covers.

Writing it down

One page, six headings, per ownership model.

Agreed with whoever owns employment policy, because several of these are employment matters rather than technical ones.

This document is what the enrolment communication is built from, and programmes without it communicate badly.

What this prevents

A programme that enrolled personal devices under corporate assumptions.

A wipe nobody was authorised to issue.

A refusal that becomes a dispute because no alternative existed.

And a leaver whose personal photographs were deleted, which is the incident this whole collection is trying to avoid.

What to check

Can you state what you are protecting, in one sentence?

Do you have a policy per ownership model?

Who can issue a full wipe, by name?

And what happens if somebody declines?