Governance: Who Watches the Watchers

The technical questions in UEBA are tractable. The governance questions determine whether the programme is trusted, lawful and survivable, and they are frequently settled informally by whoever configured the tool.

The questions to settle in writing

Who can see scores? Not everyone with a SIEM login. A named group.

Who can see the underlying events for an individual? A narrower group, with the access logged.

Who can request an investigation into a person? If any manager can ask, the system becomes an instrument in interpersonal disputes. Restrict to named roles.

Who approves it? Requests should not be self-approving. A second person — legal or senior HR — before anyone examines an individual in depth.

What triggers HR or legal involvement? Defined thresholds, agreed in advance.

Who can change detection logic, thresholds and exclusions? Change control matters here: an exclusion silently added is a monitoring gap nobody agreed to.

Who reviews the reviewers? The one most often omitted.

Separation of duties

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

For small teams full separation is impractical. The approval step substitutes: someone outside the investigation authorises it and reviews the output before it goes anywhere.

The specific risk this prevents: an analyst forms a theory about a colleague, investigates to confirm it, and presents a conclusion nobody independently tested. This is the failure mode that ends programmes, and it does not require bad intent — confirmation bias is sufficient.

Auditing access to the system

Behavioural monitoring data is exactly the kind of data a curious or malicious insider would want. The security team is not exempt from insider risk, and it has the most access.

Log every query against individual data. Who looked, at whom, when, under what case reference.

Review that log outside the team. Internal audit, or a periodic independent review. Monthly is adequate.

Alert on self-lookup and on lookups without a case reference.

Time-box access. Standing access for everyone is the default configuration and it is the wrong one.

If a programme implements one governance control, this is the one. It is also the one that reassures employees most, because it answers the question they actually have: who is watching, and who watches them?

What the system is not for

State this explicitly, because in the absence of a stated limit people assume the worst and are occasionally right.

Not for measuring productivity. Not for monitoring union or employee representative activity. Not for identifying whistleblowers, who in many jurisdictions have specific protection. Not for management curiosity about individuals. Not for performance management.

A system used for any of these once will be assumed to be used for all of them permanently, and the assumption will be reasonable.

Transparency to employees

Publish what is monitored, why, who has access, what it is not used for, and how access is audited.

The instinct is that disclosure reduces effectiveness. Against a determined adversary, marginally. Against the ordinary population — which is where nearly all your alerts come from — disclosure improves outcomes and is frequently a legal requirement rather than a choice.

Reviewing the programme

Annually, by someone outside the team:

What was investigated, on what basis, with what outcome. Whether approvals were obtained. Whether access logs show anything unusual. Whether the distribution of alerts shows a disparity. Whether exclusions have accumulated. Whether the stated purpose still matches the actual use.

Programmes nobody reviews drift, and drift here is not recoverable once discovered.

A one-page governance charter

Short enough that people read it, specific enough to settle arguments.

Purpose. What the system is for.

Scope. Which populations and data are covered, which are excluded.

Access. Who can see scores, who can see underlying events, how access is granted and revoked.

Investigation. Who can request, who approves, what threshold triggers HR or legal involvement.

Prohibited uses, listed explicitly.

Audit. What is logged, who reviews it, how often, and to whom they report.

Retention. Per data category.

Review. Who reviews the programme annually and what they examine.

Publish it. A charter kept internal to the security team does not do the thing a charter is for, which is to make the constraints visible to the people subject to them.

Common false positives

Governance failures that occur without anyone intending them:

Standing access granted during deployment and never revoked.

Investigations opened informally because a manager asked a colleague directly.

Self-approval, where the person requesting and the person approving are the same in practice.

Scope creep, where a system deployed for security is consulted for a performance question because it was available.

Exclusions added quietly during a noisy period, creating unagreed gaps.

Prohibited uses undocumented, so nobody can say a boundary was crossed.

Each is prevented by the charter and the access audit, and each is very difficult to remediate once it has become normal practice.

Blind spots and assumptions

That governance is bureaucracy. It is what makes a finding defensible when challenged, which is the moment the programme's value is decided.

That the small team makes it unnecessary. Small teams have less separation and therefore need the approval and audit controls more, not less.

That nobody misuses access. Where access is unaudited, misuse is undetectable rather than absent.

That the written policy reflects practice. Verify by sampling investigations, not by reading the document.