Blog · How it works

Retention is set to delete your data automatically. Here's what stops it for the one employee you're actively investigating

Published 25 August 2026

Automatic deletion is a compliance feature, not a bug - data you don't need shouldn't sit around forever. But an active investigation or a litigation matter can need exactly the records that schedule is about to remove. A legal hold is the exemption that resolves that conflict, and it has to actually be checked at the moment deletion runs, not just recorded somewhere and hoped for.

Retention deletes on a schedule, by category

Every organization sets its own retention window per data category - how long activity sessions, application usage, website visits, security alerts, DLP evidence, report exports, and screenshots are kept before they're deleted. A scheduled job walks every organization's policies and removes anything past its cutoff.

One category is deliberately excluded from this automatic process entirely: audit logs. They're append-only by design and are never touched by the retention job - removing an audit record requires a separate, more privileged path, not a retention setting anyone can configure down to zero.

A legal hold is an exemption, not a separate copy

Placing a hold doesn't duplicate or move any data. It records a scope - which employees are covered - and a reason, and requires step-up re-authentication to create, the same elevated confirmation used for DPIA approval and tenant suspension. When the retention job runs, it first looks up every actively held employee for that organization, then excludes their records from every deletion query it runs, across every category that has employee-level data. Held employees simply don't show up in what gets deleted that cycle - the exemption is applied at the point of deletion, not as an after-the-fact restore.

Screenshots get the same exemption, handled specially

Screenshots aren't deleted by the same generic per-category logic as the rest, because deleting one means removing both a database row and the actual stored image. That path checks the same held-employee list before it deletes either the storage object or the record - a hold protects screenshots exactly as completely as it protects everything else, not as an afterthought bolted onto a different mechanism.

What a hold does not do

• It doesn't restore anything already deleted. A hold placed today protects data from today's retention run onward - it isn't retroactive.
• It doesn't pause monitoring. Collection and a hold are separate systems; a hold tells the deletion job not to touch an employee's existing records, it doesn't change what gets recorded going forward.
• It doesn't do anything special for audit logs. Those were already exempt from automatic deletion regardless of any hold - a hold changes what happens to the categories that are otherwise deletable.

Related reading

• Being logged in isn't enough to approve a DPIA or enable screenshots
• "We log file activity" isn't the same as "we have a client-data audit trail"
• The DPDP 72-hour breach clock, explained

← Back to the blog