The essentials in 30 seconds
- An internal user has nothing to bypass to access the data: it all plays out at the moment of exit.
- Negligence and malice call for two distinct tests; start with negligence, the most frequent.
- You test the controls, never the people: dedicated accounts, synthetic data, an approved framework and regular replay.
Insider threat refers to the risk that a user with legitimate access (employee, contractor, apprentice, administrator) takes data out of the company, by mistake or deliberately. Testing exfiltration by insider threat means replaying, with synthetic data and an approved framework, the actions a trusted user could take, in order to check that your controls block them or at least detect them.
The key point: an internal user has nothing to bypass to access the data. They already have it. Everything therefore plays out at the moment of exit.
Why insider threats escape conventional controls
Most security measures are designed against an intruder: strong authentication, detection of abnormal behaviour on a compromised account, segmentation. Faced with an employee opening a file they consult every day, these barriers do not fire. The access is legitimate, the time is normal, the workstation is known.
There is only one place left where you can act: the egress channel. Attachment to a personal address, synchronisation to a personal cloud, USB stick, printing, copy and paste into a generative AI tool, external sharing from a collaborative workspace. This is precisely the territory of DLP, and it is also where poorly calibrated rules let flows through without the slightest signal. We detail this phenomenon in the article on DLP false negatives.
Diagram · the only point of action
Negligence or malice: two profiles, two tests
Confusing the two leads to bad tests. The negligent employee is not trying to hide. The malicious employee, on the other hand, makes an effort, often a modest one, to avoid alerts.
| Criterion | Negligence | Malice |
|---|---|---|
| Intent | Working faster, “taking work home” | Keeping or monetising information |
| Typical channels | Personal email, personal cloud, AI tools, public link sharing | Same channels, plus splitting, renaming, archiving, removable media |
| What the test must prove | The basic rules block or warn the user | Simple variations do not defeat detection |
| Expected response | Block with an educational message | Block and an actionable alert for the SOC |
For malice, stick to variations that any user would find on their own: changing the extension, compressing, splitting into several sends, using another service. The aim is not to build an attack technique, but to check that the rule does not rest on a single fragile attribute.
An employee’s departure: the scenario to test first
The notice period concentrates the risk. The person still has all their access, knows the value of the documents and has a concrete reason to keep a copy: customer file, commercial proposals, technical documentation, contract templates.
A concrete scenario
A sales engineer resigns and is joining a competitor in three months. During the final weeks, he exports his portfolio from the CRM, sends it to his personal mailbox “to keep his contacts”, then synchronises a folder of proposals to personal storage. No alert, because each action, taken in isolation, looks like his usual work.
This scenario is easily replayed with synthetic data: a decoy CRM export, fictitious proposals marked as confidential, a test account placed in the group of departing employees. You then observe three things: what is blocked, what is only logged, and what gets through without a trace.
What to check on the organisational side
- Does the HR signal (resignation, mutually agreed termination, end of assignment) actually reach security, and how quickly?
- Is there a reinforced policy for departing accounts, and does it apply to every channel?
- Are contractors and temporary staff covered, given that they often sit outside the HR process? The subject ties in with data leaks at third parties and contractors.
- Are the alerts generated handled by someone, or do they land in a queue that nobody reads?
Next step
Would your controls see a prepared departure?
A 30-minute guided demo, on pre-built result sets: the campaign across the 8 channels covered, the report and its detail, nothing to install. The POC then replays one standard scenario with synthetic data, from a representative machine in your network, through your real egress controls. What actually gets out through your egress paths is what the pilot shows you.
Testing ethically and within a framework
Testing insider threat touches employees. A poorly framed test can look like individual surveillance, which raises legal questions and damages trust. The principle to hold: you test the controls, never the people.
The rules of the framework
- Dedicated test accounts. The scenarios are played from accounts and workstations created for the exercise, not by impersonating a real employee.
- Synthetic data only. The files taken out are decoys that imitate the form of your sensitive data without containing any. If the test succeeds in getting something out, no real data is exposed. See our article on synthetic data in production.
- Written approval. The scope, the channels tested and the dates are approved by management, the DPO and, depending on your organisation, the legal team and employee representative bodies.
- Informing the SOC according to the objective. If you are measuring detection, a designated contact is informed to avoid a disproportionate escalation. If you are only testing blocking, the team can be informed in advance.
- Controlled destinations. The personal accounts, external storage and receiving addresses used belong to the test team and are destroyed afterwards.
- Reporting on the controls. The deliverable talks about rules, channels and configurations. It names no one.
The channels to cover
- Outbound email to personal domains (method detailed in Email DLP: testing your rules)
- Upload to a personal cloud via the browser or a synchronisation client
- External sharing from collaboration tools (public link, external guest)
- Copy and paste into a generative AI assistant
- Removable media and printing
- Bulk export from a business application (CRM, ERP, document management)
- Remote workstations, off VPN, where network controls no longer apply
For each channel, note the expected result (blocked, warned, logged) and the observed result. The gap between the two is your work list. The general framework of this approach is described in our guide to data exfiltration testing.
Replay over time, not just once
A one-off test gives a snapshot. Yet DLP rules move: an agent update, a new SaaS application adopted by a team, an exception added to unblock a project and never removed. A channel closed in January can be reopened in March without anyone noticing. Regular replay of the same scenarios makes it possible to measure the posture over time and to spot regressions as soon as they appear.
Frequently asked questions
Should employees be told that an insider threat test is taking place?
The test covers dedicated accounts and synthetic data; it monitors no employee. General information about the existence of security controls and regular testing is nevertheless good practice. Have the arrangement approved by your DPO and your legal team.
Is a behavioural analytics tool enough against insider threats?
No. It helps spot atypical behaviour, but a discreetly prepared departure often looks like normal activity. You also need controls that act on the egress channels, and evidence that they work.
Which scenario should you start with?
Sending a synthetic sensitive file to a personal mailbox and a personal cloud, from an account placed in the group of departing employees. It is simple, quick and very revealing.
Should administrators be included?
Yes. They often have exceptions to DLP rules. Check that these exceptions are justified, documented and limited.