Begin with the purpose, not the data source.
Begin with the purpose, not the data source.
A request such as “collect device data” is too broad to govern. Start with a concrete operational purpose: maintain an asset inventory, detect low storage, confirm an approved software version or support a user-reported problem.
For each purpose, identify the minimum signal needed, who may see it, how long it remains useful and what action it can trigger. If a field has no defined decision or operating use, it should not be collected merely because an agent can access it.
Privacy requirements for a managed-device model
Privacy requirements for a managed-device model
Visible enrollment
Make it possible to identify that a device is managed, which organization manages it and where policy information lives.
Minimal telemetry
Use a documented inventory and health field set with collection intervals matched to the purpose.
Role separation
Separate viewing signals, proposing an action, approving it and reviewing its history where risk warrants.
Bounded actions
Prefer a narrow catalog of signed, time-limited actions over general shell access.
User and manager context
Apply notice, consent or organizational approval appropriate to the device, action and workplace setting.
Revocation
Support controlled unenrollment, key rotation and loss of management authority when a relationship ends.
Draw prohibited boundaries in product requirements.
Draw prohibited boundaries in product requirements.
Hidden keylogging, covert camera or microphone activation, private-message collection and indiscriminate personal-file harvesting are not ordinary asset or health-management functions. Excluding them should be an enforceable design requirement, not only a policy sentence.
General remote execution also creates an unnecessarily broad control surface. A safer model defines permitted actions, validates target and authorization, limits time and replay, and records execution and outcome.
Review a proposed telemetry field
Review a proposed telemetry field
Each stage keeps its owner, context and outcome visible.
- 01
Name the purpose
State the specific risk, support task or inventory decision the field serves.
- 02
Reduce the detail
Ask whether a category, state or local evaluation can replace raw or continuous data.
- 03
Set the boundary
Define eligible devices, viewers, collection interval, retention and permitted downstream use.
- 04
Make it inspectable
Document the field for administrators and affected users and keep changes reviewable.
Questions to answer before enrollment
Questions to answer before enrollment
Device ownership, employment context and local law can change the appropriate notice and authorization model. Organizations need their own qualified assessment before deployment.
Product documentation should still make the technical behavior understandable enough for that assessment: collected fields, timing, destinations, access roles, retention, commands and unenrollment.
Authority
Who owns the device, who is affected and who may authorize management?
Visibility
What can administrators and users inspect about collection and past actions?
End of access
What happens to credentials, retained signals and the device record at offboarding?