In short
- The risk window opens 60 to 90 days before a resignation, not on the last day
- Baseline each person against their own history, not a global rule
- Two or three sustained signals together are worth a conversation; one is not
- Define thresholds, reviewers and next steps in writing before switching anything on
Most insider threat programmes are built around off-boarding. Access is revoked on the last day, a checklist is signed, and the risk is considered closed. The problem is that by the last day, anything worth taking has usually already gone.
The window that actually matters
The behaviour that precedes deliberate exfiltration tends to appear well before a resignation is announced — often in the sixty to ninety days before it. That is the period in which someone decides to leave, and in which their access is still entirely legitimate.
This is what makes insider risk awkward to detect. There is no exploit, no malware and no policy violation to alert on. An employee reading files they are entitled to read is indistinguishable from an employee reading files they are entitled to read.
There is no exploit to detect. The signal is not the access itself — it is the change in the pattern of access.
What a behavioural baseline looks like
A workable framework compares each person against their own history rather than against a global rule. The useful signals are unglamorous:
- Volume of documents opened relative to that person’s own ninety-day norm
- Access to repositories outside their usual working set
- Sustained out-of-hours activity where none previously existed
- Bulk operations — archive creation, sync-folder additions, large print jobs
- Movement of data toward personal or removable destinations
None of these is conclusive on its own. Two or three of them together, sustained over a fortnight, is worth a quiet conversation.
The failure mode
The way this goes wrong is when it becomes surveillance. A programme that produces a list of suspects will destroy trust faster than it prevents loss, and in most jurisdictions it also creates legal exposure. The output should be a small number of reviewed anomalies, handled by a named person under a written policy — not a dashboard the whole security team browses.
Define the thresholds, agree who reviews them, agree what happens next, and write all of it down before you turn any of it on.
