Governance: Who Decides, Who Investigates, Who Sees What

An insider risk programme grants a small group visibility into colleagues' activity. Whether that is acceptable depends almost entirely on the constraints around it, and those constraints have to be written down before anyone has the access.

The four questions

Who can request an investigation? If any manager can ask security to look at an employee, the programme becomes a tool for interpersonal disputes. Restrict it: a named list of roles, in writing.

Who approves it? Requests should not be self-approving. A second person — typically legal or a senior HR figure — signs off before anyone looks at an individual's activity.

Who can see the raw data? A small named group. Not the whole security team, not managers, not IT generally.

What triggers escalation? Defined thresholds for when HR joins, when legal joins, when it becomes a formal disciplinary or criminal matter.

Answering these four in a document, agreed by legal and HR, is the difference between a programme that survives its first contested case and one that does not.

Separation of duties

The people who build detections should not be the people who investigate individuals, and neither should be the people who decide consequences.

This feels heavy for a small team and it prevents the failure mode that ends programmes: an analyst who develops a theory about a colleague, investigates to confirm it, and presents a conclusion nobody independently tested.

Where the team is too small for full separation, the approval step is the substitute. Someone outside the investigation authorises it and reviews the output.

Access to the data

Least privilege applies to the security team too. Analysts reviewing alerts do not need to read the content of every flagged document. Many products allow review of metadata with content access as a separate, logged permission.

Log the watchers. Access to monitoring data should itself be audited, and the audit reviewed by someone outside the team. This is the single most effective safeguard against misuse and the one most often omitted.

Time-box investigation access. Access granted for a specific case, expiring when it closes.

What the programme is not for

Write this down explicitly, because in the absence of a stated limit people will assume the worst and occasionally be right.

Not for measuring productivity. Not for monitoring union or works council activity. Not for tracking who talks to whom for management purposes. Not for personal curiosity about colleagues. Not for identifying whistleblowers, which in many jurisdictions carries specific legal protection.

A programme that is used for any of these once will be assumed to be used for all of them permanently.

Retention

Decide how long you keep monitoring data, and delete on schedule.

Indefinite retention is the default in most deployments and the hardest position to defend. It creates a growing archive of employee activity, discoverable in litigation, subject to access requests, and valuable to an attacker.

Set a period tied to purpose — typically weeks to months for routine telemetry, longer only for open cases.

Transparency to employees

Publish what is monitored, why, who has access, and what the data is not used for.

The instinct is that disclosure reduces effectiveness. Against a determined malicious insider, perhaps marginally. Against negligence — the majority of your caseload — disclosure improves outcomes, because awareness changes behaviour.

And in several jurisdictions covert monitoring of employees is unlawful. The choice is frequently not between disclosed and undisclosed but between disclosed and unlawful.

Review

Annually, by someone outside the team. What was investigated, on what basis, with what outcome, and whether the constraints held.

A programme nobody reviews drifts, and drift in this area is not recoverable once discovered.