Skip to content
Sections
All notes

All notes · Monitoring

Retention of Monitoring Data

How long to keep what the monitoring produces, which for this category should be shorter than instinct suggests.

Monitoring · Procedure

Monitoring generates a data holding about employees. The programme's own retention decisions deserve as much attention as the provider terms it was set up to police.

Applying the boundary described in “Retention of Monitoring Data” requires a clear operational purpose and a record that can be reviewed without reading private content. Teams considering task time tracking can use workload and time evidence to understand how approved processes are actually used, while keeping AI discovery, security telemetry and employee monitoring separate and proportionate.

For an independent benchmark, compare the local approach with ICO artificial-intelligence guidance; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

What accumulates

Destination logs: which services were reached, by whom, when.

Inventory snapshots.

Alerts, with whatever content triggered them.

And in some configurations, prompt content itself.

The last two are personal data about identifiable people and should be treated as such.

A workable schedule

Destination logs: whatever your general network log retention is, typically weeks to a few months.

Inventory: current state plus a short history, because trend matters.

Alerts: resolved alerts retained briefly; substantiated cases retained per your incident policy.

Prompt content on non-matches: not retained at all.

That last line is the one that matters and it is a configuration choice available in most products.

Why shorter is better here

The data is sensitive, the investigative value decays quickly, and a long holding is both a target and an obligation.

Nothing in programme-level reporting needs individual records from eight months ago.

Aggregate counts can be kept indefinitely because they are small and not personal.

Aggregate early

Daily counts by service and department, retained long.

Individual records, retained short.

This gives you the trend for reporting and removes the holding that creates exposure.

Most tooling will do this if asked; almost none does it by default.

The access request point

If you hold personal data, somebody can ask what you have about them.

Being unable to answer is itself a problem, and answering means producing their monitoring record — which is an uncomfortable document if it contains prompt content.

Short retention is the practical answer, because data you do not hold cannot be requested.

Deletion in practice

Check that it happens: backups, the supplier's systems, exported extracts in somebody's folder.

A retention policy covering only the primary store is incomplete.

And get the supplier's own retention in the contract, which the procurement note covers.

When the programme ends

Delete, confirm, and say so.

Monitoring data outliving the programme that justified it is the clearest possible example of purpose drift, and it is extremely common because nobody owns switching it off.

What to check

Is prompt content retained on non-matches?

What is your retention for alerts, and is it enforced?

Could you answer an access request about monitoring data?

And does anybody own deletion when the programme ends?

The point

Do not retain prompt content on non-matches.

Data you do not hold cannot be requested, leaked or repurposed.

Underlying all of this

Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.

The recurring pattern

The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.