The request almost always arrives as a budget line. Someone read a breach post-mortem, or a peer got burned by a departing engineer who walked out with a customer list, and now there is a line item that says insider-threat tooling and a question about which vendor to pick. The premise underneath the line item is that insider risk is a detection problem you solve by buying a sensor.
It is not. The actor is already inside. They have a badge, a laptop, a login, and — the part the sensor cannot fix — a manager, an employment contract, and a set of legal protections. The hard part of an insider-risk program was never the detection. It is that the thing you are detecting is a person you employ, and the way you build the program either earns you the trust that makes it work or turns you into the surveillance department that quietly guarantees it will not.
I run security and DevOps for a fintech that serves more than 1,500 financial institutions, which means our insider risk is also, transitively, our customers' third-party risk. Here is the version I would defend to a board, to an examiner, and — the harder audience — to the employees who have to live inside it.
Insider risk is a governance program, not a DLP purchase
Start with the rename. The field spent years calling this insider threat, and it has been quietly migrating to insider risk, and the rename is the entire argument. Threat presumes malice: the disgruntled employee, the planted spy, the exfiltration on the way out the door. Those cases are real, and they are the minority. The recurring industry studies — the Ponemon Institute's Cost of Insider Risks work most of all — consistently put the majority of insider events in the negligent or mistaken bucket, not the malicious one. The person who emailed the spreadsheet to a personal account to finish it over the weekend. The contractor whose access nobody revoked.
If most of your insider events are mistakes, a program optimized to catch spies is optimized for the wrong distribution. You will build a case-management pipeline for malice and miss the far more common failure: good people, under deadline pressure, working around a control that made their job harder than it needed to be. A DLP tool can flag the spreadsheet leaving. It cannot tell you the person was trying to do their job, cannot fix the broken process that made the workaround rational, and cannot decide what the company owes that person in response. Those are governance questions, and governance is not something you procure.
So the reframe is not cosmetic. Insider risk is a cross-functional governance program that happens to use some tooling, the way a compliance program happens to use a GRC platform. The tool is the last twenty percent. The first eighty percent is deciding, across HR, legal, privacy, and the business, what you will watch, why, who gets to look, and what happens to a human being when something trips.
The surveillance department is the failure mode, not the goal
Here is the trap, and it is easy to fall into because every vendor demo walks you toward it. You buy the platform. It offers keystroke logging, screen recording, sentiment analysis on chat, behavioral risk scoring that ranks your own employees on a dashboard. Each feature is individually defensible. Turn them all on and you have built a panopticon, and the panopticon has three costs nobody puts in the business case.
The first is trust, and trust is your actual control. The insider events that get caught early are overwhelmingly caught by a colleague who noticed something and felt safe saying so. Blanket surveillance destroys exactly that. People who feel watched stop reporting, because raising a concern to a security team that is already recording their screen feels like informing, not helping. You trade a strong human sensor network for a weak automated one and call it an upgrade.
The second is legal exposure, and it is larger than most security leaders assume. In the US, the National Labor Relations Act protects protected concerted activity — employees discussing pay, hours, and working conditions — and monitoring that sweeps them up creates labor-law liability unrelated to security. For firms with staff in Europe the bar is higher still: case law such as Barbulescu v. Romania at the European Court of Human Rights has held that an employer must clear a proportionality-and-notice test before monitoring. The government's own template here, the National Insider Threat Task Force framework, was built for cleared environments where consent to monitoring is a condition of the clearance; copying it into a commercial fintech buys the liability without the legal footing.
The third cost is the one the title is about. Build the surveillance department and that is what your security function becomes, in reputation and eventually in fact. You stop being the team people bring problems to and become the team people route around, and routing around security is the origin story of most of the insider events you were trying to prevent. The posture is self-defeating: the more total the surveillance, the weaker the culture that is your best early-warning system.
Stand up the governance body before you buy the sensor
The fix is to build the human machinery first. Before any tool, stand up a small cross-functional body — call it an insider-risk council, the name does not matter — with a written charter, and make it the thing that owns the program. The tool reports to it. It does not report to the tool.
- Legal and HR are co-owners, not reviewers. Security can build the sensors, but security must not be the body that decides an employee's fate. The moment a signal implicates a person, HR owns the employment dimension and legal owns the privilege and the exposure. Security surfaces and preserves; it does not adjudicate. Draw that line in the charter, before the first case, because you will not draw it fairly in the heat of one.
- Nobody looks alone. Dual control on every investigative action that pierces an individual's activity. One analyst cannot pull an employee's history on a hunch; a request has to be authorized, scoped, time-boxed, and recorded. This is the first thing an examiner or a plaintiff's lawyer will test.
- The program's own data is a crown jewel. The tooling is a concentration of the most sensitive records in the company: behavioral data on named employees. Least privilege on it, logged access to it, monitoring of the monitors. An insider-risk program with no controls on itself is an insider risk.
- Every trigger has a defined, humane response path. Most triggers are not investigations. They are conversations — a manager check-in and a process fix, not a case file — for the negligent majority. The case file, with legal and HR in the room from the first minute, is reserved for the genuine exception. Decide the branch points in advance.
- Notice, not ambush. Employees are told, in plain language, what is monitored, on which systems, and why, not buried in an acceptable-use PDF nobody reads. Notice is both the legal foundation, the proportionality test's first prong, and the trust foundation. A program you would be embarrassed to describe to the people inside it is one you should not run.
- The program is auditable as a program. The Justice Department's Evaluation of Corporate Compliance Programs asks whether a compliance function is a paper exercise or a working control that is resourced, followed, and improved. Hold your insider-risk program to that test: charter, decision log, metrics on outcomes rather than alert volume, an annual review with legal. If it only exists as a tool license, it is cosplay.
Monitor the assets, not the people
With the governance body real, the design principle for the tooling becomes almost simple: monitor the assets, not the people. You are a regulated fintech; the GLBA Safeguards Rule and your FFIEC-minded examiners already expect you to control and monitor access to nonpublic customer information. That mandate is asset-shaped, not person-shaped. Instrument the crown jewels — the customer data stores, the credential paths and pipelines that reach them — and watch how identities interact with them. Do not instrument the human and follow them around the building.
The difference is proportionality, and it is legible in a way blanket surveillance never is. "We log every access to customer-nonpublic data and alert on anomalous bulk export" is a control you can put in a SOC 2 description, defend to an examiner, and explain to an employee without flinching. "We record everyone's screen" is none of those things. Anchor the monitoring to the value at risk — a FAIR-style read on which assets carry the loss exposure that justifies the intrusion — and the program stays proportionate as it grows.
And widen identity past the humans. In an agent-heavy shop — we built AgentOS, our own governed internal agent platform, precisely so this would stay tractable — the thing reaching the crown jewel is increasingly a service account, a token, or an autonomous agent that a human provisioned and may have forgotten. Insider risk now includes the non-human identities your insiders create. Monitoring the asset catches the anomalous token; monitoring the person never sees it.
The exit is where the risk concentrates
If you do one thing beyond standing up the governance body, instrument the exit. Carnegie Mellon's CERT Insider Threat Center has built one of the largest public corpora of these cases, and across it the departure window is where malicious insider events cluster: the weeks between a resignation and a last day, or the run-up to a termination the employee saw coming. It is also the one high-risk event that is not a suspicion. It is a fact, with a date, that HR already knows.
So build the departing-employee protocol as a routine triggered by the resignation, not by a hunch — which keeps it proportionate, because it applies to everyone equally and singles out no one:
- The status change opens the review, automatically. HR's resignation or termination record is the trigger. The council does not decide whom to watch; the calendar does.
- Snapshot access and recent data movement against a baseline. What can this person reach, and what has their access to the crown jewels looked like over the prior thirty to sixty days versus their own normal? You are looking for the anomaly against their baseline, not reading their email.
- Freeze scope, do not expand it. A departure is a reason to stop granting new access and to start timing revocation, not a license to widen surveillance on the person.
- Revoke on the last day, including the non-human identities. The human's SSO is the easy part. The tokens, service accounts, and any agents they stood up are the part that outlives them, and the part exit diligence — yours or an acquirer's — will find if you skipped it.
- Close the loop, then delete the working data. Most reviews find nothing, which is the expected outcome. When one does, the behavioral data collected for it should not become a permanent file. Retention is a control, and over-retention is its own liability.
The whole protocol is defensible precisely because it is boring and universal: it watches the event, not the individual. It is the opposite of profiling.
Where to start
Stand up the cross-functional council and write its charter before you evaluate a single tool. Monitor the assets that carry the loss, not the people who touch them. Instrument the exit as a routine, not a suspicion. And measure the program by the trust it keeps, not the alerts it fires — because the culture where a colleague still feels safe raising a concern is the control no vendor sells.
I am curious where other security leaders have drawn the monitoring line — specifically the proportionality call between watching the asset and watching the person, and how you kept HR and legal co-ownership from turning into a committee that never ships. Tell me how you have built this, or where it went sideways. I read every reply.
