DLP Investment Justification After a High-Profile Insider Incident

The board debrief after a high-profile insider incident follows a predictable script: someone asks what went wrong, someone else asks what it will cost to make sure it doesn't happen again, and a number gets attached to a plan before the room fully understands what failed. That window of attention rarely stays open past a handful of meetings, so what the security leader does with it decides whether the organization ends up genuinely safer or just poorer and still exposed. The quality of the argument made in that window matters as much as the size of the budget it unlocks.

The window after a high-profile insider incident

The instinct in that room is to act fast and visibly: add controls, expand the DLP footprint that's already deployed, give the board something concrete to point to. That instinct makes sense. Boards want evidence of response, and a CFO freshly burned by an incident wants to see money solve the problem it just caused. But speed without a well-built argument tends to produce more of the same tool category that already let the incident happen, purchased at a larger scale and a higher price. The size of the check matters less than whether the reasoning behind it actually addresses how the incident occurred.

Insider incidents don't happen rarely enough that you can treat any single one as an isolated shock. Fortinet's 2025 Insider Risk Report found that most organizations lost data to an insider within the prior 18 months, several of them more than once. If a single incident triggers the board meeting, it is a visible symptom of a structural pattern that was already running before anyone noticed it, and that reframes the entire conversation: the task isn't responding to an incident, it's fixing a program that was already generating incidents on a regular basis, this one just happened to be the one that got noticed.

The actual distribution of insider risk causes

Any investment case built after an incident has to start with an honest look at what actually causes insider risk, because most existing programs were built to catch a threat profile that represents a minority of actual events. StationX's 2026 insider threat statistics report that roughly three quarters of insider incidents are non-malicious, because negligence and credential theft drive them, not deliberate sabotage. It's a near-total inversion of the common image of the insider threat, not a marginal correction to it.

Negligent insiders account for the largest share of annualized cost across organizations, and credential theft incidents run the highest cost per individual event. Volume compounds both: organizations average more than a dozen insider events per year, and at that frequency, total annual cost gets driven by how often events happen rather than how severe any single one is. Fortinet's 2025 Insider Risk Report backs this up from a different angle, finding that the majority of incidents trace back to negligent or compromised users, with confirmed malicious intent appearing in a much smaller share of cases. Security professionals surveyed for that report say they worry most about careless, negligent, or uninformed employees, more than about deliberate sabotage. Departing employees and people who handle sensitive data daily make up the next tier of concern.

A newer cause category sits awkwardly between these two tiers: shadow AI. When employees feed corporate data into unauthorized AI tools, they open exfiltration paths, and traditional DLP was never built to classify or block them. The behavior looks like ordinary negligence, someone pasting a document into a chat window to save time, but the outcome can match what a malicious actor would have tried to achieve on purpose. Bright Defense's 2026 insider threat statistics cite IBM's Cost of a Data Breach finding that shadow AI adds meaningful additional cost per incident, and that a large majority of the organizations researched had no AI governance policy in place. Fortinet's 2025 report found that more than half of security professionals worry specifically about sensitive data ending up inside tools like ChatGPT, but only a small fraction feel fully prepared to do anything about it.

The practical consequence for anyone building a budget request is straightforward: a program built mainly to catch intentional bad actors leaves the majority cause, negligence and compromised credentials, chronically underserved. Asking "how do we catch the next malicious insider" after an incident is asking the wrong question, because it was already the wrong question before the incident happened. The question that actually matches the data is how to cover the full distribution of causes, and that question points toward different tools than the ones most programs already own.

What the financial structure of insider risk reveals about where to invest

Once the cause distribution is on the table, the conversation can move to numbers a CFO will actually weigh. The single most defensible lever in that conversation isn't prevention spending in the abstract, it's containment speed, because the cost gap between organizations that contain incidents quickly and those that don't is far larger than what most organizations currently spend on detection tooling. Bright Defense's 2026 statistics carry the Ponemon finding on this directly: organizations that contain insider incidents quickly spend materially less annually than organizations where containment drags on, and the gap runs into millions of dollars, tracking closely with how long containment takes.

That gap sits inside a cost trend that has been climbing for years. Average annual insider threat costs have more than doubled since 2018, and both Bright Defense and StationX report new highs in their figures. North America carries the heaviest regional burden. None of this looks cyclical. Each new wave of technology adoption, cloud, then SaaS, now generative AI, adds exposure faster than existing controls can be extended to cover it. The cost curve has structural reasons to keep climbing rather than correct itself.

This is where a formal insider risk program earns its budget on more than intuition. Bright Defense notes that organizations running a dedicated program avoid a meaningful number of incidents each year, and that avoids millions of dollars in breach cost. That gives a security leader a program-level return on investment to present, a distinction that matters in a room where the CFO is comparing this request against every other capital request on the table. And the request doesn't need to be framed as a novel ask: Bright Defense's statistics show insider risk's share of IT security budgets has grown substantially in recent years, most organizations have already been increasing their allocations, and a large share expect to increase them further. The security leader is arguing for a better split of a budget peers are already funding.

The incumbent toolset and the incident it produced

In most cases, the incident that triggered the budget conversation is itself proof that the existing DLP toolset was already deployed and already failing. If the investment case doesn't say that, the money raised in this window will buy a bigger version of the same failure.

The case of Jinfeng Luo at Intel shows how legacy DLP's channel-by-channel design breaks down in practice. DLP caught one path Luo used, but you can't draw the lesson that it worked. A determined insider needs only one unmonitored channel to succeed, and legacy DLP is architected around channels rather than around people, so closing one path leaves every other path exactly as open as it was before.

The case against Linwei Ding at Google shows a cleaner version of the same failure: authorized access defeating a perimeter-based control. Ding, a Google software engineer, allegedly uploaded a large volume of files containing AI trade secrets, including details on Tensor Processing Units and GPU systems, to a personal cloud account between May 2022 and April 2023. He was convicted in January 2026 in San Francisco. No perimeter got crossed in that sequence. The data moved through access Ding was authorized to use, and DLP rules built around channel and classification had no way to tell that activity apart from ordinary work.

Fortinet's 2025 Insider Risk Report, along with its accompanying product analysis, documents how widespread these gaps are. Most organizations can't see how users interact with sensitive data across endpoints, cloud apps, and GenAI platforms. Only a small fraction have effective data discovery and classification running. Only a fraction of security professionals feel fully confident in how their organization detects insider threats. The false-positive rate compounds all of it: false-positive rates in legacy DLP deployments can reach extremely high levels, a result the research traces to static, pattern-based detection methods like regular expressions that can't read context. When analysts spend their days closing false alerts, the real events get by them uninvestigated. The tool isn't just failing to add protection, it's consuming the analyst capacity that would otherwise have caught the incidents that actually mattered. Fortinet's 2025 Data Security Report found that fewer than half of organizations agreed their DLP stopped sensitive data from leaving, even though they had deployed it and were running it actively.

Fragmentation ties the pattern together. A large share of organizations manage multiple DLP policy sets spread across separate, siloed tools, most of them running with no integration into SIEM, UEBA, or automated threat response platforms. Siloed enforcement produces siloed visibility: data moves across SaaS, endpoint, cloud, and browser at the same time, while each control sees only the one slice of that movement it was built to watch. The case of Cameron Nicholas Curry, known online as "Loot," adds a final layer to this picture by showing the contractor lifecycle as a recurring structural weakness. Offboarding lag and loose contractor access provisioning are well-documented failure modes, and static DLP rules can't fix them, because fixing them needs behavioral context about who is leaving and why, and no classification rule can supply that on its own.

The downstream harm from insider incidents, seen by regulators and boards

Once harm from an insider incident reaches people outside the organization, the argument shifts from internal cost containment to legal exposure, and that reframing can move a board faster than any per-incident dollar figure.

A regulatory boiler-room fraud case is the clearest available example of that shift producing criminal consequences. The organization at the center of that case didn't commit the fraud itself, but data that left the organization through an insider made the fraud possible, and regulators prosecuted the resulting chain of harm. That case structure, insider sells data, a third party commits fraud with it, regulators prosecute, is becoming the model regulators increasingly reach for. The argument that lands with a board and a general counsel is that an employee selling data to a third party turns the company into a link in a fraud prosecution chain, a framing that moves the conversation out of the SOC and into a room where HR, Legal, and the board all have a stake.

The security leader should say what this means for governance instead of leaving it implicit. Insider risk is a cross-functional liability that touches HR, Legal, and the board simultaneously. Fortinet's 2025 Insider Risk Report states that insider risk management requires governance, cross-functional coordination, and senior leadership backing, with one decision-maker who holds both the funding authority and the visibility needed to break down data silos. Right now, ownership is split: organizations most commonly assign it to security or the SOC, at 38%, with data protection teams and dedicated insider risk groups each holding smaller shares, and the remainder scattered across IT, enterprise risk, or unassigned. That fragmentation in ownership mirrors the fragmentation in tooling described earlier, and it produces the same blind spots for the same underlying reason: no single party can see, or answer for, the whole picture.

What a modern insider risk architecture does differently

Everything above points toward a specific set of requirements. An architecture built to match the actual distribution of insider risk has to watch behavior across people, not just traffic across channels, because the Luo case proved that closing one channel leaves every other one open. It has to recognize legitimate, authorized access patterns as a potential risk surface in their own right, because the Ding case showed that no perimeter needs to be crossed for serious harm to occur. It has to replace static, pattern-matching detection with methods that can read context, because the false-positive volume in legacy DLP isn't a tuning problem; it's a design limitation that burns the analyst time real events need. It has to integrate across SIEM, UEBA, and threat response instead of sitting as another siloed policy set, because fragmented tools produced fragmented visibility even when each one worked as designed. And it has to account for the contractor lifecycle and offboarding timing directly, because the Curry case showed that provisioning and deprovisioning lag is a structural gap no classification rule can close on its own.

None of that is a request for a bigger version of what already exists. Each requirement traces back to a specific, documented failure mode covered above, which gives a security leader a way to defend the investment spec item by item rather than as a lump sum. That's the argument that holds up inside the narrow window after an incident: not a louder version of the request that produced the current gaps, but a different request, built from the specific ways the current toolset already failed.