Data Minimisation in Monitoring

The instinct in analytics is to collect broadly, because a feature you did not collect cannot be modelled. The instinct in privacy is to collect narrowly, because every field is personal data with obligations attached.

Both are correct. Most deployments resolve this by collecting everything and never revisiting it, which is a decision made by default rather than deliberately.

What minimisation means here

Not collecting less for its own sake. Collecting what serves a stated purpose and being able to say why each category is there.

Purpose specification per source. For each data source, one sentence: what detection does this enable? A source with no answer should not be ingested, and the exercise regularly finds several.

Field-level selection. Most sources carry far more than the analytics use. Email metadata is sufficient for behavioural detection; content is not required. Ingesting only what features consume reduces obligation substantially at no detection cost.

Aggregation where it suffices. Some features need counts, not events. Where a daily aggregate serves, retaining raw events adds exposure without capability.

Retention per purpose. Baselining needs the training window. Investigation needs recent detail. Neither needs three years of raw endpoint telemetry, which is what many deployments accumulate because storage was cheap and nobody set a schedule.

The tiered retention that works

Raw events: short, typically 30 to 90 days. Long enough for investigation, short enough to bound exposure.

Aggregated features: longer, since they support baselining and are far less revealing than the events behind them.

Baselines and profiles: as long as the entity is active, deleted on departure.

Findings and case records: per your case retention policy, usually longer, with restricted access.

Dismissed alerts: short. Retaining every anomaly ever raised about every employee, indefinitely, is difficult to defend and creates a large disclosable record.

That last one is worth stating plainly because it is universal and almost never examined: most deployments retain every alert about every person forever, by default.

Content versus metadata

The most consequential single choice available.

Metadata — who, when, how much, to where — supports nearly all behavioural detection. Volume features, diversity features, relationship features and timing features need nothing more.

Content — what was written, what the file contained — adds relatively little to behavioural analytics and adds enormously to intrusiveness and obligation.

A programme built on metadata is meaningfully more defensible and gives up less than people expect. Where content is genuinely needed, that is a DLP function with its own justification, not something to fold into behavioural monitoring because the pipeline was there.

Access minimisation

Collection is half of it. Who can see the data is the other half.

Analysts see aggregates and contributions by default. Access to underlying events for a specific entity should be a separate, logged permission.

Time-box investigation access. Granted for a case, expiring at closure.

Audit the watchers. Access to behavioural data reviewed by someone outside the team. This is the single most effective safeguard against misuse and the most commonly omitted.

Restrict enrichment visibility. Employment context is useful for triage and does not need to be visible to everyone with queue access.

Reviewing it

Annually, per source: what does it enable, what is it costing in obligation, has anything been detected using it, could a narrower version serve?

Sources that survive this are defensible. Sources that do not should be removed, and the exercise usually finds at least one that was ingested during a project and never used.

An annual source review

One afternoon, per year, that reliably finds sources nobody needed.

List every source, with its ingestion date and its stated purpose.

For each, ask what detection it enables and whether anything has actually been detected using it. Sources with no answer to either question are candidates for removal.

Check the fields. Which are consumed by features, which are retained because they arrived. Narrowing the field set is usually possible without any detection loss.

Check retention against purpose. Raw events retained far beyond the investigation window, aggregates retained beyond the baseline window.

Check who can see it.

Record the decisions. A source retained after review is defensible; a source retained by inertia is not.

Common false positives

Minimisation decisions that look safe and are not, or look risky and are not:

Removing a source that supported an unused detector which was itself broken, so the absence of findings proved nothing.

Retaining content because it might be useful, where metadata already carried the entire signal.

Shortening retention below the baseline window, silently degrading models.

Aggregating away a field that an investigation later needs, discovered only during a case.

Restricting analyst access so tightly that triage requires an escalation every time, which produces slower review and worse outcomes.

The resolution in each case is to tie the decision to a stated purpose and test it against a real triage, rather than reasoning about it abstractly.

Blind spots and assumptions

That more data improves detection. Beyond a point it adds noise, dimensionality problems and obligation.

That retention is free. It is storage cost, breach exposure, disclosure obligation and discovery risk.

That the vendor default is considered. Defaults are set to demonstrate capability, not to minimise.

That minimisation weakens security. A narrower programme that survives regulatory and employee scrutiny detects more over ten years than a broad one that gets switched off after a complaint.