Insider Risk vs Insider Threat: Programme Scope, Privacy and Detection

Most insider programmes are still built to catch a person, when most of the harm they need to prevent comes from access, process and mistakes that never involve a person with bad intent. Insider threat and insider risk are often used as synonyms, but they describe different scopes, different operating models and different privacy footprints. The UK National Protective Security Authority (NPSA) separated the terms formally in May 2023, and the US Cybersecurity and Infrastructure Security Agency (CISA) now defines insiders by access rather than by malice. This guide compares the two framings as programme designs: what each one watches, who owns it, how it handles HR, legal and privacy limits, and how both apply to insiders who misuse service accounts, keys and other non-human identities. It is written for CISOs, insider programme leads, HR and legal partners, and privacy officers deciding how to scope or reshape a programme.

Key takeaways

• Threat is a subset of risk. NPSA defines insider risk as the likelihood and impact of harm from the action or inaction of an insider, and an insider threat as an insider who intends to or is likely to cause harm; a programme scoped only to threats ignores negligence and process gaps.
• The operating models differ. A threat programme is investigation-led and case-centred; a risk programme is posture-led and control-centred, measuring exposure across roles, access and processes before any individual is a suspect.
• Privacy limits shape both, but differently. Under UK GDPR the ICO requires a clear purpose, the least intrusive means and, for high-risk monitoring, a DPIA before processing starts; a risk posture approach can meet many goals with aggregate, role-level data instead of individual surveillance.
• HR and legal are co-owners, not escalation points. Joiner, mover and leaver processes, sanctions and investigations live outside security; programmes that treat HR as a final step miss the earliest and cheapest controls.
• Insiders increasingly act through machine credentials. Signing keys, API keys and shared service accounts let a current or former insider act without their own identity in the logs, so both framings must cover non-human identities.

The short answer

Run an insider risk programme, with an insider threat capability inside it. Insider risk is the broader discipline: it manages the likelihood and impact of harm from anyone with authorised access or knowledge, whether that harm comes from malice, negligence, coercion or plain error. Insider threat management is the narrower function that handles specific individuals or groups judged likely to cause harm: triage, investigation, threat assessment and case closure.

For the full build of the investigative function, see the Insider Threat Programme Guide. This page is about choosing and combining the two scopes.

Definitions from the primary sources

The vocabulary shift is recent and deliberate. NPSA (formerly CPNI) previously defined an insider as a person who exploits, or intends to exploit, legitimate access for unauthorised purposes. In May 2023 it replaced that single definition with four terms, explaining that harm also comes from people with legitimate access who make mistakes, and that the old wording led practitioners to use "risk" and "threat" interchangeably.

CISA's definition takes a similar access-based view: an insider is anyone who has or had authorised access to or knowledge of an organisation's resources, and insider threat is the potential for an insider to use that access to harm the organisation, through malicious, complacent or unintentional acts. CISA groups insiders into unintentional (negligent and accidental), intentional, collusive and third-party categories. The behavioural detail of those categories is covered in Malicious vs Negligent vs Compromised Insider.

Side-by-side comparison

Insider threat framing: threat model, architecture and limits

Threat model. The adversary is a person: a disgruntled employee, a departing engineer taking intellectual property, a staff member bribed or recruited by an external group, or a contractor acting for a third party. CISA lists violence, terrorism, espionage, sabotage, theft and cyber as the expressions of insider threat, and the CERT Division of the Software Engineering Institute describes the problem as misuse of authorised access to critical assets in its Common Sense Guide to Mitigating Insider Threats (seventh edition, 22 best practices).

Architecture in words. Signals from user activity monitoring, data loss prevention, identity logs, physical access and HR events flow into an analytics layer that scores individuals. An analyst triages alerts, a multidisciplinary hub (security, HR, legal, and often employee relations) decides whether to open a case, and the case moves through investigation, threat assessment and an outcome. CISA's Insider Threat Mitigation Guide frames this as define, detect and identify, assess, and manage.

Where it works. Environments with high-value secrets, regulated duty to detect (defence contractors, national security supply chains, critical infrastructure), and a history of deliberate theft or sabotage.

Where it fails.

• Accidents dominate volume: misdirected email, oversharing in collaboration tools and pasting data into public AI tools are not threats in the NPSA sense, but they cause much of the loss. The Samsung ChatGPT source code leak is an example of harm with no hostile intent.
• Monitoring is hard to justify: individual scoring of the whole workforce, including keystroke-level capture, is exactly the kind of processing the ICO lists as high risk.
• Legitimate access hides abuse: in the Coinbase insider breach bribed support staff used access they already held for their jobs, so the controls that mattered were record-level access scoping and bulk-access monitoring, which are posture controls.

Insider risk framing: threat model, architecture and limits

Threat model. The hazard is the combination of access, opportunity and process weakness, regardless of intent. A leaver with an unrevoked key, a support role that can query every customer record, a shared admin account with no owner, a privileged engineer with no change approval: each is an insider risk before anyone decides to misuse it.

Architecture in words. The programme starts from critical assets and the roles that can reach them. It combines entitlement data from identity governance, data classification and flow mapping, joiner-mover-leaver timeliness, segregation of duties rules and control test results into a risk register for insider exposure. Individual-level data is used only after a documented escalation threshold is met, at which point the case moves into the threat capability.

Where it works. Most commercial organisations, regulated firms with strong employee privacy expectations (UK, EU, works council jurisdictions), and any environment where accidental loss and third-party access outweigh deliberate theft.

Where it fails.

• No teeth: without a defined path to investigation, a risk programme sees a live exfiltration attempt as a metric.
• Blind spots in machine access: risk programmes that review only human accounts miss the keys and service accounts insiders actually reuse, as the Coupang signing key breach showed when a former engineer used a token signing key kept after leaving to forge access tokens.

Maturity across the risk framing is staged in the Insider Risk Maturity Model.

HR, legal and privacy: where the two framings diverge most

The practical difference between the framings shows up in how much personal data they process and who signs off. Using the ICO's employment monitoring guidance for UK GDPR as a reference point:

The ICO notes this guidance is under review following the Data (Use and Access) Act, so confirm the current version before relying on it. In the EU, check the national employment rules made under GDPR Article 88 and any works council co-determination rights before deploying monitoring. In the US, government programmes work under the National Insider Threat Policy and the NITTF minimum standards, which the NITTF Insider Threat Program Maturity Framework builds beyond.

HR integration points that a risk programme owns:

• Pre-employment: screening proportionate to role (NIST SP 800-53 PS-3, ISO/IEC 27001:2022 A.6.1).
• Movers: access recertified on transfer (PS-5), with old entitlements removed, not accumulated.
• Leavers: access revoked on or before the last day, including credentials the person created or knows (PS-4). See the Employee Offboarding Security Checklist.
• Sanctions: a formal, consistent process for policy breaches (PS-8, A.6.4), owned by HR, with security providing evidence.
• Wellbeing and grievance signals: handled by HR under its own lawful basis, shared with the insider function only through an agreed threshold, never as a raw feed.

Insiders and non-human identities

Insiders are among the people best placed to misuse machine credentials, because they created them, know where they are stored, or inherited them from a shared team account. Activity performed with a service account or API key carries no personal name, so threat-led analytics that score individuals often miss it entirely. ATT&CK tracks the use of legitimate credentials as T1078 Valid Accounts, and exfiltration to cloud services as T1567 Exfiltration Over Web Service; both apply whether the actor is external or internal.

The Ledger Connect Kit npm compromise involved a former employee's npm access that had not been revoked. For identity-centred insider controls more broadly, see the Insider Threat and Identity Guide.

Decision guidance: which scope to lead with

• Lead with insider risk if most of your loss events are accidental, if you operate under GDPR or similar employee privacy rules, if staff trust is fragile, or if you have no investigations capability yet. Build the threat capability as a gated escalation path.
• Lead with insider threat if you hold classified or export-controlled information, are contractually required to run an insider threat programme, or have suffered deliberate theft or sabotage and need a case process now. Add the risk layer within a year so detection is not your only control.
• Small organisations (under about 500 staff): one risk owner, joiner-mover-leaver discipline, privileged and NHI access reviews, and a written escalation route to HR and legal. A dedicated hub is usually unnecessary.
• Large or regulated organisations: a risk programme under the CISO or CRO, a small insider threat hub with HR, legal and privacy represented, and a data protection officer sign-off on every new data source.

Buyers evaluating tooling for either model can use the Insider Risk Management Buyer's Guide.

How to move from a threat-led to a risk-led programme

1. Rewrite the charter. Adopt access-based definitions (NPSA or CISA), state that the programme covers unintentional and third-party insiders, and name HR, legal and privacy as co-owners.
2. Inventory current data sources. For each monitoring feed, record purpose, lawful basis, DPIA status and whether it is individual or aggregate. Retire feeds with no documented purpose.
3. Map critical assets to roles and machine identities. Identify which human roles and which service accounts, keys and agents can reach each crown-jewel data set.
4. Build the posture baseline. Measure excess entitlements, orphaned and ownerless accounts, leaver access closure time and NHIs without owners. These become the first risk register entries.
5. Define escalation thresholds. Document what moves an exposure or event from aggregate analysis to an individual case, who approves it, and how the decision is logged. Pilot with one business unit and review every escalation with legal for the first quarter.
6. Update transparency material. Refresh the worker privacy notice and acceptable use policy to describe posture analytics and the escalation process in plain language.
7. Keep a rollback. Retain the existing case process unchanged until the new thresholds have run for at least one review cycle, so live investigations are not disrupted.

Worked scenario: a payments firm resets its programme

A 3,000-person UK payments company runs a threat-led programme: user activity monitoring on every laptop, risk scores per employee, and a three-person investigations team. In a year it opens 40 cases and substantiates four. A DPIA review finds keystroke capture with no documented need, and the works forum objects to the scoring.

The firm keeps its case team but rescopes the programme. It removes keystroke capture, limits content inspection to payment card and customer data types, and moves anomaly scoring to role-level baselines. It maps which roles and service accounts can export customer records, finds that 60 support agents can query any account, and that two shared database service accounts are known by eleven engineers. Record access is limited to assigned cases, the shared accounts are vaulted and rotated, and leaver workflows now revoke personal access tokens and trigger key rotation for owning teams. Individual investigation now requires a documented threshold, such as a bulk export plus a resignation notice, and approval from legal.

Detection and measurement

What to log: access to classified data stores, bulk queries and exports, privileged sessions, service account interactive logons, token and key use against creator HR status, publishing actions in CI and package registries, and every escalation decision with approver.

Metrics that show the risk programme is working:

• Leaver access closure: percentage of leavers with all human and owned non-human credentials revoked within 24 hours of the end date.
• Ownerless NHIs: count of service accounts, keys and tokens with no named human owner, trending to zero.
• Excess entitlement removal: entitlements removed per review cycle as a share of entitlements reviewed.
• Escalation quality: share of individual cases opened that are substantiated, and share with documented legal approval (target 100 percent).
• Monitoring footprint: number of individual-level data sources with a current DPIA, against the total in use.
• Time to contain: hours from a confirmed insider event to access removal.

Framework mapping

Common failure patterns

• Renaming without rescoping: the threat team is renamed "insider risk" but still only scores individuals and investigates alerts.
• HR as the last step: HR hears about a case only at the sanction stage, so mover and leaver signals never reach the programme.
• Monitoring without a DPIA: tools are deployed in default configuration with full content capture, creating legal exposure larger than the risk they address.
• Human-only leaver process: the person's account is disabled but keys, tokens and shared passwords they hold stay valid, as in the Coupang and Ledger cases above.
• No defined escalation threshold: analysts open individual cases on judgement alone, which is inconsistent and difficult to defend.

Practitioner checklist

• Adopt access-based definitions of insider, insider risk and insider threat in the programme charter.
• Name HR, legal and privacy as co-owners with documented roles.
• Record purpose, lawful basis and DPIA status for every monitoring data source.
• Map crown-jewel data to the human roles and non-human identities that can reach it.
• Assign a named owner to every service account, key and token, and tie revocation to the leaver workflow.
• Write and approve escalation thresholds from aggregate analysis to individual case.
• Bring contractors and outsourced support into access scoping and review.
• Publish a plain-language worker notice covering monitoring and escalation.
• Report the posture metrics above to the risk committee quarterly.

Standards and references

• NPSA: NPSA changes insider risk definitions
• CISA: Defining Insider Threats
• CISA: Insider Threat Mitigation Guide
• ICO: Data protection and monitoring workers
• CMU SEI: Common Sense Guide to Mitigating Insider Threats, Seventh Edition
• ODNI NCSC: Insider Threat Program Maturity Framework
• NIST: SP 800-53 Rev 5, Security and Privacy Controls
• MITRE ATT&CK: T1078 Valid Accounts

Related NHI Mgmt Group resources: Insider Threat Programme Guide, Insider Risk Maturity Model, Insider Risk Management Buyer's Guide, Insider Risk Executive Briefing, Insider Threat and Identity Guide.