Retention and Aggregation

Occupancy systems default to keeping everything forever at full resolution. Almost no planning question needs that, and holding it creates obligations.

The practical lesson in “Retention and Aggregation” is to connect a measurement to a named decision without treating the number as certainty. Teams exploring gdpr employee monitoring can review gdpr employee monitoring as one source of time and project context, while retaining direct feedback and documented outcomes as the basis for interpretation.

The resolution ladder

Raw events: a detection at a device at a second.

For a public, independent reference related to “Retention and Aggregation”, consult the European Data Protection Board guidelines. Its principles provide a useful check on scope, terminology, governance and the claims made during procurement or review.

Minute or quarter-hour counts by zone.

Hourly or daily aggregates.

Monthly summaries.

Each step up removes identifying potential and each is sufficient for different questions.

What each level is for

Raw events: calibration and fault diagnosis. Needed for days, not months.

Quarter-hour by zone: operational scheduling and the occasional detailed question. Weeks to months.

Daily and weekly: the planning questions, which is most of what the programme is for. Years.

Monthly: long-term trend and seasonality. Indefinitely, and it is tiny.

A workable policy

Raw events: thirty days.

Fine-grained counts: twelve months.

Daily aggregates: three to five years.

Monthly summaries: keep.

One table, written down, applied automatically. The automation matters: a policy nobody implements is a statement of intent.

Why keeping less is better

Seasonality needs years of daily data, which is small.

Nothing needs years of minute-level data, which is large.

And the detailed layer is the part that carries re-identification risk, so dropping it on schedule reduces the main exposure.

Aggregating at source

The strongest position: the device transmits counts, not events.

Then the detailed layer never exists, which removes the retention question for it entirely.

Ask about this at procurement, because it is a device capability rather than a configuration you can add later.

Deletion in practice

Check it happens.

Backups, supplier systems and exported reports all persist beyond the primary store, and a retention policy that covers only the database is incomplete.

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

Exports and spreadsheets

The uncontrolled copy problem: somebody exports a detailed extract for an analysis and it sits in a shared folder for four years.

Which defeats the whole policy.

Name the practice, set an expectation, and prefer giving people a view rather than a file.

What to check

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

Does the device aggregate at source, or send events?

What does your supplier retain, and is it in the contract?

And how many detailed extracts are sitting in shared folders?