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 no sensor fixes: a manager, an employment contract, and a set of legal protections. The hard part 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 the trust that makes it work or turns you into the surveillance department that 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 to the hardest audience of the three: 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 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. 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 insider risk is a 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
Every vendor demo walks you toward the trap. 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. Raising a concern to a security team that is already recording your screen feels like informing, not helping, so people stop. 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, the National Insider Threat Task Force framework, was built for cleared environments where consent to monitoring is a condition of the clearance. Copy it into a commercial fintech and you buy 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.
Stand up the governance body before you buy the sensor
Build the human machinery first. Before any tool, stand up a small cross-functional body, call it an insider-risk council, with a written charter, and let it own 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 concentrates 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. For the negligent majority they are conversations: a manager check-in and a process fix, not a case file. 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 the proportionality test's first prong and the trust foundation at the same time. 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 is simple: monitor the assets, not the people. You are a regulated fintech; the GLBA Safeguards Rule (opens in new tab) and your FFIEC (opens in new tab)-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 (opens in new tab) 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. Do that and the program stays proportionate as it grows.
Then widen identity past the humans. In an agent-heavy shop the thing reaching the crown jewel is increasingly a service account, a token, or an agent a human provisioned and forgot. We built AgentOS, our own governed internal agent platform, precisely so that would stay tractable. 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 trigger the departing-employee protocol on the resignation, not on a hunch. That is what keeps it proportionate: 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 find something, the behavioral data collected for it should not become a permanent file. Retention is a control, and over-retention is its own liability.
The protocol is defensible precisely because it is boring and universal. It watches the event, not the individual. It is the opposite of profiling.
The control no vendor sells
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 rather than the alerts it fires, because the culture where a colleague still feels safe raising a concern is the control no vendor sells.
I want to know where other security leaders have drawn the proportionality line 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 where it held, or where it went sideways. I read every reply.