CyphrQ

Insider Threat Program: Types, Warning Signs and Privacy Limits

How to build an insider threat program: CISA's insider types, warning signs, least privilege, logging and DLP, HR and legal roles, and lawful monitoring.

What is an insider threat program? It is the set of people, policies and controls an organisation uses to prevent, spot and handle harm caused by someone who already has legitimate access: an employee, contractor or supplier. A good one combines least-privilege access, logging and data loss controls with HR and legal processes, and it monitors staff only as far as privacy law allows.

An insider doesn't need to break in. They already have a login. That makes insider risk a different problem from keeping attackers out, and it is why security can't run the programme alone.

What counts as an insider threat, according to CISA?

The US Cybersecurity and Infrastructure Security Agency (CISA) defines an insider as "any person who has or had authorized access to or knowledge of an organization's resources". Insider threat is "the threat that an insider will use their authorized access, wittingly or unwittingly, to do harm" (CISA). Note the "had": former staff count.

CISA sorts insider threats into these types:

Type (CISA) CISA's description Everyday example
Unintentional: negligence Exposes the organisation "through carelessness" Ignoring a policy and emailing a customer file to a personal address to work from home
Unintentional: accidental "Mistakenly causes an unintended risk" Attaching the wrong spreadsheet to an email
Intentional (malicious) Acts "to harm an organization for personal benefit or to act on a personal grievance" Copying customer data to sell
Collusive Insiders "collaborate with an external threat actor" A support agent paid by a criminal group to pull records
Third-party "Contractors or vendors who are not formal members of an organization" An outsourced help desk with access to your systems

Many teams add a sixth case that CISA's list doesn't name separately: the compromised insider, whose account is being used by an outside attacker. The person is innocent; the login isn't. How infostealers steal session tokens explains one common route. The controls overlap heavily, because from your logs a stolen account and a misbehaving employee can look the same.

What do real insider cases look like?

UK, 2024: RAC call-centre staff (malicious). The UK Information Commissioner's Office (ICO) reports that two customer service staff at the RAC's Stretford call centre copied and sold more than 29,500 lines of personal data about people involved in road traffic accidents. The RAC's newly installed security monitoring software showed one of them accessing and copying the information, and the RAC reported it to the ICO. At a hearing at Minshull Street Crown Court on 8 October 2024, both were sentenced to six months in prison, suspended for 18 months, plus 150 hours of unpaid work, after pleading guilty to offences under the Computer Misuse Act 1990 and the Data Protection Act 2018. The ICO published the news the next day, 9 October 2024 (ICO).

US, 2025: Coinbase support roles (collusive and third-party). In a Form 8-K filed on 15 May 2025, Coinbase said a threat actor demanding money "appears to have obtained this information by paying multiple contractors or employees working in support roles outside the United States". Its security monitoring had detected staff accessing data without a business need "in the previous months", and the company had terminated them. Coinbase preliminarily estimated "approximately $180 million to $400 million relating to remediation costs and voluntary customer reimbursements", and said it had not paid the demand (SEC filing).

Both cases share the detail that matters for your programme: the people involved were using access they had been given, and monitoring caught the misuse. In the Coinbase case, detection and dismissal still didn't stop the data being used for extortion.

Which warning signs should an insider threat program watch for?

Warning signs are prompts to look closer, never proof. The most useful ones are about activity, not personality:

  • Access without a business need. Records looked up that don't match the person's role or open tickets. This was the signal in both cases above.
  • Unusual volume. Bulk exports, mass downloads or printing far above the person's normal pattern.
  • New ways out. First-time use of USB storage, personal cloud accounts or personal email for work files.
  • Timing. Spikes in data access after a resignation, a disciplinary process or a rejected promotion. HR knows about these events; security usually doesn't, which is why the two need a lawful way to talk.
  • Control evasion. Attempts to disable endpoint agents, clear logs, or rename and compress files before sending them.

Avoid building a programme around profiling people by background or nationality. It is unfair, it creates legal risk, and it doesn't find the negligent insider, who is usually just in a hurry.

What are the building blocks of an insider threat program?

CISA's Insider Threat Mitigation Guide is organised around types of insider threat, detection strategies, assessment guidelines, threat management and a mitigation programme. CISA also publishes a companion resource, "Assembling A Multi-Disciplinary Insider Threat Management Team" (dated 28 January 2026 on the same page).

In practice, the building blocks are:

  1. A sponsor and a charter. A senior owner, a written purpose and clear limits on what the programme may and may not do.
  2. A cross-functional team. Security, IT, HR, legal, privacy (your data protection officer, if you have one) and, case by case, the person's line manager.
  3. Policies people have read. Acceptable use, data handling, monitoring notice and leaver procedures.
  4. A reporting channel. A confidential way for staff to raise concerns, with protection for people who report in good faith.
  5. A case process. Who triages an alert, who decides to escalate, how evidence is preserved, and when HR or police get involved.
  6. Training. In my view, the unintentional types in CISA's list are mainly a training and process problem, not a surveillance one.

Which technical controls limit insider damage?

The controls that matter most limit what any one person can reach and record what they do:

  • Least privilege and separation of duties. NIST's Cybersecurity Framework 2.0 outcome PR.AA-05 reads: "Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties" (NIST CSF 2.0).
  • Activity logging. CSF 2.0 outcome DE.CM-03: "Personnel activity and technology usage are monitored to find potentially adverse events".
  • Data loss prevention (DLP). Tools that spot and block sensitive data leaving through email, USB, web uploads or cloud sharing. DLP only works once data is labelled; see data classification and DLP.
  • Privileged access management. Admin rights issued for a task, time-limited and recorded.
  • Leaver process. Same-day removal of accounts, tokens and remote access when someone leaves, plus a check of their recent data activity.
  • Supplier access. Third-party accounts held to the same rules, which third-party risk management covers in depth.

How far can you monitor employees under UK GDPR and India's DPDP Act?

Monitoring is lawful only within limits, and the limits are concrete.

UK. The ICO's guidance on monitoring workers says:

  • You need a lawful basis, and "must be clear about your purpose and select the least intrusive means to achieve it."
  • "You must carry out a DPIA before undertaking any processing likely to cause high risk"; a DPIA is a data protection impact assessment. The guidance lists "keystroke monitoring of workers" among its examples of high-risk processing.
  • Apart from very exceptional cases of justified covert monitoring, "you must inform workers about any monitoring".
  • Covert monitoring is for "exceptional circumstances", such as preventing or detecting "suspected criminal activity or gross misconduct", and "should only be authorised by senior management."
  • Homeworking is covered, and you "must not keep personal information obtained from monitoring workers for any longer than is necessary".

The ICO's page carries a banner saying the guidance is under review after the Data (Use and Access) Act, so check it before you finalise a policy. EU employers start from the same GDPR principles and should check national employment rules with counsel.

India. The Digital Personal Data Protection Act, 2023 lists employment purposes among its "legitimate uses" in section 7, as our DPDP guide notes. This post doesn't quote the clause, because the Act's official text could not be checked; take legal advice on how far it extends to security monitoring, and remember the Act's other duties, such as security safeguards, still apply.

The practical rule: tell people what you monitor and why, monitor activity on work systems rather than private lives, and keep the data no longer than the purpose needs.

Going deeper: for security and IT teams

This section is for security engineers and SOC leads who would build detection for an insider programme.

Threat model. Insiders already hold valid credentials, so perimeter controls don't apply. What they need is reach (data their role exposes), a way out (an exfiltration channel) and time without anyone noticing. What they get depends on how much your access model over-provisions. Reduce reach first: role-based access reviewed against PR.AA-05, and query-level limits on bulk exports from CRM and support tools.

Exfiltration techniques to cover. MITRE ATT&CK lists T1052 Exfiltration Over Physical Medium (sub-technique T1052.001, over USB), with mitigations M1057 Data Loss Prevention, M1042 Disable or Remove Feature or Program and M1034 Limit Hardware Installation. Web channels sit under T1567 Exfiltration Over Web Service, including T1567.002 Exfiltration to Cloud Storage. Map each to a log source you actually collect.

Log sources, in priority order.

  1. Identity provider sign-ins and privilege changes.
  2. Application audit logs for record views and exports in CRM, support and HR systems. This is where both the RAC and Coinbase patterns would surface, so confirm your SIEM actually receives it.
  3. Endpoint telemetry: removable media mounts, archive creation, cloud sync clients.
  4. Email and web gateway logs for uploads to personal storage.
  5. HR feeds: leaver dates, role changes and notice periods, shared under a documented purpose.

Detection logic. Per-user baselines beat static thresholds. Alert on record views outside assigned queues, export volumes several times a user's norm, first-time removable media use, and any combination of these inside a notice period. Route alerts to a small, named triage group, not the whole SOC, so that employee data stays on a need-to-know basis.

Privacy engineering. Pseudonymise analyst views until a case is opened, log every analyst query against monitoring data, and set retention for insider telemetry in writing. These choices make the ICO's least-intrusive-means and retention tests easier to show in a DPIA.

Testing. Run a purple-team style exercise with HR and legal present: a simulated leaver bulk-exports dummy records. Measure time to alert, time to triage and whether the evidence would stand up. Red, blue and purple teaming covers how to scope one.

Questions to ask your team:

  • Which business applications log record-level views, and are those logs in our SIEM?
  • How fast are accounts removed after a resignation, measured over the last ten leavers?
  • Has a DPIA been done for our endpoint and DLP monitoring?
  • Who can see an insider alert, and who decides to escalate it to HR?

An insider threat program checklist for the first 90 days

  1. Name a senior sponsor and write a one-page charter with limits.
  2. Form the team: security, IT, HR, legal and privacy.
  3. Complete a DPIA for any monitoring, and update the staff monitoring notice.
  4. Review access for the five systems with the most sensitive data; remove what roles don't need.
  5. Turn on record-view and export logging in those systems, and send it to your SIEM.
  6. Fix the leaver process so access ends the same day.
  7. Set up a confidential reporting channel.
  8. Run one tabletop exercise on a leaver who takes customer data.

Key takeaways

  • CISA's insider types run from careless and accidental to malicious, collusive and third-party; plan for compromised accounts too.
  • The RAC and Coinbase cases were both caught by monitoring of access without a business need.
  • Least privilege, application-level logging, DLP and a fast leaver process do most of the technical work.
  • HR and legal are part of the programme, not observers.
  • In the UK, monitoring needs a clear purpose, the least intrusive means, transparency and usually a DPIA; covert monitoring is for exceptional cases.

Sources