Workforce

Retention, access, and who inside the company may look

The store outlives the purpose, and later purposes find it without anybody deciding to repurpose anything.

For a separate operational view of time, ownership and team activity, see Monitask.

Every deployment is justified by a purpose. The store it creates outlives that purpose, and the main risk in workforce monitoring is not the collection but what the material is used for two years later by somebody who was not in the original conversation.

Purpose creep is the mechanism, not misuse

Data gathered to settle invoice disputes is present when a performance review comes round. Data gathered for security is present during a redundancy selection. Nobody has to decide to repurpose it; it simply exists, it is easier to consult than to ignore, and each use looks reasonable on its own.

The decision that prevents this is taken at collection, not at use. Material kept for a stated window and then deleted cannot be found by a purpose nobody anticipated. Material kept indefinitely will be.

Raw and derived are different lifetimes

Screenshots, keystrokes, window titles and full addresses are the raw material and carry almost all of the risk. Weekly aggregates carry almost none and answer most of the questions anybody actually asks.

The sensible arrangement is therefore short raw retention and longer aggregate retention: days or weeks for the capture, months or longer for the summary. Most products default the other way, because long raw retention demonstrates capability during an evaluation.

Setting the window per purpose rather than globally is what makes it defensible. A billing dispute has a period. A security investigation has a period. Neither is "forever, in case".

Who can look is a governance question

Most deployments end up with three tiers by default: administrators who can see everything about everyone, managers who can see their own reports in detail, and nobody else.

The first tier is the one that goes unexamined. Technical staff administering the tool can generally view any individual's captured material, including that of people far senior to them, and that access was granted as a side effect of operating the software rather than as a decision about who should be able to watch whom.

Two questions settle most of it. Which roles can view material identifying a named person, as against an aggregate. And whether viewing leaves a record. Access logs are what convert an honour system into something reviewable, and their absence is the reason curiosity in these systems is free.

the storekept because deleting is workcollected to settle invoicesa performance reviewa redundancy selectiona disciplinary processa subpoena, or a breachnone of these were the purpose. all of them are reachable.
Figure 1Collected for one stated purpose and reachable by four others. None of them required a decision to repurpose anything; the material was simply there.

Elevated access should be an event

Investigations sometimes genuinely require an individual's detail. The arrangement that survives scrutiny treats that as an event rather than a standing permission: requested with a reason, approved by somebody who is not the requester, limited in time and scope, logged, and reviewed afterwards.

That is more process than most organisations expect for a monitoring tool, and it is considerably less than they would expect for reading somebody's email, which is roughly what is being authorised.

Can the tool answer the person?

Many regimes give individuals the right to see the data held about them, and it is a procurement question rather than a legal one whether the product can actually produce it: everything about one person, in a readable form, without exposing anybody else's data in the same export.

Ask for a demonstration rather than an assurance. A tool that cannot do it will make an obligation into an engineering project at the moment somebody exercises the right, which is usually a moment when relations are already strained.

Departure, and the hold that stops deletion

Retention rules have to survive people leaving, and the default in practice is that a leaver's records sit in the store indefinitely because deletion is nobody's task.

The complication worth designing for is that a pending dispute may legally require preservation, which suspends deletion for that person's material. That is legitimate, and it needs to be a deliberate, scoped, recorded act with an end. A preservation hold applied loosely and never lifted is how "we delete after ninety days" becomes untrue without anyone noticing.

The store is a target

A workforce monitoring database contains screenshots of internal systems, credentials captured incidentally, message content, and a behavioural map of the organisation. It is a more valuable target than most systems it sits alongside, and it is frequently administered with less rigour because it was bought by a department rather than by security.

The supplier's own posture matters here as much as your configuration: where the data sits, which of their staff can access it for support, which sub-processors are involved, and what happens to copies at the end of a contract. Those are contract questions and belong in the contract.

What we cannot verify

Retention defaults, access models and export capabilities differ by product and version and are described by their vendors; we have tested none and name none. Legal preservation obligations and individual rights are jurisdictional and fact-specific, and nothing here is advice. What your own deployment retains and who can read it is answerable this week from its own configuration, which is a review very few organisations have run.

The short version

  1. The store outlives the purpose, and later purposes find it without anyone deciding to.
  2. The preventing decision is taken at collection, not at use.
  3. Raw capture carries the risk; aggregates answer most questions and should outlive it.
  4. Administrators can usually view everyone, acquired as a side effect of operating the tool.
  5. Viewing should leave a record, or curiosity costs nothing.
  6. Ask for a demonstration that the tool can produce one person's data on request.

Start from the class of problem, not the list of tools

Every selection here names the situation first and the criteria second. Product names come last, and each one carries the line describing what it costs you.