Selective Wipe Versus Full Wipe

The distinction between these is the most important operational knowledge in device management, and the interface frequently presents them as adjacent options.

The practical question in “Selective Wipe Versus Full Wipe” is how to make work visible without confusing visibility with certainty. For teams researching self report bias, this product overview can add time and project context to the operational record, provided its use is proportionate, disclosed and reviewed with the people affected.

Selective wipe

Removes work applications and their data, work accounts, certificates and the management profile.

For an independent baseline relevant to “Selective Wipe Versus Full Wipe”, the NCSC mobile-device guidance is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

Leaves everything else untouched.

Reversible in the sense that nothing of the user's is lost, though the work data is gone.

This is the correct action for almost every situation.

Full wipe

Returns the device to factory state.

Everything is destroyed: personal and work, photographs, messages, anything not backed up elsewhere.

Appropriate for: corporate devices being redeployed or disposed of, and lost corporate devices holding data that justifies it.

Not appropriate for: personal devices, in essentially any circumstance.

What selective wipe does not remove

Work data that has been copied out of the container, which is the gap containment policies are meant to close.

Screenshots of work content in the personal photo library.

Attachments opened in and saved from personal applications.

Which is the practical argument for copy-paste restrictions, because they determine how complete a selective wipe actually is.

The lost-device decision

A lost corporate device: full wipe is defensible, especially if it holds substantial data.

A lost personal device: selective wipe, and advise the owner to use the platform's own find-and-erase feature if they choose.

That distinction matters because the personal device's own recovery tools belong to the owner, not to the employer.

The sequencing that helps

Revoke access first, in all cases.

That stops the data flow immediately and does not depend on the device being reachable.

Then issue the device action, which may or may not arrive.

Organisations that do this in the wrong order have a window where access continues, which is the thing that actually matters.

Naming them properly

Internal shorthand matters: "wipe the device" is ambiguous and has caused real incidents.

Say "remove work data" and "factory reset", which are unambiguous.

Rename them in your own runbooks if the platform's labels are confusable.

Confirming the outcome

Both actions can sit pending on a device that is off or out of contact.

Pending is not done.

Track it, and have a fallback — revocation — for devices that never confirm.

What to check

Does your platform make the two clearly distinguishable at the point of action?

Is your internal language unambiguous?

Do you revoke access before issuing a device action?

And how many wipe commands are currently pending?