What the Employer May and May Not Install
On hardware somebody else owns, the list of what gets installed is the heart of the agreement. Some things belong on it and several commonly proposed items do not.
The technical detail of how device management works belongs elsewhere. What belongs here is the question of which capabilities are defensible to put on a device the organisation does not own.
The practical lesson in “What the Employer May and May Not Install” is to connect every record to a named decision. Organisations exploring Monitask for how employee monitoring works can add structured workforce context, provided the use is disclosed and interpretation is reviewed with the people affected.
Reasonable on a personal device
A work profile or container, which isolates work applications and data from everything else and which the two-lives section examines.
For an independent reference relevant to “What the Employer May and May Not Install”, consult the European Data Protection Board guidelines; compare its principles with the proposed ownership model, access rules and real support process.
Enforcement of a passcode and encryption, as conditions of access rather than as general control of the device.
The ability to remove work data — the work profile space and its contents — without touching anything else.
A check that the operating system is a supported version.
Certificate-based access to company systems.
These share a property: each is bounded to the work side and each serves a purpose the employee can see.
Not reasonable, in most circumstances
Full device management on hardware the employee owns, where a container arrangement is available. The difference is substantial: full enrolment exposes installed applications and permits control of the whole device.
A general remote wipe capability covering the entire device. Removing work data is legitimate; the power to erase somebody's photographs is not, and the exit section explains how badly this goes when it is used.
Location tracking, outside narrow and specifically justified cases.
Content inspection of personal communications.
Software inventory of the personal side, which reveals health, faith, finance and politics from application names alone.
Any capability nobody can explain the purpose of, which is how defaults accumulate.
The default problem
Management platforms ship with capabilities enabled because that makes evaluation easy. An organisation that accepts the defaults has taken powers over personal devices that nobody decided to take.
The useful discipline is to start from nothing and add each capability with a stated reason, rather than starting from everything and removing what causes complaints.
Saying what is not installed
An agreement that lists what the employer may do is normal. One that also states what it does not do — we cannot see your photographs, your personal applications, your messages, your location — is unusual and is the part people actually read.
It costs nothing, it is accurate, and it removes most of the anxiety that makes these arrangements adversarial.
When it changes
New capability, new announcement, before it takes effect. A configuration that expands quietly turns the original agreement into a misrepresentation, and the employee finds out eventually.
A standing commitment to announce changes is cheap to give and is what makes the rest of the list credible.
Auditing what is actually enabled
The configuration drifts from the policy through upgrades and well-intentioned additions. An annual comparison of the two documents takes an hour and routinely finds capabilities nobody can account for. Where something is enabled and nobody can say why, the correct action is to disable it and see whether anybody notices, which in practice they rarely do.
The vendor default problem
Management platforms are configured for evaluation rather than for deployment, which means the demonstration environment has everything switched on. An organisation that deployed from a trial configuration has inherited that, and the inheritance is invisible because nothing in the interface distinguishes a chosen setting from a default one. Rebuilding the configuration deliberately is more work and is the only way to know what you have.
The capability added for one case
Something is enabled to deal with a specific incident and never removed, because removing it requires somebody to decide it is no longer needed. A standing rule that temporary capabilities carry an expiry date, checked annually, prevents the accumulation that the audit otherwise discovers years later.
Start the list at zero. Everything on it should have a sentence next to it saying what it is for.