Every monitoring policy covers what is collected and who can see it. Most stop there. Retention gets a sentence, if it gets anything, and the sentence is usually a paraphrase of whatever the vendor's default happens to be.
That is a mistake with a long fuse. A collection that was proportionate on day one becomes disproportionate by year three purely through accumulation, and the organisation usually discovers this at the worst possible moment — during a breach, a subject access request, or a discovery order.
Why "we'll keep it in case" is the wrong instinct
The instinct to keep everything comes from a reasonable place. Storage is cheap, and nobody has ever been fired for having data available. But monitoring data specifically carries costs that scale with time.
The first is breach exposure. A behavioural archive covering four years of every employee's application usage, working hours and activity patterns is a genuinely attractive target and a genuinely damaging loss. Thirteen months of the same data is a materially smaller incident. Retention is a security control, not just a compliance one.
The second is discoverability. Data you hold can be requested. In the EU and UK, employees have access rights over it. In litigation it can be subpoenaed, including in disputes you did not anticipate — a wrongful dismissal claim, a discrimination case, a commercial dispute where someone's working hours become relevant. Every additional year is additional surface.
The third is the one that actually bites: purpose creep. Data that exists gets used. You collected activity metadata for capacity planning, and three years later someone in a disciplinary process asks whether the record can establish what an employee was doing on a particular Tuesday. It can. That is a new purpose requiring its own lawful basis and notice, and the pressure to skip that step is enormous precisely because the data is right there. The cheapest control against purpose creep is not having the data — which is a retention decision made years earlier.
What the law actually requires
Almost no jurisdiction gives you a number, which is why this is hard.
What most give you is a principle. Under GDPR and UK GDPR, personal data must be kept in a form permitting identification no longer than is necessary for the purposes for which it is processed. Canada's reasonableness standard reaches the same place by a different route, as does India's DPDP framework and most modern privacy law. The GDPR checklist and the UK/ICO guide cover the surrounding obligations.
A principle is harder than a rule, because you cannot comply by pointing at a number. You have to be able to explain why your period is the right one for your purpose. The good news is that this explanation is short if you did the earlier work: you named a purpose, the purpose implies a time horizon, and the retention period follows from the horizon.
Where fixed schedules do apply, they usually come from somewhere other than privacy law — a regulator's record-keeping rules, a client contract, sector requirements like HIPAA audit controls. Those are floors on specific data, not licence to keep everything else.
Working out the period from the purpose
The question that produces a defensible answer is: what is the longest useful lookback for the decision this data informs?
For capacity planning and workflow analysis, that is usually a year or slightly more. You want to see seasonal variation and compare this quarter to the same quarter last year. Beyond that, the organisation has changed enough that the comparison is not meaningful — different team, different tooling, different product. Thirteen months covers it, and the extra month exists so a full year-over-year comparison is possible on the last day of the period.
For burnout and working-pattern signals, shorter. These are early-warning indicators and their value is recency; a six-month window is more than adequate and arguably more useful, because old data dilutes current signal.
For security audit logs, longer, and governed by your incident response requirements rather than analytics needs. A year is common; regulated environments often require more.
For anything tied to a legal hold, retention is suspended and the schedule does not apply. Make sure the mechanism for this exists before you need it.
A workable default for a workforce analytics deployment:
| Data | Period | Why |
|---|---|---|
| Raw per-person activity events | 3 months | Detail is only needed for recent investigation of a data quality question |
| Daily per-person summaries | 13 months | Supports year-over-year comparison at team level |
| Team and org aggregates | 24-36 months | No longer personal data if aggregation is genuine |
| Security and access logs for the tool itself | Per your IR policy | Different purpose, different owner |
The shape that matters here is the tiering. Most organisations treat retention as one number applied to everything, when the useful design keeps detail briefly and summary longer.
Making it real rather than aspirational
A retention policy that lives in a document and not in the product is not a retention policy.
Check that your tool actually enforces periods rather than merely displaying a setting. Ask the vendor what happens to data at expiry: is it deleted, soft-deleted, or hidden from the interface while remaining in backups? Backups are where retention promises usually go to die, and "deleted from the application" is not the same claim as "no longer held".
Decide what happens when an employee leaves. Their historical data is still personal data, and the purpose that justified collecting it has ended. Most organisations should delete on a short timer post-departure, retaining only what a legal or payroll obligation requires. This is also the moment to check the offboarding process actually triggers it.
Write down who reviews the schedule and when. Annually is enough. The review exists so that a period set for a purpose that no longer exists gets shortened rather than inherited forever.
And put the periods in the employee-facing policy. "We keep detailed activity for three months and daily summaries for thirteen" is a specific, checkable commitment that does more for trust than a page of principles — the policy template has a slot for exactly this.
Retention also determines how two awkward events go. When an employee asks for their monitoring data covers the disclosure side, and if your monitoring data leaks covers why a shorter retention is a security control rather than only a compliance one.
Where ProdView fits
Retention is configurable in ProdView rather than fixed, and the collection is narrow to begin with: activity and application metadata, never screen content or keystrokes, screenshots optional and off by default. A smaller collection makes a shorter retention period easier to live with, because there is less that anyone wants to keep. Employees see their own data throughout, which is what makes access requests routine rather than an event.
When not to pick us: you have a regulatory obligation to retain session recordings or forensic detail for years. That is a real requirement in some sectors, and a UAM tool built for evidentiary retention is the right answer for the seats it covers.
Try before you commit
Three seats are free forever, which is enough to check what the tool actually deletes and when, before you write a policy promising it. Model the payback with the ROI calculator if the business case comes first.
General information as of August 2026, not legal advice. Retention obligations vary by jurisdiction and sector; confirm yours before setting a schedule.