Comprehensive Insider Visibility

Part 2 of 4: Comprehensive Insider Visibility 

Why the evidence chain matters, and why no single data source can build it 

In Part 1 we talked about why the Insider Threat Matrix™ matters: it gives everyone a shared language for insider risk. Motive. Means. Preparation. Infringement. Anti-forensics. That alone is worth a lot, because it stops Security, HR, and Legal from talking past each other. 

But the follow-up question is the one that really matters: can you actually see enough to use that framework well? 

An investigation is only as strong as the evidence underneath it. Not the alert count. Not the dashboard. The evidence. And for insider risk, that evidence almost never lives in one place. It's scattered across endpoint, email, cloud, chat, AI prompts, identity context, and sometimes a manager who noticed something felt off before any system did. 

So, Part 2 is about visibility that spans the whole lifecycle, maps back to the Matrix, and gives investigators the whole user story from day one. In this blog, I’ll answer the top questions I hear from customers about visibility. 

 

The first clue is rarely the last thing that happens 

Where does the story actually start? 

A lot of programs still treat insider risk as a "catch the exfiltration" problem. Someone downloads a file. Someone copies data to USB. Someone emails a sensitive attachment to a personal account. Case closed. 

Except that's not how these cases feel when you trace them backward. 

The final act is usually the loudest signal, but it's almost never the first meaningful one. The story starts earlier. A tone shift in chat. An odd question in email. A sudden interest in files outside someone's normal lane. A strange AI prompt. Downloads that look a lot like staging. 

If you can see the behavior where it actually happens, you can connect the before, the during, and the after instead of rebuilding the case from fragments. Which raises the obvious question: where does each of those pieces come from? 

 

One lifecycle, many sensors 

Why doesn't any single data source tell the whole story? 

Here's the division of labor I've come to rely on: 

• Endpoint shows the activity 

• Email and chat show the motive 

• Cloud shows the movement 

• AI shows what the user tried to do with the data 

• Identity and HR context show who this person is in the org and what pressure might be in play 

Each of those is useful alone. None of them covers the Matrix on its own, and that's the part that gets underestimated. 

Lay the sources against the lifecycle and the gaps jump out. Motive lives almost entirely in communications, relationship circles, and HR context. Means lives in identity and access. Preparation shows up on the endpoint and in cloud as staging, renaming, unusual access. Infringement is where endpoint, cloud, email, and AI activity converge. Anti-forensics is back on the endpoint: deletions, cleared history, archives that vanish. A program built on endpoint and cloud alone sees the middle of the story with no beginning. A program built on communications alone sees the beginning with no proof of what happened next. 

That's why integration isn't a feature request. It's the whole point. Technical indicators tell you what a person did. Sentiment tells you why, and often tells you first. Stitched together, they cover the breadth of the lifecycle. Separated, each one leaves you guessing about the phase you can't see. 

But "together" assumes you can actually read the communications side, and that's where most programs reach for the wrong tool. 

 

Keyword lists always run out of road 

If people know they're monitored, why would a wordlist catch them? 

The moment insider risk comes up, someone suggests a keyword list, and it haunts me from years of managing these. Sure, keyword lists catch the obvious stuff. But the obvious stuff is not where the hard cases live. 

People know they're being monitored in many cases. The technically savvy ones usually know first. They get vague. They use coded language. Sometimes they don't even realize they're signaling risk, because the motive is buried in frustration, sarcasm, or a half-joke that still carries weight. 

Then there's language itself. Native translation is not a bolt-on, and in most understaffed programs nobody is manually interpreting everything at the pace the business moves. Different languages carry different tone and shorthand, so the same intent shows up wearing very different clothes. 

A static list breaks under all of that. It only recognizes the phrases it was handed last quarter. The better model is a framework that grows as practitioners learn from real cases. 

Which usually prompts the next objection. 

 

"But won't the smart ones just hide it?" 

Why concealment fails under pressure? 

I hear this pushback constantly, and it's fair. Some will. 

But hiding takes discipline, and discipline is the first thing to go when emotions run high, and that half-coded exchange is often the piece that ties the rest of the evidence together. 

And here's what real cases keep showing: people start covering their tracks while they're in the act, not before it. Clean-up is reactive. Motive and preparation are almost always messier than anti-forensics, because the person hasn't started worrying yet. 

The harder version of this question isn't about hiding at all. 

 

"Everything they're doing fits the role. What are we missing?" 

Where does motive live when the logs look like a typical day? 

This is the question I get most, and it's the right one. The obvious cases take care of themselves: the bulk download at 2 a.m., the USB on the way out the door, the forward to a personal address. Those trip a rule. But how about the privilege administrator that appears to just be doing admin things? The cases that worry many are the ones where every action is consistent with the job. The analyst who pulls reports pulls reports. Nothing in the endpoint or cloud telemetry looks wrong, because on its own, nothing is. If the technical layer is all you have, these people are invisible right up until the moment they aren't. 

What surfaces them is motive, and motive rarely shows up in a log. It shows up in sentiment: a tone that's turned, a grievance that keeps resurfacing, a sudden vagueness with people who used to get straight answers. And it shows up in HR context around catalyst events: a bad review, a denied promotion, a layoff notice, a new manager, a resignation. Line one of those up with the timing of otherwise-normal activity, and the picture changes completely. 

That's why the HR relationship isn't a governance formality. Programs that build real playbooks with HR, covering who flags what, when, and what happens next, are more likely to be running proactively rather than reacting to incidents. Without that channel, motive signals stay in a manager's head while the telemetry says everything is fine. 

 

"What about the ones that are trained to hide it?" 

Do infiltrators leave the same trail as a disgruntled employee? 

A trained infiltrator is a different animal from a tech-savvy employee who got careless. The fraudulent joiner, the DPRK IT-worker pattern being the well-known example, doesn’t have a grievance. There’s no catalyst event. Their discipline isn’t emotional. It’s operational. 
But absence is a signal too. Real employees have texture. They may complain about meetings, get chatty on a Friday, settle into a rhythm. Infiltrators tend to be flat: scripted replies, recurring camera excuses, avoidance when challenged directly, response times that don’t match the timezone they claim, identity details that don’t line up across HR, IT, and access records. Endpoint and cloud fill in the rest: broad SharePoint access early; bulk pulls that outrun the job, clean-up before anyone has asked a question. 

Mapped to the Matrix, they can move through all five phases in weeks. Different signs, same lesson: one data source misses them; integrated telemetry doesn’t. 

So what does reading motive actually involve? 

 

Sentiment is a behavioral indicator, not a hunch  

What can tone tell you that a log can't? 

Sentiment gets misunderstood. Some folks hear the word and picture a machine trying to read feelings. That's not the useful version. 

The useful version is practical: watch for tone, escalation, concealment, grievance, coercion, urgency, and shifts of time. People hint. They hedge. A user can look perfectly fine in endpoint telemetry while chat shows pressure building before the risky action ever lands. 

That's why sentiment belongs in the detection layer as a corroborating factor, right next to endpoint, email, cloud, and AI activity. It answers questions logs can't. Was this accidental, negligent, reckless, coerced, or malicious? Did the tone shift before the technical event, or after? Those distinctions matter to HR and Legal, because the response should fit the situation. 

One more thing that gets underinvested: human reports. A manager notices a tone change. A peer flags a weird message. Those aren't soft signals. They're frequently the first branch of the evidence tree. 

Here's how the layers look when they're all in play. 

Comprehensive visibility is not about monitoring everyone equally. It's about applying governance, risk thresholds, and contextual review so investigators see only the information necessary to evaluate risk. 

 

You already have the logs, and most of you already use them 

So why is triage still the bottleneck? 

Here's what I hear from nearly every team: they already pull this data at some point, and they lean on it to understand the why behind an alert. And contrary to the perception that analysts want to read everything, they don't. They want to see the risk they need to see and none of the rest. The catch is that the mechanism has to support that, and neither manual reading nor lexicon triggers do. 

This is where the LLM piece earns its place. Not as a replacement for judgment. As the first pass that takes on the boring review: scanning content continuously, weighing it against the custom risk behaviors your organization actually cares about, mapping them back to the Matrix, and surfacing only what deserves a human's attention. 

That only works with guardrails, and this part is non-negotiable: masking by default, risk thresholds that gate what gets surfaced, tiered role-based access to detail, HR and Legal alignment on scope, and audit logs on the whole thing. Controlled, defensible review where the right people see the right level of detail at the right time. 

Get that right, and something else changes: when you see the signal. 

 

The early window is where your options live 

What does seeing it sooner actually buy you? 

The earlier you see the signal, the more choices you have. Once the file is out, the chat deleted, and the browser history cleared, you're documenting aftermath. 

Motive and preparation are where leading indicators sit: a shift in tone, pressure from outside, small actions that look like nothing alone and something together. That's also where you can tell whether someone is malicious, negligent, reckless, or just having a terrible week. That distinction changes everything downstream. HR may need one path, Legal another. A user may need intervention before behavior becomes an incident. 

 

Where Parts 3 and 4 pick up 

What has to be true before protection and investigation get smarter? 

Part 3 moves into dynamic protection: reducing exposure without breaking normal work, which only works when the system can tell routine activity from risk that's building in real time. Part 4 explores how connected telemetry shortens investigations, reduces dead ends, and gives analysts the evidence they need to validate risk in minutes rather than hours. This gives them the lead time they need to protect the people, data, and brand.  

Both depend on what we covered here. No sentiment, no real read on motive. No visibility, no reliable protection. No integrated telemetry across the lifecycle, no trustworthy automation. No evidence chain, no defensible case. 

Insider risk isn't usually hidden in a single event. It's hidden in the connections between events. The organizations that see those connections earliest have the most options, the strongest cases, and the best chance to intervene before an incident becomes a breach.  

So, here's what I'm curious about: in your program, how far back does the first meaningful clue usually show up, and what actually leads to substantiated cases? Or are we still banking on someone simply noticing that something feels off and hoping it’s shared with us in time to change the outcome?