The same alert, a large download to a personal cloud account, can mean a thief, a careless employee or an attacker using a stolen login, and treating one as another either lets harm continue or wrongs an innocent person. Insider incidents split into three types with different intent, different evidence and different responses: the malicious insider who chooses to cause harm, the negligent insider who causes harm through carelessness or error, and the compromised insider whose legitimate account is being driven by someone else. This guide compares them on intent and signals, how to tell them apart during triage, how investigation and HR or legal involvement differ, and which controls matter most for each. It is for SOC analysts, insider risk leads, HR and employment counsel, and security managers who must make the first call on an insider alert.
Key takeaways
- Rule out compromise first. A compromised account is the cheapest hypothesis to test and the most urgent, because an external attacker is active now. Check authentication, device and session evidence before assuming anything about the person.
- Intent is a conclusion, not a starting point. Activity logs show what happened; only investigation and the person's own account show why. Label the event, not the employee, until the facts are in.
- Negligence is the most common and the least investigated. Most insider exposure comes from people trying to get work done. Fix the process and the tooling, and keep disciplinary routes for repeated, informed disregard.
- HR and legal join at different points for each type. Early for suspected malice, rarely for compromise, and through a standard, proportionate route for negligence.
- Controls overlap but priorities differ. Phishing-resistant authentication defeats most compromise, guardrails and design defeat most negligence, and least privilege plus monitoring of high-risk roles limits malice.
Three types, defined
CISA defines an insider as any person who has or had authorised access to, or knowledge of, an organisation's resources, and insider threat as the threat that an insider will use that access, intentionally or unintentionally, to cause harm. CISA divides unintentional threats into negligent (the person knows the policy and ignores it, such as allowing tailgating) and accidental (a mistake, such as emailing a document to the wrong recipient), and describes intentional or malicious threats as deliberate harm for personal gain or to act on a grievance. CISA also names collusive threats, where insiders work with an external actor, and third-party threats from contractors and vendors with access.
The compromised insider is not a separate category in CISA's taxonomy, because the harmful actor is external. It belongs in insider triage anyway: the activity arrives through a trusted account, it looks like insider activity in the logs, and it is the most frequent explanation for anomalous behaviour by an otherwise trusted user. In ATT&CK terms it is T1078 Valid Accounts.
Programme design, governance and the insider threat hub are covered in the Insider Threat Programme Guide. This page focuses on telling the three apart and responding to each.
Side-by-side comparison
| Dimension | Malicious insider | Negligent insider | Compromised insider |
|---|---|---|---|
| Who acts | The account holder, deliberately | The account holder, without intent to harm | An external actor using the account holder's identity |
| Motive | Financial gain, grievance, ideology, coercion or recruitment by outsiders | Convenience, deadline pressure, unclear rules, poor tooling | Attacker's goal: data, money, ransomware staging, further access |
| Awareness | Knows the act is wrong; may conceal it | Often unaware of the risk; rarely conceals | Account holder usually unaware |
| Typical timing | Around resignation, a poor review, a dispute or a known financial pressure; outside normal hours | During normal work, linked to a task or deadline | Shortly after a phishing wave, MFA prompts or a new device registration; any hour |
| Concealment | Renaming files, archives with passwords, clearing history, using personal channels, staying under thresholds | None or minimal; activity is open and often explained when asked | Attacker hides from the user (mail rules, deleted notifications) more than from monitoring |
| Strongest evidence | Pattern over time, collection beyond role, links to a personal trigger event | A single event matching a work task; same pattern across peers | Authentication anomalies: new device, location, impossible travel, token replay, MFA fatigue |
| Primary response owner | Insider risk team with HR and legal | Line manager and security awareness, HR only for repeated cases | SOC and incident response |
| Urgency | High, but covert containment may be needed to preserve evidence | Usually low; fix exposure quickly | Immediate: contain the session and credentials |
Signals that separate the three
CISA notes that detection combines human and technical elements, and that colleagues are a key source for noticing concerning behaviour. It also notes that most people under stress do not turn to harmful acts, and that when insiders do, it is usually a deliberate decision rather than a spontaneous reaction. That is why a single technical event rarely establishes malice. The Top 10 Insider Threat Indicators page lists the general indicators; the table below shows how the same indicator reads for each type.
| Observation | Points to malicious if | Points to negligent if | Points to compromised if |
|---|---|---|---|
| Upload to personal cloud storage (ATT&CK T1567.002) | Files outside current role, after notice given, renamed or archived first | Files tied to a current task, user working remotely without an approved sharing route | Session from an unfamiliar device or IP, user denies it, preceded by MFA prompts |
| Bulk access to a repository (T1213) | Records unrelated to open tickets or projects; volume far above peers over weeks | A one-off export for a report; same as others in the team | Sudden burst via API or sync client the user never uses |
| Email forwarded externally | To a personal address, selected sensitive threads, during a dispute | Auto-forward set up to read mail on a phone | New inbox rule forwarding and deleting, created from a new session |
| USB or removable media (T1052) | Large copy shortly before leaving; blocked attempts followed by other routes | Presentation copied for a client meeting | Rarely; physical access is unusual for remote attackers |
| Privilege use outside role | Requests for access with no business reason; use of shared admin accounts | Over-granted access used for convenience | Discovery commands, enumeration of groups and shares, new tokens issued |
| Behavioural reports from colleagues | Expressed grievance, unexplained affluence, interest in unrelated projects | Complaints that a process is slow or a tool is blocked | User reports strange prompts, lockouts or emails they did not send |
Two fast tests resolve many cases. The authentication test: did the activity come from the user's known device, location and session, with normal MFA? If not, treat it as compromise until proven otherwise. The peer test: do others in the same role do the same thing? If yes, the issue is probably process or tooling, which points to negligence or a policy gap rather than malice. See ITDR vs UEBA for the tooling that produces these baselines.
Triage: a decision sequence
- Contain exposure without tipping off. If sensitive data is leaving, block the destination or revoke the share. This is safe for all three types and does not presume intent.
- Test for compromise. Review sign-in logs, device identity, token issuance, MFA events and recent password or MFA method changes. If compromise is likely, move to incident response: revoke sessions and refresh tokens, reset credentials, re-register MFA, and contact the user through a verified channel. See the Account Takeover Response Playbook.
- If the user's own session is confirmed, check business context. Is there an open task, ticket or project that explains the activity? Ask the line manager discreetly if the insider risk policy allows it.
- Look at history, not the single event. Pull 30 to 90 days of activity for the same user: escalation, collection outside role, concealment steps, and any HR trigger events known to the insider risk team.
- Decide the route. Negligent or accidental: remediate and educate. Possible malicious: open an insider risk case with HR and legal before any interview. Unclear: keep monitoring under the documented proportionality rules and set a review date.
- Record the reasoning. Note each hypothesis tested and the evidence for and against. This protects the organisation and the employee whichever way the case ends.
Investigation, HR and legal: how each type differs
| Step | Malicious | Negligent | Compromised |
|---|---|---|---|
| Who leads | Insider risk lead or investigations function | Line manager with security support | Incident response lead |
| When HR joins | At case opening, before any contact with the employee | Only for repeated or informed disregard, through the standard policy route | Normally not, unless the user broke a rule that enabled the compromise (for example credentials reused on a personal site against policy) |
| When legal joins | At case opening: privilege, monitoring lawfulness, evidence handling, possible law enforcement referral | When regulated data was exposed and notification may be required | For breach notification assessment and law enforcement contact |
| Evidence | Forensic images, preserved logs with chain of custody, device seizure under policy, no alerting the subject | Logs of the event and the data affected | Authentication logs, endpoint telemetry, attacker infrastructure indicators |
| Contact with the person | Planned interview with HR present, after evidence is secured | Conversation focused on what happened and what would help | Supportive: they are a victim; get their timeline quickly |
| Typical outcome | Disciplinary action, dismissal, civil or criminal referral, access removal | Training, process change, tooling fix; formal warning only if repeated | Credential reset, device rebuild, wider hunt for the attacker |
- Proportionality and privacy: monitoring that supports these investigations must itself be lawful. In the UK, the ICO's guidance on monitoring workers applies the UK GDPR and the Data Protection Act 2018, and the ICO notes it is under review following the Data (Use and Access) Act. Agree with counsel, in advance, what monitoring is in place, how workers are told about it, and who can authorise deeper review.
- Need to know: keep suspected malicious cases to a small named group. Early disclosure harms the investigation and, if the suspicion is wrong, the employee.
- Do not let labels leak: an analyst ticket that says "malicious insider" on day one becomes discoverable and prejudicial. Use neutral case titles.
- Consistency: apply the same thresholds and sanctions to everyone in the same role. Inconsistent handling is a common ground for employment disputes.
For full case handling after data theft, see the Insider Data Theft Response Playbook; for destructive cases, the Insider Sabotage Response Playbook.
Controls per type
| Control | Malicious | Negligent | Compromised |
|---|---|---|---|
| Phishing-resistant MFA, device-bound sessions | Low effect | Low effect | High: removes most credential theft and push fatigue routes |
| Least privilege and access reviews (NIST AC-6) | High: limits what can be taken | Medium: limits blast radius of mistakes | High: limits what the attacker inherits |
| Approved sharing routes and sanctioned tools | Low | High: removes the reason to work around controls | Low |
| DLP with user prompts and justification | Medium: blocks careless routes, determined people find others | High: teaches at the moment of risk | Medium |
| User behaviour analytics and account monitoring for atypical usage (AC-2(12)) | High, if tuned to role and trigger events | Low value per alert | High: new device, location and access patterns |
| Personnel screening, access agreements, sanctions (PS-3, PS-6, PS-8) | High | Medium: makes rules known | Low |
| Leaver process and immediate revocation (PS-4) | High: notice periods are a peak risk window | Low | Medium: dormant accounts are taken over |
| Awareness training (AT-2, AT-2(2)) | Medium: teaches colleagues to report concerns | High | Medium: users report prompts they did not trigger |
The Coinbase insider breach shows the malicious and collusive case: outsourced support agents with legitimate tool access were paid by criminals to pull customer records, so no credential theft was needed and the controls that mattered were access scoped to the case at hand and alerts on reads unrelated to open tickets. The Uber breach shows the compromised case: a contractor's password, bought after malware on a personal device, plus repeated MFA push prompts gave an attacker a trusted session. The lessons are opposite: one needed tighter scoping and monitoring of a trusted role, the other needed phishing-resistant MFA and managed devices for contractors.
Where identity fits
All three types act through identities, and machine identities blur the lines. A developer who copies a production API key to a personal laptop for convenience is negligent; one who keeps it after leaving is malicious; an attacker who finds it in a public repository is a compromised insider by proxy. Service accounts and AI agents with broad read access behave like insiders that never resign. Give them owners, narrow scopes and anomaly detection, and revoke secrets a leaver could have seen. See the Insider Threat and Identity Guide and the Insider NHI Misuse Breaches Lessons Guide.
Worked scenario: one alert, three outcomes
An alert fires: an engineer uploaded 4 GB of design documents to a personal cloud storage account on a Sunday evening.
- Compromised: sign-in logs show the session began from a new device in another country, two hours after a burst of declined MFA prompts and one approval. The engineer, contacted by phone through the directory number, says they approved a prompt by mistake. Response: revoke sessions, reset, re-register a FIDO2 key, block the storage destination, hunt for the same infrastructure across other accounts. No HR involvement.
- Negligent: the session is from the engineer's managed laptop at home. The files belong to a project due Monday, and the corporate file share is slow over the VPN. Three peers have done the same this quarter. Response: remove the personal copy with the engineer's cooperation, fix the remote access route, add a DLP prompt pointing to the approved tool, record a policy reminder. No disciplinary action for a first case.
- Malicious: the session is from the engineer's laptop, but the files span projects they have not worked on for a year, were zipped with a password first, and the engineer resigned on Friday to join a competitor. Response: preserve evidence quietly, open an insider risk case with HR and legal, suspend access under the leaver policy at a planned time, and interview with HR present.
Detection and measurement
- Classification mix: share of closed insider alerts classified as malicious, negligent, accidental, compromised or benign. A mix dominated by "unclassified" means triage is not finishing.
- Time to rule out compromise: median time from alert to a documented authentication check. Target within one hour for high-severity alerts.
- Repeat negligence rate: proportion of users with a second negligent event within 12 months. Falling numbers show remediation is working.
- Peer-pattern findings: number of negligent events traced to a process or tooling gap that was then fixed.
- Leaver window coverage: percentage of resignations in high-risk roles where enhanced monitoring was applied under policy during the notice period.
- Misclassification reversals: cases where the initial label changed after investigation. Track both directions to calibrate analysts.
Common failure patterns
- Jumping to malice: interviewing or suspending an employee before checking whether their account was compromised, which damages trust and can expose the organisation to claims.
- Treating compromise as user error only: resetting a password and closing the ticket without hunting for the attacker's other footholds, mailbox rules or tokens.
- Punishing negligence that the organisation created: disciplining people for workarounds when the approved route did not work, which teaches concealment rather than compliance.
- Ignoring trusted third parties: outsourced and contractor staff with access are left out of monitoring and reviews, as the Coinbase case shows.
- Monitoring without a legal basis agreed in advance: evidence gathered through monitoring that was not disclosed or authorised may be unusable and create its own liability.
- Labelling people in tickets: early labels in case systems prejudice outcomes and leak beyond need to know.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | PM-12 Insider Threat Program; IR-4(6) Insider Threats | Programme and incident handling for insider cases |
| NIST SP 800-53 Rev. 5 | AC-2(12), AU-6, AU-13, SI-4 | Atypical account use, audit review, information disclosure monitoring |
| NIST SP 800-53 Rev. 5 | PS-3, PS-4, PS-6, PS-8; AC-6 | Screening, termination, access agreements, sanctions, least privilege |
| NIST SP 800-53 Rev. 5 | AT-2, AT-2(2) | Awareness training including insider threat |
| NIST CSF 2.0 | GV.RR-04, PR.AT-01, DE.CM-03 | Cyber security in HR practices, awareness, monitoring personnel activity |
| MITRE ATT&CK | T1078, T1213, T1567.002, T1052, T1048 | Valid accounts (compromise), collection and exfiltration routes common to all three |
Practitioner checklist
- Make "rule out compromise" the first documented step of every insider alert playbook.
- Use neutral case titles and restrict suspected malicious cases to a named group.
- Agree with legal and HR, in advance, what monitoring exists, how workers are told and who authorises deeper review.
- Run the peer test before escalating: if a role commonly does it, fix the process.
- Define trigger events (resignation, dispute, role change) that the insider risk team may lawfully use to raise monitoring.
- Include contractors and outsourced staff in access reviews, monitoring and leaver processes.
- Deploy phishing-resistant MFA and device-bound sessions for high-risk roles to remove most compromise cases.
- Give negligent events a remediation route (training, tooling fix) separate from disciplinary routes.
- Revoke secrets and tokens a leaver could have accessed, not only their own account.
- Review misclassified cases quarterly to calibrate triage.
Standards and references
- CISA: Defining Insider Threats
- CISA: Insider Threat Mitigation Guide
- CISA: Detecting and Identifying Insider Threats
- Carnegie Mellon SEI: Common Sense Guide to Mitigating Insider Threats, Seventh Edition
- NPSA: Insider Risk
- ICO: Employment practices and data protection, monitoring workers
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: T1078 Valid Accounts
Related NHI Mgmt Group resources: Insider Data Theft Guide, Insider Recruitment by Threat Actors, Employee Offboarding Security Guide, Insider Risk Management Buyer's Guide.