The insider you cannot just lock out: responding to a privileged departure

There is a moment in a lot of insider cases where two people in the room are looking at the same evidence and reaching opposite conclusions. One says: cut his access now, we cannot let this continue. The other says: if we do that, we lose everything. Both are experienced. Both are right about something. The reason they disagree is that one of them is still running the external-attacker playbook, and the other has realized it does not apply.

For an outside intruder the playbook is simple and correct: contain first, scope second. Cut the access, kill the session, revoke the token, and figure out the rest afterward. Speed is unambiguously good, because the adversary has no legitimate reason to be there and nothing about a fast response harms anyone who matters. The whole discipline of external incident response is built on that assumption.

An insider breaks the assumption. The person you are worried about has legitimate access, legitimate reasons to use it, a manager, an employment contract, rights, and - crucially - knowledge of how you watch. Acting fast against them is not free. It can tip off a genuinely malicious insider so they destroy evidence or trigger whatever they staged. It can taint the chain of custody you would need to act on them lawfully. It can break employment or privacy law and hand them a wrongful-treatment claim. And most uncomfortably, it can inflict real harm on someone who turns out to have had an ordinary explanation. A departing privileged administrator is the sharpest version of this problem, because they hold the most access and the “obvious” move against them is the most expensive if you are wrong.

Why does the contain-first reflex backfire on insiders?

Because containment is a hostile act, and against an insider a hostile act has consequences the external playbook never has to price in.

Think about what “cut his access” actually does when the subject is an admin who is still employed, still has a badge, and still has colleagues. If he is malicious and coordinated, the lockout is his signal to burn the evidence, tip an accomplice, or fire the logic bomb he left behind - you traded a few minutes of exposure for the entire case. If he is not malicious - if the “anomaly” was a legitimate late-project data pull, or a negligent shortcut, or a compromised account being driven by someone else - you have just publicly treated a colleague as a criminal on the strength of a hunch. Either way, you have taught everyone who watches that admitting anything, or even looking unusual, gets you cut off and confronted. That lesson is expensive: it drives the next person’s mistake underground, where you will find out about it much later and much larger.

The external playbook never has to weigh any of this, because an intruder has no standing to be harmed, no evidence chain you are trying to preserve for an employment tribunal, and no chilling effect on a workforce you depend on. The insider case has all three.

Why is the “user” the hardest part, not the access?

Every insider scenario has two objects: the access, and the person. External response only ever deals with the access. Insider response is dominated by the person, and the person is where all the ambiguity lives.

An insider signal is behavioral, not a known-bad indicator. You are not matching a hash or a C2 domain; you are reading access that is legitimate but out of pattern. A resigning engineer suddenly browsing repositories outside their team. Bulk reads of documents they never touched before. Forwarding to personal channels in the final two weeks. A privileged account making changes at an hour the human never works. None of these is proof of anything on its own, because each one has an innocent version. That is the entire difficulty: an anomaly is a question, not a verdict.

And the four ways an insider incident can actually be true point to four different responses. A malicious insider is deliberately acting against you. An administrative-error insider is a trusted admin who made a high-blast-radius mistake with no ill intent. A negligent insider is a well-meaning person who bypassed a control for convenience. A compromised insider is a victim whose access is being driven by someone else, sometimes under coercion. The same raw signal - “privileged account is exfiltrating data” - can be any of these, and the correct action for one is the wrong action for the others. That is why “who is this, really?” has to be answered before “what do we cut,” and why the answer cannot come from the security team alone.

How do you decide between governing and acting?

The decision is not “respond or do not respond.” It is which of two regimes you are in, and the clues in the incident tell you.

Govern is the default when harm is not imminent, intent is ambiguous, and an innocent explanation is live. Governing does not mean watching passively. It means you engage the insider-risk program as a whole - security together with HR or Employee Relations, Legal, and the person’s management - rather than acting unilaterally. You preserve evidence to a standard that would survive scrutiny: authorized monitoring only, clean chain of custody, nothing that a lawyer can later call entrapment or an illegal search. You apply proportionate, authorized monitoring to answer the question the anomaly raised. And you do all of this without tipping the subject, because if they are malicious your best asset is that they do not yet know you are looking.

Act is correct when harm is imminent and irreversible - active sabotage or deletion in progress, or mass exfiltration where malice is already established. Here decisive, authorized action to stop the specific irreversible harm beats preserving the case, because a perfectly documented case is worthless if the data is already gone or the systems are already wiped. In the act regime, “keep observing” is the wrong call.

Most real privileged-departure cases are govern with a narrow carve-out: you handle the person through the governed process, while you immediately cut any unauthorized standing persistence they created - a backdoor account, an extra credential, a personal-cloud sync rule, an OAuth grant that should not exist. Those are unauthorized and carry irreversible risk regardless of intent, so they come out now. The distinction that makes this work is authorized-and-explainable versus unauthorized-and-standing. You govern the ambiguous, legitimate access; you cut the illegitimate persistence.

What does “govern” actually look like for a departing admin?

Concretely, and in order: preserve before you disturb. Do not delete the account, wipe the laptop, or “clean up” anything - preserve the account and its activity, because those are your evidence. Quietly confirm what has actually been accessed and where it went, using authorized telemetry, so you are reasoning from facts rather than from the shape of a hunch. Bring HR and Legal in early, so that whatever you eventually do is defensible and so that the employment and privacy constraints are known before, not after, you act. Prepare the decisive action - staged access revocation, a coordinated conversation, a referral if warranted - but do not trigger it prematurely; hold it ready for a coordinated moment. And keep the audit trail of who did what, when, and from where, because that record is what turns a suspicion into a defensible decision later.

If the evidence tips toward imminent, irreversible harm, you move to act - now, decisively, and still authorized. If it does not, you keep the option ready and let the evidence and the process catch up to it. Either way, you have not foreclosed anything.

The failure mode to avoid has a name worth saying plainly: treating a person who has legitimate access like an intruder. It feels decisive, it satisfies the room, and it routinely destroys the case, the evidence, and sometimes an innocent employee’s standing all at once.

Why can’t detection tooling just tell you the answer?

Because the tooling surfaces the anomaly, and the anomaly is the beginning of the work, not the end of it. UEBA and DLP are good at “this is out of pattern” and bad at “this is malicious,” for the simple reason that intent does not live in the telemetry. The forwarding rule that looks like exfiltration is identical, at the log layer, to the forwarding rule a diligent employee set up to keep working over a holiday. The bulk read that looks like theft is identical to the bulk read of someone closing out a project they own.

What separates the readings is context the tooling does not hold: Is this person actually leaving, and on what terms? Was this access part of their job last month? Is there a legitimate business reason sitting one Slack message away? Does the destination tie to anything external? A mature insider-risk function treats the alert as a prompt to assemble that context - deliberately, proportionately, and with the other functions in the room - rather than as a verdict to execute. The instrument tells you where to look. It does not tell you what you are looking at.

How should a security leader frame this to the business?

Two ideas do most of the work. First, insider response is a governance function, not a containment function - it lives at the intersection of security, HR, and Legal, and a security team acting alone on an insider is a liability, not a capability. Second, the goal is not to catch people; it is to make the right call under ambiguity fast enough to matter and cleanly enough to defend. Those framings change what you invest in: not just better anomaly detection, but the cross-functional process, the evidence discipline, and the pre-agreed decision rights that let you move without either freezing or overreacting.

The uncomfortable truth underneath all of it is that the insider was always inside. There was never a perimeter to keep them out. The entire discipline is about what you do with what you can see, and the most common way to get it wrong is to reach for the one move - cut access, confront, done - that feels like control and usually is not.