When an employee or contractor walks out with your data, the investigation is as much an HR and legal process as a security one, and a misstep in either can lose the evidence or the case. Insider data theft rarely involves malware or a broken control: the person uses access they legitimately hold, often in the weeks around a resignation. This playbook template gives [Organisation] a repeatable response with named roles, decision points, the evidence to preserve and the privacy checks that must happen before anyone starts looking at an individual's activity. It is written for security operations, insider risk, HR, legal and the executives who approve decisions. Replace every [Organisation] placeholder and align it with your local employment and data protection law. It is guidance, not legal advice.
How to use this template
- Adopt it as a sub-playbook of [Organisation]'s incident response plan. See the Incident Response Plan Template.
- Agree it with HR and legal before you need it. Who may authorise targeted monitoring, who interviews the subject and when access is removed are all decided in advance, not during the case.
- Keep the circle small. Insider cases are confidential by default: the case team is named in section 2 and nobody else is briefed without the incident lead's approval.
- Keep decision points explicit. Each "Decision" line names who decides and on what evidence, and every decision goes in the case log.
- Exercise it yearly with a departing-employee scenario. See the Tabletop Exercise Scenario Pack.
CISA defines an insider as anyone who has or had authorised access to, or knowledge of, an organisation's resources, which includes contractors, vendors and former staff. Its mitigation framework (Define, Detect and Identify, Assess, Manage) is the programme this playbook sits inside. See the Insider Threat Programme Guide and the Insider Data Theft Guide for prevention.
1. Scope and triggers
1.1 This playbook applies to suspected or confirmed unauthorised copying, removal or disclosure of [Organisation] data by a current or former employee, contractor, outsourced support agent or partner using access they were given.
1.2 Variants in scope:
| Variant | Typical signs | Main risk |
|---|---|---|
| Departing employee taking data | Bulk downloads, sync to personal cloud or USB in the 30 to 90 days before the leaving date | Intellectual property, customer lists, source code to a competitor |
| Bribed or recruited insider | Record lookups unrelated to assigned work, screenshots, steady low-volume access | Customer personal data sold or used for fraud |
| Disgruntled or malicious user | Access to repositories outside role, mass email to personal address | Leak, extortion or sabotage |
| Negligent disclosure | Data pasted into personal or public AI tools, shared links set to "anyone" | Uncontrolled copies of confidential data |
| Former staff with live access | Sign-ins, API calls or key use after the leaving date | Continued access through credentials never revoked |
1.3 Triggers: an insider risk or DLP alert; an HR referral (resignation to a competitor, disciplinary action); a manager or colleague report; a customer or third party finding [Organisation] data outside [Organisation]; an extortion demand; activity by an account whose owner has left.
1.4 Out of scope: an external attacker using a stolen employee account. That follows the Account Takeover Response Playbook. If triage shows the account was compromised rather than misused by its owner, switch playbooks and record why.
2. Roles and contacts
| Role | Named lead | Responsibilities |
|---|---|---|
| Incident lead (insider risk or security) | [Name, phone] | Opens the case, owns the case log and evidence register, coordinates all parties |
| Security analyst or forensic examiner | [Name] | Collects logs and device images, maintains chain of custody, writes the technical findings |
| HR business partner | [Name] | Employment facts (notice date, role, contract terms), plans interviews and any suspension |
| Legal counsel | [Name, external firm] | Privilege, lawful basis for investigation, injunctions, law enforcement referral, notification duties |
| Data protection officer | [Name] | Proportionality and DPIA for targeted monitoring; personal data breach assessment |
| Identity and IT administrator | [Name] | Account, token and device actions on instruction from the incident lead |
| Data or business owner | [Name] | Confirms what the data is, its sensitivity and the business impact |
| Executive sponsor | [Name] | Approves covert monitoring, legal action and external communication |
2.1 The subject's line manager is not on the case team unless legal agrees. Managers may be told only what they need to support a suspension or interview.
3. Detection and triage
3.1 Open a confidential case. Record the trigger, time, reporter and the person's identity in the case system with restricted access. Use a case number, not the person's name, in tickets and chat.
3.2 Check privacy before looking. The DPO and legal confirm the lawful basis and that the planned review is proportionate. Under UK ICO guidance, covert monitoring is only justified exceptionally, for example suspected criminal activity or gross misconduct where telling the worker would prejudice detection; it needs senior management authorisation and a DPIA, and must be targeted and time-limited. Use pseudonymised alerts where your tooling supports it until the case is opened. See the Employee Monitoring and Privacy Guide.
3.3 Establish the facts quietly. Review existing logs without alerting the subject: file access and download logs, DLP and CASB events, email sent to personal addresses, endpoint USB and print logs, source code clone history, and SaaS export events.
| Exfiltration path | ATT&CK | Evidence source |
|---|---|---|
| Personal cloud storage upload | T1567.002 Exfiltration to Cloud Storage | Proxy, CASB, endpoint DLP |
| Other web services (webmail, file sharing, AI tools) | T1567 Exfiltration Over Web Service | Proxy, browser DLP, email gateway |
| USB or removable media | T1052.001 Exfiltration over USB | EDR device control, Windows device events |
| Bulk read from SharePoint, wikis, CRM or repositories | T1213 Data from Information Repositories | SaaS audit logs, Git server logs |
| Bulk read from cloud buckets | T1530 Data from Cloud Storage | CloudTrail data events, storage access logs |
| Auto-forwarding to a personal mailbox | T1114.003 Email Forwarding Rule | Mail audit log, transport rules |
3.4 Rate severity. High: regulated personal data, trade secrets, source code or credentials taken, or evidence of sale or extortion. Medium: confidential business data with no sign of onward disclosure. Low: policy breach with data still under [Organisation] control.
3.5 Decision (incident lead with legal and HR): close as benign (record reasons), proceed to an overt HR process, or proceed to a full investigation with evidence preservation. A full investigation is required for any High case.
4. Containment
4.1 Preserve evidence before you act. Placing a legal hold on mailbox and cloud storage, exporting relevant audit logs (many platforms keep them only for a fixed period) and imaging or seizing the corporate laptop all come before account changes. Record hashes, who collected what, when and how. See the Digital Forensics (DFIR) Guide.
4.2 Decision (incident lead, HR and legal): covert or overt. Covert containment (quietly restricting sharing, blocking uploads to personal cloud, watching for further movement) suits cases where the data is still on the device or where a law enforcement referral is likely. Overt containment (suspension and full access removal) suits cases where harm is continuing or the person is leaving within days.
4.3 Overt containment actions, timed to coincide with the HR meeting:
- Accounts: disable the directory account, revoke sessions and refresh tokens, and disable registered devices. In Entra ID that is Account enabled set to off, Revoke sessions, and disabling devices with Microsoft Graph. Existing access tokens can stay valid for about an hour unless the application supports continuous access evaluation.
- Non-human credentials the person controlled: personal access tokens, SSH keys, API keys, cloud access keys, OAuth apps they authorised and any service account whose password they knew. Rotate shared secrets, not only the person's own. See the Service Account Security Guide.
- Remote and physical access: VPN, building badges, privileged access vault checkouts and third-party portals.
- Devices: recover corporate devices; for mobile devices, use selective wipe of corporate data only after the image is taken.
4.4 Contain the data, not just the person. Remove external sharing links, revoke access to files shared to personal addresses, and ask the receiving platform or party to remove copies where legal advises.
5. Eradication
5.1 Confirm that no access path remains: search for accounts, tokens, keys, mailbox delegates, forwarding rules or scheduled jobs created by the person, and for shared credentials they knew. The Coupang breach shows the cost of a former engineer's signing key left unrevoked.
5.2 Determine the full data set taken: file names, record counts and data subjects. This feeds section 7.
5.3 Legal pursues recovery of copies: written undertakings, return or certified deletion, and where justified a court order. Security verifies any device or account the person surrenders.
5.4 Check for collusion: other users accessing the same data in the same window, shared external destinations, or the same third-party employer.
6. Recovery
6.1 Restore normal access for colleagues affected by containment, such as shared folders that were locked.
6.2 Reassign ownership of the person's data, mailboxes, service accounts and workflows. See the Employee Offboarding Security Guide.
6.3 Business owners act on the impact: change customer-facing processes if customer data was taken, and change commercial plans or pursue legal remedies if trade secrets were taken.
6.4 Lift covert monitoring formally and record the end date. Delete monitoring data that is not needed as evidence, in line with the retention schedule.
7. Communication and notification
| Audience | Owner | When |
|---|---|---|
| Executive sponsor | Incident lead | On declaration and at each decision point |
| Data protection regulator | DPO | Where personal data is affected and the breach is notifiable. Under UK GDPR and EU GDPR Article 33, within 72 hours of becoming aware |
| Affected individuals | DPO and legal | Where the breach is likely to result in high risk to them (GDPR Article 34), or as other laws require |
| Law enforcement | Legal | On decision by legal and the executive sponsor |
| Customers, partners or regulators by contract | Legal and account owners | As contracts and sector rules require |
| Staff | HR | Minimal, factual and without naming the individual |
7.1 Communications about the individual go through HR and legal only. Never discuss the case in open channels. Where a bribed insider exposed customer data, extortion may follow: the Coinbase insider breach moved from bribed support agents to a US$20 million extortion demand and regulatory filings.
8. Post-incident review
8.1 Within [10] working days of closure, hold a blameless review with the case team. Record: timeline from first indicator to detection to containment, what was taken, which controls worked and which did not.
8.2 Answer these questions:
- Did HR leaving dates reach the security tooling, and did heightened monitoring of leavers start?
- Did the person's access exceed their role? Feed findings into access reviews. See the Insider Threat and Identity Guide.
- Were audit logs available for the full period, or had retention expired?
- Was the privacy check completed before targeted review began?
8.3 Track: time to detect, time to contain, percentage of leavers whose access was removed on the leaving date, and number of DLP or insider risk alerts converted to cases.
Implementation guidance
- Connect HR to security first. Resignation and termination dates are the strongest trigger. Microsoft Purview Insider Risk Management, for example, ships a "Data theft by departing users" policy template triggered by an HR connector date or by account deletion in Entra ID, scoring downloads, printing and copying to personal cloud near the end date.
- Write the privacy approach once. Complete a DPIA for insider monitoring, document the lawful basis and tell staff what is monitored. Keep covert monitoring as an exception with named approvers.
- Size by organisation. A small organisation may have one person covering security and IT: use external forensic and legal support on retainer and keep the case team to three people. A large organisation should run a standing insider risk team with a separate investigator role, so analysts never investigate people they work with.
- Pre-stage evidence collection: retention periods for audit logs that exceed your typical detection delay, legal hold procedures and a forensic imaging kit.
- Include non-human credentials in offboarding. Every token, key and service account a person owns should be listed against their identity so it can be revoked with them.
| Playbook section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Programme and triggers | DE.CM-03 | PM-12 | A.6.4 |
| 3. Detection and triage | RS.AN-03 | AU-6, IR-4 | A.5.25 |
| 4. Containment and evidence | RS.MA-01, RS.AN-06 | IR-4, AC-2(3), PS-4 | A.5.26, A.5.28 |
| 6. Recovery | RC.RP-01 | IR-4 | A.5.26 |
| 7. Communication | RS.CO-02 | IR-6 | A.5.26 |
| 8. Review | RS.AN-03 | IR-4 | A.5.27 |
References: CISA: Insider Threat Mitigation · ICO: Data protection and monitoring workers · NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management · Microsoft: Revoke user access in an emergency in Microsoft Entra ID · Microsoft: Insider Risk Management policy templates
This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Insider Data Theft Guide · Insider Threat Programme Guide · Data Loss Prevention (DLP) Guide · Employee Monitoring and Privacy Guide · Incident Response Guide