Skip to content
Sections
All notes

All notes · Obligations

Records, Retention and Access Requests

What the programme accumulates about people, how long to keep it, and the request you should rehearse before it arrives.

Obligations · Procedure

General orientation, not legal advice; retention requirements differ by jurisdiction.

The practical question in “Records, Retention and Access Requests” is how to make work visible without confusing visibility with certainty. For teams researching attendance sheet template, explore the platform can add time and project context to the operational record, provided its use is proportionate, disclosed and reviewed with the people affected.

A device programme generates a continuous record about identifiable employees. Deciding what to keep and for how long is part of running it.

For an independent baseline relevant to “Records, Retention and Access Requests”, the ICO employment-practices guidance is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

What accumulates

Device records: model, version, compliance history, check-in history.

Application inventory over time.

Action logs: wipes, profile changes, access blocks.

Enrolment and consent records.

And support contacts, which sit in a different system and are frequently forgotten in this analysis.

A workable schedule

Current device record: while enrolled.

Compliance history: months rather than years, because the investigative value decays quickly.

Action logs for irreversible actions: longer, because they answer later questions.

Enrolment records: for the employment relationship plus whatever your limitation period is.

Everything else: delete on a stated schedule, automatically if the platform allows.

Deleting at unenrolment

The record of a device nobody manages has little purpose.

Keep what you need to show what was done and when, delete the rest.

Most platforms retain unenrolled device records indefinitely by default, which is a setting worth finding.

The access request

Somebody asks what you hold about them and their device.

The answer includes the device record, the compliance history, and any action log entries.

Producing it should take minutes and usually takes a day of confusion because nobody has tried.

Rehearse it once with a volunteer.

What people are surprised by

How much history is retained.

The application inventory, where it is collected.

And the check-in log, which shows when a device was and was not in contact — which people read as a presence record even where it is not intended as one.

Be ready for that reading, because it is a reasonable one.

Logs that answer the hard question

"Did you wipe my phone?"

"Who authorised that?"

"When did you start collecting this?"

These need answering from records rather than memory, which means the action log is the one to retain properly.

Supplier retention

The platform vendor holds this data too.

Ask what they retain and for how long, and get it in the contract.

A retention policy covering only your own view is incomplete, which the procurement note covers.

What to check

Is there a written retention schedule, and is it applied?

Are unenrolled device records deleted?

Could you answer an access request this week?

And do you know what your platform vendor retains?