Insider risk management: from signals to cases

Insider risk management is the practice of noticing when a person with legitimate access starts to behave in a way that puts company data at risk, and then handling it before data leaves. It is not the same as blocking every USB stick. It is about collecting the right signals from endpoints, scoring them per user so that the few people who need attention stand out, and turning those scores into cases with evidence an investigator, HR or a lawyer can rely on. This guide covers the signals, the scoring, the case work, and what a working program looks like.

Why insiders are a different problem

An outside attacker has to break in. An insider already has a badge, a laptop, a mailbox and read access to the file share. The data they take is data they were allowed to open.

Insiders come in more than one shape:

Type	What it looks like	Typical signal
Departing employee	Copies "their" work in the last two weeks	USB copy, personal cloud upload, large downloads
Careless user	Pastes a customer list into an AI chat to "clean it up"	AI prompt with confidential text, web mail attachment
Over-privileged account	Reads folders the role never needed	Access to shares outside the team, off-hours reads
Compromised insider	Account used by someone else	New device, odd hours, unusual network
Malicious insider	Deliberate, slow, spread over months	Many small events, screenshots, printing

In practice, careless mistakes fill most of the queue. The malicious case is rare and the hardest to see, because each single action looks normal. That is why insider risk management works on patterns over time rather than single alerts. CISA's insider threat mitigation guidance (https://www.cisa.gov/topics/physical-security/insider-threat-mitigation) frames the program the same way: define, detect and identify, assess, manage.

The signals that actually matter

A risk program is only as good as the telemetry under it. The signals worth collecting from the endpoint are:

Removable media. A USB device plugged in, what was copied to it, and whether the device was trusted by serial number. See USB device control: block removable storage without blocking work.
Uploads. Files sent to personal cloud storage, web mail, transfer sites, and AI chat tools. The destination matters as much as the file.
Clipboard. Confidential text pasted out of a protected application. Copy-paste is the cheapest exfiltration channel and the one most programs ignore. See Clipboard DLP: how to stop copy-paste leaks.
Print. Still a way out, and it leaves no network trace.
Screen capture. Screenshots of protected screens, and a phone camera pointed at the monitor.
DLP decisions. Every warn, justification and block, with the policy that fired.
Network changes. A laptop on an unfamiliar network, or a new device for a user who never had one.
Usage. How long the person used the computer each day. A sudden change, in either direction, is context.

What you do not need is keystroke logging or reading private messages. It adds legal exposure and noise.

From signals to a risk score per user

Raw events are useless on their own. A thousand "USB inserted" events a day tells you nothing. A score compresses events into a number per user, so the queue is sorted by who needs attention today.

A workable scoring model has four parts.

Weight by channel and sensitivity

A block on a confidential file weighs more than a warning on a public one. An upload to a transfer site weighs more than a copy to a trusted drive. Keep the weights simple and written down. If the security lead cannot explain why a user is at the top of the list in one sentence, the model is too clever.

Decay over time

A score that only goes up turns everyone red by March. Each signal should fade over days or weeks, so that the score reflects current behavior. An event from six months ago should be visible in the history, not in the number.

Context, not just counts

Two things change what a signal means: the person's role and the moment. A designer copying 2 GB of images to a drive is doing their job. The same volume from someone in finance is not. Any signal in the two weeks after a resignation letter deserves a higher weight, so connect the program to HR events.

A short list, reviewed on a schedule

The output should be ten names, not a dashboard of four hundred. Someone reviews it weekly, notes one line per name, and either closes it, keeps watching, or opens a case.

Deterrence: the cheapest control you have

Detection catches people after the fact. Deterrence changes behavior before it. Three controls do most of the work:

A visible watermark. When a protected screen carries the viewer's name, the time and the device name, photographing it or sharing a screenshot stops being anonymous. Most people will not. See Screen watermarking: a visible name and time on every protected screen.
A reason prompt instead of a block. When a policy asks "why are you copying this to USB?" and keeps the answer, the honest user types one line and gets on with work, and the dishonest one has just written a statement they will have to defend.
Telling people the program exists. A hidden program is less effective and harder to defend. A short, plain policy, signed at onboarding, is enough.

Deterrence also keeps the detection queue short.

Cases, and what good insider risk management looks like

A high score is a reason to look, not a conclusion. The step from "this user looks odd" to "we can act" is the case, and it is where most programs are weakest.

What a case needs

The timeline. Every relevant event for the person, in order, with the file, channel, device and policy decision for each.
The connections. Which files were touched, which devices were used, which other people were involved. A graph view beats a spreadsheet because the question is usually "what else touched this file?"
The evidence. Screenshots kept at the moment of capture, the blocked clipboard content, the justification the user typed. Evidence collected at decision time is strong; evidence reconstructed later is weak.
Access control on the case itself. Only the investigation team should see it. A case about a senior manager readable by the whole IT team is its own insider risk.
An outcome. Closed as benign, referred to HR, referred to legal, or escalated. Record it, because the next case about the same person starts from here.

What good looks like

A company doing insider risk management well has every endpoint reporting the same signal set, including laptops off the corporate network, and has its confidential data classified so the score can tell a sensitive file from a lunch menu. Without classification, every event has the same weight and the score is noise. See Automatic data classification: giving every file a level. The risk list is short and reviewed weekly, HR tells security about leavers on the day, deterrence is visible, cases have an owner, and staff have been told in writing.

Checklist: starting an insider risk program

Decide which data is confidential and classify it, automatically where possible.
Pick the signals: USB, uploads, clipboard, print, screen capture, DLP decisions, network, usage.
Confirm the endpoint agent collects all of them, online and offline.
Write down the scoring weights and the decay period in one page.
Connect HR leaver and joiner events to the score.
Put a visible watermark on the applications that hold the most sensitive data.
Set the riskiest channels to "ask for a reason" before setting any of them to "block".
Define the case workflow: who opens, who investigates, who decides, who can read.
Create a separate role for case access.
Publish a short staff-facing policy and get it acknowledged.
Review the risk list weekly; write one line per name.
Test the whole chain once a quarter with a planned scenario and check the evidence holds up.

How Tracemark does it

Tracemark delivers insider risk management from the same agent and console that run its DLP, device control and endpoint management. The Insider Risk product covers the chain from signal to case:

Signals. The agent records USB activity, network changes, uploads and every DLP decision (clipboard, file copy, print, web uploads, email, AI prompts). Because the DLP engine reads what is actually in the file, not just the name, a decision about a confidential file is recorded as such.
Risk score per user. The console computes a score for each user from those signals, so the list is sorted by who needs attention.
Deterrence. A visible watermark with the viewer's name, time and device appears on protected screens. Screenshots of protected screens are either kept as evidence or blocked. Camera Guard uses the webcam to notice a phone raised at the screen.
Cases. A case links the people, files and devices involved on one graph, so an investigator can see what else touched a file or which device a user carried.
Usage tracking. Computer time per user per day, measured by the agent, gives the context behind a change in behavior.
Evidence. Every DLP decision sits in the Incidents queue with who, what, channel, policy and outcome. It can be searched, saved as a view, exported to CSV or bundled into an evidence pack.
Access. Role-based access in the console means each role sees only what it can use, so case material stays with the people who work on it.

The same agent runs on Windows, with clipboard DLP also on macOS and Linux, and it keeps working offline with policies cached on the device and events queued for later.

Frequently asked questions

What is the difference between insider risk management and insider threat detection?

Insider threat detection is one part of the program: spotting the behavior. Insider risk management also covers deterrence, scoring, investigation and the decision at the end. Detection without a case process produces alerts nobody acts on.

Does insider risk management mean monitoring everything employees do?

No. A good program collects a defined set of data-movement signals (USB, uploads, clipboard, print, screen capture, policy decisions) and tells staff it does so. Keystroke logging and reading private messages add legal exposure and noise, not detection.

How do you avoid false positives in a user risk score?

Weight signals by the sensitivity of the data and the channel, let scores decay over time, and add role and HR context. Then review a short list weekly by a human. The score decides who to look at, not what happened.

What should an insider risk case contain?

A timeline of events with file, channel, device and policy outcome; a graph of the people, files and devices involved; evidence captured at decision time (screenshots, blocked content, justifications); restricted access; and a recorded outcome.

Try it

Try Tracemark free for three months. Claim it at tracemark.ca