Malicious, negligent and compromised insiders: what differs between them, and what does not?

## Three problems that share a word "Insider threat" is usually spoken as if it named one kind of adversary. It names a **position** occupied in three quite different ways, and confusing them is the single most common wrong answer in this area. **Malicious.** A person with granted access who intends loss. A platform engineer holding standing administrative roles in a cloud account copies the customer data store a fortnight before resigning. Intent is present and the actions are deliberate. **Negligent.** A person who intends nothing and causes loss anyway. A finance analyst on a Friday afternoon exports a customer table out of the reporting system and into a personal spreadsheet service, because the sanctioned path is slow and the report is due. No exploit, no unusual account, no dishonesty — and the customer table is now in a place with different owners, different retention and a different account recovery story. **Compromised.** A person who is not acting at all. Their session or long-lived credential is held by someone else, and the calls arrive under their name. From the environment's point of view this is the account doing its job. ## What varies, and what is invariant | Subtype | What is different | What is identical | |---|---|---| | Malicious | Deliberate intent to cause loss | Account, device, hours, permitted operations | | Negligent | No intent; convenience under time pressure | Account, device, hours, permitted operations | | Compromised | The named person is not the one acting | Account, device, hours, permitted operations | The right-hand column is the whole lesson. Everything that would let you tell the three apart lives in the person's head or in someone else's hands; nothing about the position exposes it. A successful sign-in proves a credential was accepted, never that its owner was present or willing. ## Why that collapse is useful rather than depressing If the three are indistinguishable from the position, then any control that has to know *which one you are facing* is unbuildable. That immediately disqualifies a whole family of proposals: - **Screening.** Background checks are a point-in-time filter aimed at the malicious subset. They say nothing about a careless export and nothing at all about a stolen session, and a person's circumstances change after they are hired. - **Trust and culture.** Genuinely valuable for retention and for people reporting their own mistakes, but two of the three problems do not involve dishonesty, so trust cannot be the bound. - **Contractual clauses.** They allocate liability after the loss. They do not shorten the reach of a role. What survives is the class of control that acts on the position rather than the person: the **scope the role may grant**. Whether the analyst's role can export a whole table or only the rows a report needs; whether the platform role can read a customer data store at all or only manage the infrastructure around it; whether either role can grant itself or someone else more scope. Each of those bounds the loss identically in all three cases, which is exactly the property you want from a control aimed at an actor you cannot classify. ## The framing that wins the interview Asked "how do you handle insider threat", say first that it is three problems sharing a name, then that the three are indistinguishable from the position, then that the only movable knob is scope. If you are asked which of the three is most common, resist ranking them by drama: the negligent case dominates by volume in most organisations and produces real, reportable loss with nobody having done anything dishonest. ## The trap to avoid Do not answer that insider risk is a hiring or a trust problem. It is the answer interviewers are listening for, because it silently assumes the malicious case is the whole category — and it leaves the two subtypes that account for most of the actual loss completely unaddressed.