HR asks you to justify a 92 UEBA risk score to the employee it belongs to - what do you say?

## Why this is a leadership question and not a triage question A user risk score is the one output of a security stack that is *about a person*. When a case reaches a line manager and an HR partner, the security team stops being the reader of the tool and becomes the party making an assertion about an employee. What you are willing to assert, and on what basis, is an organisational commitment - and it should be settled before the first case, not in the meeting. The uncomfortable property at the centre of it: an additive risk score is **not reconstructable in the room**. Eleven contributing reasons with product-supplied weights, computed against a learned baseline and a cohort assembled from HR attributes, produce a 92. Even the analyst cannot say why it is 92 rather than 71 in terms a non-specialist could check, and the weights are frequently vendor defaults nobody in the organisation chose. ## What you can and cannot defend **Defensible:** the observations. "On these four nights this account established VPN sessions between 22:40 and 02:10. On the second night it authenticated to file server FS-07, which this account had not accessed in 90 days. Over those nights it read 41 GB from the reporting share, against a 30-day median of roughly 5 GB." Every one of those is a record, with a source, a timestamp and a retention period. They can be re-read and they can be challenged. **Not defensible:** the total. "The system rated you 92 out of 100" invites a question - what makes 92 - whose honest answer is "a set of weights we did not choose, summed over reasons that partly describe the same event". Presenting the number as though it were a measurement of the person is the failure mode this whole scenario exists to teach. There is also a claim-direction point worth stating plainly to a non-technical audience: the records show a **credential** was used. They do not by themselves show who was at the keyboard. That cuts both ways - it is a caution against over-claiming, and it is why the employee's own account of the week is evidence, not an excuse to be dismissed. ## Contestability The practical test for whether you are treating someone fairly is: **can the subject dispute it?** A person can dispute a fact - "that was not me, I was on a flight", "I opened those files because finance asked me to, here is the request". A person cannot dispute a weight, a percentile computed over a cohort they have never seen, or a baseline they cannot inspect. So an investigation that turns on the score is an investigation the subject has no way to answer, which is exactly the situation that produces both injustice and, eventually, a formal grievance the security team cannot support. Concretely, this leads to a small number of commitments worth making in advance: - Scores rank the SOC's work queue. They are never quoted as a finding, in a case record, in a report to management, or to the subject. - Any statement made about an employee cites specific records, with times, systems and what the comparison was. - The subject's explanation is sought before any conclusion is written, unless there is an active reason not to alert them - and if there is, that is a deliberate, recorded decision with a named owner rather than a default. - The absence of a raised score is never offered as exoneration either. It is as uninformative in the person's favour as it is against them. ## Closing it honestly When the explanation holds up - the quarter-end close, the reorganisation that left her as the only person in her role - the correct label is **benign true positive**: the activity happened, it genuinely deviated from the baseline, and it was authorised. Not a false positive. The distinction survives into the record that HR and the manager keep, and it says something different about the employee: the tool was not wrong about what she did, and there is nothing here that reflects on her. The score itself is usually left alone. It decays over the window, and retracting points does not undo anything; the useful repairs are upstream - rebuild the single-member peer group into a real cohort, and treat under-sized or stale cohorts as a data-quality issue with an owner. If the same person surfaces again next quarter with the same reasons and nothing was fixed, the third appearance starts to read as a pattern about her rather than a pattern about the group, and that is a harm the security team caused. ## The tradeoff to own Refusing to act on scores alone costs something: the queue is long, verification is slow, and a policy of "records or nothing" means fewer cases closed per shift. The counter-position - acting on the number because it is fast - trades a person's standing for throughput on evidence nobody can explain. Being able to state that tradeoff explicitly, and say where the line sits and who decided it, is what the question is really testing.