Explainability and Defensible Findings

A UEBA finding can end in a conversation, a disciplinary process, a dismissal or a prosecution. At every one of those stages someone asks why the system reached its conclusion, and the answer has to survive scrutiny by people who are not statisticians.

This constraint should shape model selection, and it usually does not.

The levels of explanation required

To the analyst. Why did this entity surface? Needed within seconds, dozens of times a day. Requires per-feature contributions displayed alongside the entity's baseline.

To the manager or HR. What did this person do that was unusual, in plain language? Requires translation from features to behaviour: not "feature 14 deviated by 3.2 sigma" but "accessed 40 systems in a day, against a normal range of 3 to 6".

To the individual. Under several frameworks they can request this. It must be comprehensible to someone with no technical background.

To a tribunal or court. The highest bar. Requires that the method be describable, the data be shown to be reliable, and the conclusion be defensible against an expert challenging it.

A model that cannot support the fourth level should not produce findings that reach it.

What makes a method explainable

Simple statistics are self-explanatory. "This person accessed 40 systems; their normal range is 3 to 6; no peer exceeded 12." Anyone can evaluate that.

Rules are explainable by construction. The condition is the explanation.

Tree-based methods can produce a path, though ensembles of hundreds of trees are less tractable than the single-tree case suggests.

Distance and density methods are partially explainable: which features contributed most to the distance.

Neural methods are not explainable without substantial additional work, and post-hoc attribution techniques produce approximations that an informed challenger can attack.

The practical consequence

Use interpretable methods for anything that reaches a person. Complex models are appropriate for prioritising a queue. They are inappropriate as the basis of a finding presented in a process with consequences.

Many mature programmes run exactly this split: opaque models order the work, and any escalation is supported by explicit, simple, checkable observations gathered afterwards.

Never present a score as the finding. Present the observations. "Risk 87" cannot be defended; "transferred 4,200 files to removable media on these dates, against a personal baseline of none in twelve months" can.

What to preserve

For any finding that might be revisited:

The score and the model version that produced it.

The per-feature contributions.

The baseline snapshot the score was computed against. Without it, "unusual" has no referent, and baselines move.

The underlying events, not just the aggregate.

The enrichment applied at the time, since roles and attributes change.

The analyst's reasoning, recorded contemporaneously.

Products routinely retain the score and discard the rest, which forecloses defence months later when it is needed.

The vendor question

Ask directly, during evaluation: show me the explanation an analyst sees, and show me what I would hand to an employment lawyer.

If the answer is a score, a chart and a list of contributing events without baselines, the product is usable for triage and not for anything further. That may be acceptable — provided the programme is designed around it.

Where explainability and accuracy trade off

Sometimes a more complex model genuinely detects more. The trade is real.

The resolution that works: let the complex model rank, and require that any escalation be independently supportable by explicit evidence. If an analyst cannot construct a simple, checkable account of what happened, the case does not proceed on the model's word.

This preserves the detection benefit and refuses to let an unexplainable score become a consequence for a person.

Writing an explanation that survives challenge

The practical test: could this paragraph be read aloud in a hearing without an expert to defend it.

State the observation with numbers. What was done, how much, when, against what personal and peer baseline.

State the data basis. Which sources, over what period, with what known gaps.

State what was ruled out. Data defects, account compromise, structural explanations, approved workflows — and how each was checked.

State what remains unexplained, honestly. A finding that acknowledges its limits is stronger than one that does not.

Avoid the score entirely. It adds nothing that the observations do not, and it invites a question with no good answer.

Attach the underlying events, so that anyone can verify the aggregate.

Written this way, an explanation is a factual account rather than a model output, and it does not depend on anyone accepting the analytics.

Common false positives

Explanation failures that undermine otherwise sound findings:

Score-led narratives, where the number came first and the reasoning was assembled to support it.

Baselines quoted without their window, so "unusual" has no defined referent.

Aggregates without underlying events, which cannot be independently verified.

Peer comparisons against the wrong group, discovered during challenge.

Post-hoc feature attribution presented as the model's actual reasoning when it is an approximation.

Missing context that was available — a role change, an approved project — which, once produced by the person, discredits the whole account.

Blind spots and assumptions

That explainability can be retrofitted. For some architectures it cannot, and the choice was made at procurement.

That the analyst's explanation is the model's. Analysts construct plausible narratives from contributing factors. That is not the same as the model's actual computation, and the difference matters under challenge.

That nobody will challenge it. The first serious case will be challenged by someone whose job is to find the weakest link.

That documentation of the method is enough. A method description does not explain a specific decision about a specific person, which is what is actually asked for.