Insider threat response plan: evidence, proportion and the employee who may have done nothing

Why this one is different

In every other plan in this library the adversary is outside and speed is the virtue. Here the subject is an employee or contractor with legitimate access, employment rights and, quite possibly, an innocent explanation. The things that make an external response good (move fast, isolate, reset everything) can make this one unlawful, unfair or simply loud enough to destroy the evidence.

CISA's guide frames the work as define, detect and identify, assess, and manage. This plan is the assess and manage half: what to do once somebody has raised a concern about a named person.

The first-hour version is insider data removal. Read this before you need that.

Before anything: three rules

1. Security does not run this alone. HR, legal and the security lead form the case group from the first conversation. Security supplies facts; it does not decide what happens to the person.
2. Need to know, strictly. The subject's manager is not automatically in the group. Neither is the security team at large. Every additional person is a way for the subject to find out and for the organisation to defame someone who did nothing.
3. Only monitoring your policies and your law already permit. If your acceptable use policy and local law allow review of corporate systems for this purpose, use that. If you are unsure, that is the question for legal before any collection, because evidence gathered unlawfully may be unusable and may be an offence.

Phase 1: intake and triage

Goal: decide whether there is something to investigate, without alerting anyone.

1. Record the concern: who raised it, when, what they observed first-hand and what they inferred. Separate those two in writing. Most referrals are inference.
2. Classify the concern. The response differs:

Type	Typical trigger	What is at risk
Data removal before departure	Resignation, then unusual downloads or uploads	Intellectual property, customer data
Misuse of access	Queries outside role, snooping on records	Privacy, regulatory exposure
Sabotage	Disciplinary action or dispute, privileged access	Availability, integrity
Fraud	Finance anomalies, approvals outside process	Money
Unwitting	Credentials used from elsewhere	This is an external compromise. Switch plans

3. Rule out the unwitting insider early. Check sign-in locations and devices for the account. If the activity came from infrastructure the person does not use, you have an account compromise, and the BEC plan or the cloud account playbook applies.
4. Convene the case group and agree scope, in writing: which systems, which date range, which questions. A scope written down is what makes the investigation proportionate and shows that it was.

Phase 2: preserve, quietly

Goal: make sure the evidence still exists next week, without changing the subject's experience.

Order by what expires, per RFC 3227, and prefer collection that needs no contact with the subject's device:

1. Place legal holds on the mailbox, cloud storage and chat for the account. This stops deletion from being effective and is invisible to the user in most platforms.
2. Export the logs that roll soonest: proxy and DNS, cloud storage audit, DLP events, print logs, VPN, badge access. Retention on several of these is measured in days.
3. Snapshot cloud audit data for the scope window: file downloads, sharing to personal addresses, mass deletion, mailbox forwarding.
4. Do not touch the endpoint yet unless sabotage is suspected. An unexpected remote session or a new agent is how subjects find out.
5. Hash what you export and record who collected it and when. The hash manifest tool does this in one command.

Phase 3: investigate

Goal: answer the scoped questions, and only those.

Question	Sources
Did data leave, and where to	Proxy logs for personal cloud storage and webmail uploads, cloud storage sharing events, email to personal addresses, USB device history on the endpoint (registry USBSTOR, setupapi.dev.log), print logs
Was it outside their normal pattern	The same sources for the previous ninety days. Volume alone proves little; a change relative to their own baseline and role is the finding
Was access outside their role	Application audit logs, database query logs, records accessed against cases assigned
Was anything destroyed or altered	Deletion events, change records, backup job changes, new privileged accounts
Were there preparations	Archive creation (USN journal, 7-Zip or WinRAR in process logs), renamed files, clearing of browser history, anti-forensic tools

Two disciplines matter more here than anywhere else:

Look for the innocent explanation as hard as the guilty one. A large download before a holiday, a migration task nobody told security about, a manager's verbal instruction. Write down what you checked to exclude them.

Report observed and assessed separately. "The account uploaded 4.1 GB to a personal cloud storage domain on the 14th" is observed. "The employee stole customer data" is a conclusion for the case group, and perhaps a tribunal.

Phase 4: act

Goal: a decision by the case group, carried out in an order that protects the evidence and the person.

If the group decides to act, sequence it so that access ends at the moment of the conversation, not before and not after:

1. HR and the manager hold the meeting. Security is not in the room.
2. As the meeting starts, disable the account, revoke sessions and tokens, remove VPN and remote access, disable badge access, and rotate any shared or service credentials the person knew. Shared credentials are the step that is forgotten.
3. Recover corporate devices at the meeting. Image them before reissue. Do not power them on to have a look.
4. Remove the person's access to third-party services that are not behind your identity provider: registrars, cloud consoles, social accounts, code hosting.
5. If sabotage was the concern and the person had administrative access, review what they could have scheduled: tasks, cron jobs, cloud automation, CI pipelines, mail rules.

If the group decides there is nothing to act on, close the case, record why, and release the holds. Retain the case file according to policy and no longer.

Phase 5: recover and review

• If data left, assess whether it is a reportable breach and whether recovery is possible through counsel (undertakings, injunctions). That is legal work; the security team's contribution is an accurate inventory of what left and when.
• Review the access model. The CERT guide's recurring finding is that insiders use access they legitimately held. Ask whether they needed all of it.
• Review the leaver process. Most data removal happens in the weeks around a resignation. Heightened logging for that window, agreed with HR and stated in policy, is proportionate and effective.
• Ask how the concern reached you. If it was by chance, fix the route.

What goes wrong

1. The subject is tipped off, by a wide distribution list, a manager's change in tone, or a clumsy collection.
2. Collection exceeds policy or law, and the evidence is excluded or the organisation is the one in trouble.
3. Volume is mistaken for intent. Large transfers are normal for some roles.
4. Offboarding misses the shared credential, the API key or the third-party console.
5. An account compromise is investigated as an insider for a week, while the external operator keeps working.