Leaving: What Happens to Their Phone
The moment the programme is judged. What should happen, what sometimes does, and the single technical decision that prevents the worst case.
Personal devices · Procedure
Somebody leaves, and their personal phone has to be dealt with. This is the moment that produces the stories people tell about device management.
The people process in “Leaving: What Happens to Their Phone” needs an auditable workflow without reducing the individual to a single activity score. Used for key person dependency, key person dependency can supply time and project context, but the decision itself should still rely on documented expectations, conversation and appropriate human review.
What should happen
Access revoked at the identity layer.
For an independent baseline relevant to “Leaving: What Happens to Their Phone”, the CISA mobile-device security guidance is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.
Work profile or work applications removed, with their data.
Certificates revoked at the issuing authority.
Nothing personal touched.
The person told in advance what will happen and when.
The worst case
A full wipe issued on a personal device, destroying photographs, messages and everything else.
It happens through a wrong selection, a wrong device record, or a process that does not distinguish ownership models.
It is not recoverable and it is the single event most likely to end up discussed publicly.
The decision that prevents it
Use a work profile, so that full wipe is not available on personal devices as a matter of platform capability rather than of care.
Restraint fails eventually; structure does not.
This is the strongest practical argument for the arrangement and it is worth making in those terms.
Where that is not possible
Fully enrolled personal devices exist, usually for historical reasons.
Then: selective wipe only, as a configured restriction; full wipe requiring a named second approval; and the ownership model visible on the device record where the action is issued.
Three controls, because one is not enough for an irreversible action.
Timing
Revoke access first; device action second.
A departing person losing access is expected. A departing person whose phone is wiped before they knew the process is a complaint.
And give notice: "your work profile will be removed on Friday" costs a sentence.
The device that never checks in
Common at departure: the person has stopped using it, or switched it off.
The removal command sits pending.
Which is why revocation at the authority matters — it works regardless, and it is what actually protects the data.
Record the device as pending with a date rather than treating it as done.
Afterwards
Confirm what was removed.
Record it: date, action, who authorised, confirmation state.
That record is what answers a later question about somebody's data, and it is routinely absent.
The goodwill point
People talk about this. A programme that removes work data cleanly and visibly leaves nothing personal is described that way to colleagues and to the next employer's IT team.
One bad wipe is described for years.
What to check
Can a full wipe be issued on a personal device in your platform?
Is access revoked before the device action?
Are certificates revoked at the authority?
And is there a record of what was removed, per leaver?