Insider Threat Programme Guide: Detection, DLP and HR Process

Most organisations own the tools to spot insider activity, but few have the programme that turns an alert or an HR concern into a fair, lawful and timely decision. Insider incidents sit between functions: security sees the data movement, HR knows about the grievance or the resignation, legal decides what can be collected and used, and line managers notice the change in behaviour. This guide covers how to build and run an insider threat programme: governance, the hub or working group, the roles of HR, legal, privacy and security, indicators, user activity monitoring and data loss prevention (DLP) in a programme context, case handling and measurement. It is written for security leaders, insider risk analysts, HR partners and the counsel who advise them. The identity controls that limit what an insider can reach are covered separately in the Insider Threat and Identity Guide.

Key takeaways

• A programme is a governance structure, not a product. NIST SP 800-53 PM-12 requires an insider threat programme "that includes a cross-discipline insider threat incident handling team", led by a designated senior official.
• Most insider incidents are not malicious. CISA's taxonomy separates negligent and accidental insiders from intentional, collusive and third-party insiders, and each needs different controls and a different tone of response.
• The hub joins technical and human signals. DLP and user activity monitoring alerts mean little until they are read alongside HR, access and physical security context by a small, vetted team working on a need-to-know basis.
• Legal and privacy sign-off comes first. Monitoring workers engages data protection and employment law; in the UK the ICO expects a DPIA before high-risk monitoring and transparency with staff in all but exceptional cases.
• Measure outcomes, not alert volume. Track time to triage, the share of cases resolved without discipline, leaver data movement and coverage of critical assets, and report them to leadership at least annually.

What an insider threat programme covers

CISA defines an insider as "any person who has or had authorized access to or knowledge of an organization's resources" and insider threat as "the threat that an insider will use their authorized access, intentionally or unintentionally, to do harm". The UK National Protective Security Authority (NPSA) revised its definitions in May 2023 along the same lines and now talks about insider risk: "The likelihood of harm or loss to an organisation, and its subsequent impact, because of the action or inaction" of an insider. Note "inaction": a programme that only hunts malicious employees misses most of its caseload.

CISA also lists the forms harm takes: violence, espionage, sabotage, theft and cyber. If the charter covers only data theft, say so, so that workplace violence concerns still have an owner (often corporate security). The Samsung ChatGPT source code leak is a reminder that the largest category is well-meaning staff using an unapproved tool. See the Shadow AI Discovery Guide.

Governance and roles

The US federal model is the most developed public reference. Executive Order 13587 (October 2011) created the National Insider Threat Task Force (NITTF), the National Insider Threat Policy and Minimum Standards followed in November 2012, and in 2018 the NITTF published an Insider Threat Program Maturity Framework with 19 maturity elements (ME1 to ME19). Private organisations are not bound by these, but the structure translates well.

• Senior official: one named executive accountable for the programme, positioned with "access to leadership" (ME1), often the CISO or chief security officer with a deputy from HR.
• Charter: scope, authorities, what data the hub may receive, who may open a case and how decisions are reviewed. The CERT Common Sense Guide recommends "directives, authorities, a mission statement".
• Insider threat policy: a short published policy telling staff what is monitored, why, and how to raise concerns.
• Oversight: a panel (counsel, privacy, HR, an independent senior manager) reviewing case statistics, monitoring scope changes and complaints, plus what CERT calls "annual self-assessments and external entity assessments".
• Watch the watcher: analysts with access to monitoring data are privileged insiders too. ME13 asks programmes to monitor and independently audit programme personnel.

PM-12's discussion explains that some insider incidents are preceded by non-technical workplace behaviour, such as conflict with colleagues, which is why HR records matter, and warns in the same passage that their use "could raise significant concerns for privacy". Agreed roles and boundaries make that tension workable.

The CERT guide is direct: "The organization must involve legal counsel before implementing any IRMP and during any inquiry." Its best practice 21 (positive incentives) says organisations should "entice workforce behavior rather than coerce it", so the programme should also feed employee assistance and grievance processes, not only sanctions.

The insider threat hub or working group

"Hub" is the NITTF term (it runs an Insider Threat Hub Operations Course) for the function that receives, integrates and analyses information from across the organisation. PM-12 describes the same function as centralised integration and analysis of technical and non-technical information.

Choosing an operating model

• Working group (small and mid-sized organisations): a monthly or on-demand meeting of a security lead, an HR partner and counsel, supported by existing SOC tooling. Low cost, but slow and dependent on individuals.
• Dedicated hub (large or regulated organisations): full-time analysts with UAM or insider risk tooling, a case management system and documented feeds from HR, IAM and physical security. NITTF ME8 and ME9 ask for "automated or scheduled processes" and notification "with predictable frequency" of relevant information.
• Hybrid: the SOC handles technical triage and passes a filtered set of cases to a weekly hub meeting. A common path for organisations with an existing SOC. See the SIEM Guide.

Information feeds to agree

• HR: resignations and notice dates, terminations, role changes, active disciplinary or grievance cases (as flags, not narratives).
• Identity: new privileged grants, dormant account use, access outside role. See the Privileged Access Management Guide.
• Data security: DLP incidents, sensitivity label downgrades, bulk downloads.
• Reports from people: a confidential channel for managers and colleagues. CISA notes that "An organization's own personnel are an invaluable resource to observe behaviors of concern."

Indicators: technical, behavioural and organisational

No indicator proves intent. CISA observes that most stressful events do not lead to harmful acts, and that malicious insider acts are usually deliberate rather than spontaneous, so planning activity is often visible. Combine weak signals; do not act on any single one.

NITTF ME15 and ME16 describe behavioural science methods and "risk scoring capability based on behavioral and workplace factors". Insider risk tools often implement this as a per-user score. Use scores to prioritise analyst time, document what drives them, and never open a formal investigation on a score alone. See the Detection Engineering Guide for how to test and tune these analytics.

User activity monitoring and DLP in the programme

User activity monitoring (UAM) records what a user does on an endpoint or in applications, often including screenshots or keystrokes, and is far more intrusive than DLP, which inspects data movement against policy. NITTF ME11 calls for UAM "on all USG endpoints/devices" in federal agencies; that baseline does not transfer to most private employers.

• Start with what you have: DLP incidents, IdP sign-ins, cloud and SaaS audit logs and EDR telemetry answer most insider questions without screen capture. CERT best practice 12 frames the goal as monitoring workforce actions and "Correlating Information from Multiple Data Sources".
• Scope intrusive UAM tightly: enable screenshot or keystroke capture only for named high-risk roles (administrators of critical systems, staff in a defined notice period) or for an approved open case, with legal sign-off and a defined end date.
• Tune DLP for the hub, not for volume: route policy-tip overrides and blocked actions to coaching, and send only high-severity patterns (bulk sensitive files to personal destinations, label removal followed by upload) to the hub queue.
• DLP incident response: agree in advance which DLP severities go to the SOC, which to the data owner and which to the hub, and the timeline for each. CERT says the response plan should explain "how alerts and anomalies are identified, managed, and escalated, including timelines for every action".
• Protect the monitoring data: named analysts only, every view logged, short retention for data not linked to a case.

Legal caution: employee monitoring is subject to data protection and employment law (for example UK GDPR and the GDPR), which differ by country. The ICO's monitoring workers guidance expects a DPIA before high-risk monitoring such as keystroke logging, telling workers about monitoring except in very exceptional cases, and senior management authorisation for covert monitoring. This is not legal advice; take advice in each jurisdiction, and consult works councils where required. See the DPIA Guide: Running a Data Protection Impact Assessment.

Handling a case from alert to closure

1. Intake: log every alert or report in the case management system with source, time and reporter, and acknowledge the reporter. NITTF ME18 asks for "case management tools to ensure the integrity and effectiveness of the insider threat inquiry".
2. Triage (target: one working day): an analyst checks for benign explanations (sanctioned destination, approved exception, known project). Most alerts close here, with the reason recorded.
3. Hub review: where triage cannot explain the activity, the hub adds HR and access context. Decide on one of four outcomes: close, coach or remediate, monitor for a defined period under an approved scope, or open a formal inquiry.
4. Inquiry: counsel approves scope; analysts preserve evidence (forensic images, log exports with hashes, chain of custody) before any interview or access change that could alert the subject. See the Digital Forensics (DFIR) Guide.
5. Containment: time access suspension, device recovery and the HR conversation to happen together. NIST SP 800-53 AC-2(13) covers disabling accounts of high-risk individuals.
6. Decision and referral: HR leads disciplinary outcomes; counsel decides on civil action, regulator notification (for example a personal data breach) or law enforcement referral.
7. Closure and lessons: record the outcome, the control gap, and the fix. CERT best practice 22 is "Learn From Past Insider Threat Incidents".

Keep case files separate from personnel files, limit them to need-to-know, and apply a retention period agreed with privacy. The Coinbase insider breach, where outsourced support agents were bribed to copy customer data, shows why the response plan must reach beyond HR when insiders are collusive or employed by a supplier.

Personnel security: hiring, movers and leavers

Personnel security is the part of the programme HR owns day to day. NPSA guidance covers employment screening, ongoing personnel security, and monitoring and assessment, and NPSA publishes a personnel security maturity model for self-assessment.

• Pre-employment screening: identity, right to work, employment history and, for defined roles, criminal record or credit checks, proportionate to the role and lawful in the jurisdiction (NIST PS-3 Personnel Screening, ISO/IEC 27001:2022 A.6.1).
• Role-based risk: identify roles with access to critical assets and apply enhanced controls to them, rather than enhanced monitoring of everyone. CERT best practice 1 is "Know and Protect Your Critical Assets".
• Movers: remove old access when someone changes role (PS-5). Access kept from previous roles widens what an insider can take. See the Joiner-Mover-Leaver Guide.
• Leavers: CERT says "HR must notify members of the IT team so they can perform enhanced monitoring on the exiting individual", and its intellectual property theft example reviews "logs of activity for 30 days before and after the insider resigned". Build a standard leaver review (the "flight risk" window) covering downloads, uploads, email forwarding and print.
• Non-human credentials at exit: revoke API keys, signing keys and tokens the leaver created or knew, not only their user account. The Coupang breach involved a former engineer's signing key that was not revoked. See the Insider Threat and Identity Guide.

Building the programme in phases

1. Mandate (months 0 to 2): appoint the senior official, agree the charter with HR, legal and privacy, and identify critical assets and high-risk roles.
2. Legal groundwork (months 1 to 3): complete the DPIA, update privacy notices and policies, and publish the insider threat policy to staff.
3. Feeds and tooling (months 2 to 5): connect HR leaver and mover feeds, DLP, IdP and SaaS audit logs to the SIEM or insider risk tool. Run all new analytics in audit or monitor-only mode, with no user notification and no blocking.
4. Pilot (months 4 to 6): run the hub process on one business unit or on leavers only. Measure false positives, triage time and analyst workload, and run a tabletop exercise of the case workflow (NITTF ME19 calls for "routine exercises").
5. Expand in rings: extend to further business units and to high-risk roles, switching selected DLP rules from monitor to policy tip, and only then to block.
6. Roll back cleanly: keep each analytic and DLP rule versioned, with an owner, so that a rule causing business disruption or a disproportionate privacy impact can be returned to audit mode or disabled the same day. Record the reason.
7. Review annually: report metrics, re-run the DPIA when monitoring scope changes, and commission an independent assessment.

Small organisations: a working group, native DLP and audit logs in existing productivity suites, and a documented leaver review deliver most of the value. Large organisations: justify a dedicated hub, case management tooling and behavioural analytics when case volume or regulatory exposure makes the working group too slow.

Measuring the programme

NITTF ME2 asks programmes to use "metrics to determine progress in achieving program objectives and to identify areas requiring improvement", and to make them part of the annual report to leadership. Useful measures:

• Critical asset coverage: percentage of identified critical assets whose access and data movement feed the hub.
• Time to triage: median hours from alert to triage decision, by severity.
• Triage closure rate with reason: share of alerts closed as benign, and the top closure reasons, which drive tuning.
• Outcome mix: cases closed by coaching, process fix, discipline and referral. A programme where almost every case ends in discipline is probably missing the negligent majority.
• Leaver review completion: percentage of leavers in high-risk roles with a completed review before their last day.
• Repeat incidents: users or teams with a second DLP incident within 90 days of coaching, which tests whether coaching works.

For training measures (NIST AT-2(2) insider threat training), see the Security Awareness and Human Risk Management Guide.

Framework mapping

Common failure patterns

• Buying a tool before writing a charter: UAM is deployed, alerts pile up, and nobody has authority to act on them or a lawful basis to use HR data alongside them.
• Treating every alert as malice: heavy-handed responses to negligent or accidental incidents reduce self-reporting and push staff towards workarounds. The Samsung ChatGPT case began with staff pasting code into a public AI tool; an approved alternative and coaching do more than a ban alone.
• Ignoring third parties: contractors and outsourced support staff often have broad access to customer data and fall outside HR feeds. The Coinbase breach involved bribed outsourced support agents.
• Leaver process stops at the user account: keys and tokens survive, as in the Coupang breach.
• No control over the watchers: analysts browse recordings without a case, or monitoring data is retained indefinitely, creating a privacy breach of its own.
• Evidence lost by acting too early: access is cut and the subject is interviewed before logs and devices are preserved.

Practitioner checklist

• Name a senior official and publish a charter covering scope, authorities, data sources and oversight.
• Agree written roles and data-sharing boundaries with HR, legal, privacy and physical security.
• Complete a DPIA and update staff notices before switching on any new monitoring.
• Identify critical assets and high-risk roles, and focus intrusive monitoring on them.
• Connect HR leaver and mover feeds to the hub, and run a standard 30-day leaver data review.
• Define DLP and analytics severity routing, with triage time targets per severity.
• Use a case management system with need-to-know access and logged views.
• Preserve evidence before access changes or interviews, under counsel's direction.
• Exercise the case workflow at least annually and report metrics to leadership.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls (PM-12 Insider Threat Program)
• CISA: Insider Threat Mitigation Guide
• CISA: Defining Insider Threats
• ODNI NCSC: Insider Threat Program Maturity Framework
• Carnegie Mellon SEI: Common Sense Guide to Mitigating Insider Threats, Seventh Edition
• NPSA: Changes to Insider Risk Definitions
• ICO: Employment practices and data protection, monitoring workers
• MITRE ATT&CK: T1567 Exfiltration Over Web Service

Related NHI Mgmt Group resources: Insider Threat and Identity Guide · Joiner-Mover-Leaver Guide · SIEM Guide · Incident Response Guide · Shadow AI Discovery Guide