Est.

Detecting Data Exfiltration Before Employee Resignation

Employees steal data months before resigning, giving security teams a window to act.

Senior Writer · · 12 min read
Cover illustration for “Detecting Data Exfiltration Before Employee Resignation”
Insider Threat Detection · September 2, 2026 · 12 min read · 2,603 words

Looking at the text, the required step is to identify "Not X, It's Y" constructions and similar contrast-negation patterns across sentences and paragraphs, then rephrase them while preserving all names, headings, and structure.

When the exfiltration arc actually begins, relative to the resignation date

Treating the resignation letter as the starting gun for investigation is the central mistake in most insider risk programs. Research has tracked exfiltration activity by departing employees climbing as many as 200 days before a formal resignation or layoff notice. That's a two-thirds-of-a-year window running unwatched, and any program that starts its clock at the announcement has already missed most of the story before it opens a case file.

Layoffs break the pattern, and the break runs counter to what teams tend to expect. Research found a 720% spike in exfiltration activity in the 24 hours immediately before a layoff notification lands; employees who anticipate they're being let go often act within hours, before HR or IT has time to lock anything down. Carnegie Mellon's CERT data adds a second layer worth sitting with: 70% of insider IP theft happens within 30 days of a resignation announcement. That number sounds like good news until the implication lands. The 30-day clock starts after the announcement, so by the time a security team has formal cause to open an investigation, the announcement-period damage is largely done, and the 200-day ramp that preceded it went entirely unmonitored.

Sentiment precedes the decision to leave, which precedes the act of taking data. That order is structural, not incidental. Departing employees keep their full, legitimate access right up until someone revokes it, and their exfiltration hides behind the same permissions any other employee holds. Nothing about it trips a wire built to catch unauthorized access, because the access was never unauthorized in the first place. The permissions were valid, and the theft happened anyway — that gap is the whole problem.

What the behavioral arc looks like before anyone submits a resignation letter

Break the arc into four phases and the pattern gets legible, even though no single phase looks alarming on its own. The individual signals are supposed to look ordinary; that's what makes them hard to catch.

Phase one is emotional and organizational disengagement, and it's the hardest to catch in isolation. It shows up as dissatisfaction voiced in written communications, friction with a manager, quiet withdrawal from team channels. Login timestamps tell a similar story: after-hours activity with no corresponding project work, because someone preparing to leave often works odd hours specifically to avoid being noticed. Calendar activity thins out, and participation in forward-looking planning drops off.

Phase two is access and reconnaissance shifts, unfolding over weeks or months. An employee starts touching systems, files, or directories outside their normal scope, not necessarily the crown-jewel targets yet, but unusual lateral movement all the same. Policy documents, org charts, client lists, and contracts start getting opened or downloaded, none of which serve the employee's current job function but all of which are useful after they've left. Employees start reviewing their own historical files and past projects too, a pattern that resembles collecting more than working.

Phase three is staging and aggregation, typically compressed into the final days or weeks. Bulk downloads and exports start exceeding what's normal for that specific employee, though the files themselves may be fully authorized, so a static DLP rule sees nothing wrong. Files get compressed, renamed, or shuffled into staging folders ahead of the transfer. Research adds a wrinkle that matters more than it first appears: the majority of exfiltrated data consists of fragments, not clean file copies, including partial spreadsheets, screenshots of confidential slides, and AI-generated summaries of proprietary material. A hash-matching rule has no basis for treating any of that as a classified document. Increasingly, staging happens inside AI tools themselves; Research shows that a large share of the data employees paste into AI applications qualifies as sensitive.

Phase four is execution, often compressed into the last days or hours before departure. The largest single channel by volume is personal cloud storage, accounting for 22.7% of incidents in available research data, followed by removable media at 15.6% and generative AI tools at 13.1%. Personal email and messaging apps carry the rest, often timed for weekends or off-hours to cut the odds of being seen in real time. No single phase proves anything by itself. The proof is in the sequence, and only in the sequence.

Five real cases that show how the arc plays out differently depending on motive and access level

Five cases from the past few years show how differently this arc can present, depending on what the person wanted and what access they had.

In one documented case, insider exfiltration activity only surfaced once a resignation was tendered. That timing captures the whole problem in miniature: the exfiltration had been building for months, and the resignation was merely the moment it became visible.

A second pattern is more troubling still. In cases where an individual is hired into a role that comes with legitimate access to collaboration and cloud platforms from day one, sensitive data can leave undetected over an extended period. No file policy need ever be violated, because the access was sanctioned from the start. Static rules have nothing to catch here. Only a deviation from that individual's own baseline could have surfaced it.

A retaliatory incident from early 2025 sits at the opposite end of the spectrum. Two engineers deleted 96 government databases and exfiltrated files before their access could be revoked. This case moved fast, and the speed is the point: termination-triggered retaliation can compress the entire exfiltration arc into hours. The pre-signals here weren't months of quiet reconnaissance. They were conflict and discontent, visible earlier, if anyone had been watching for them.

A fourth pattern involves bulk leaks by departing employees whose transfer volumes far exceeded anything in their own historical baselines. That volume deviation alone should have tripped an alarm, regardless of what the files contained.

The hardest case to catch involves no resignation signal at all. Flashpoint has reported that DPRK-affiliated operatives conducted more than 6,500 interviews targeting over 5,000 companies by mid-2025, seeking legitimate employment under false identities. Once hired, their access is fully authorized and their activity is, by design, indistinguishable from ordinary work. There's no departure to watch for, because the entire relationship is a pretext from day one. Behavioral anomaly is the only detection path that exists here, full stop.

Across all five cases, the exfiltration looked like work. The signal was a change relative to what that specific person normally did, rarely a broken rule.

Why static DLP rules cannot see a pattern that spans weeks and multiple systems

Legacy data loss prevention tools evaluate a single moment: a file transfer, an email attachment, a download event. They don't see the 60 days of access pattern shifts that came before it, so the context that separates theft from ordinary work stays invisible to the tool by design. A static rule compares an event against a policy. It has no concept of comparing an event against a person's own history, and no amount of tuning fixes that gap, which is the architectural problem platforms like Candor Security, a behavioral DLP platform for modern enterprises, are built around. The architecture was never built to hold a timeline, and pretending otherwise is wishful engineering.

That mismatch produces a predictable failure mode: alert floods that train analysts to stop looking closely. When every large download trips a rule regardless of who made it, the response becomes less scrutiny rather than more. The genuine threat hides inside the noise it creates. This runs deeper than a tuning problem; it's a design flaw baked into what the tool was asked to do in the first place.

The fragment problem makes it worse. If more than 80% of exfiltrated data, per available research, consists of partial files, screenshots, and AI-generated summaries rather than clean copies, then hash-based and classification-based rules miss most of what actually leaves the building. The data simply doesn't resemble the document it was taken from. Generative AI compounds the blind spot further: legacy DLP was built to watch file transfers and email attachments, and it has no native way to inspect content pasted into an AI chat window. Research shows 77% of employees pasting some form of data into AI applications, and 13.1% of insider exfiltration incidents now run through those tools specifically.

Underneath all of this sits what might be called the access paradox. A departing employee with full, legitimate permissions isn't violating any access rule, so a permission-based control has nothing to flag. The signal that actually matters, behavioral deviation, is precisely the thing static tools were never built to measure. Analysts triage an alert flood with no way to separate the real threat from the noise, and a pattern that took eight or ten weeks to build across four different systems never gets assembled into anything a person can act on. That failure isn't a bug in any one tool. It's what happens when a moment-based architecture gets asked to answer a question about time.

What behavioral detection across a user timeline actually looks like in practice

The fix requires a different question, and it's not a subtle one. Ask whether a user's current behavior is consistent with their own history, and whether the sequence of events, taken together, tells a coherent story. Everything else is downstream of getting that question right.

Start with baselining at the individual level rather than the policy level. What does this specific employee normally download, access, and send, and when do they typically log in and out? A 500-file download is unremarkable for a data engineer and genuinely alarming for someone in HR. Anomaly only means something relative to a specific person's own pattern. Measured against a company-wide policy threshold, it means almost nothing, and treating it as though it did is the default mistake in most legacy tooling.

Cross-source stitching isn't optional here; it's the whole mechanism. Phase one signals, the discontent and disengagement, live in HR systems, communication platforms, and calendar data. Phase two signals, the reconnaissance, live in identity and access logs and endpoint activity. Phase three, the staging, lives in file systems, cloud storage, and email. Phase four, the exfiltration itself, shows up in network activity, USB logs, and cloud upload events. No single source holds the whole arc. A detection approach that only watches one layer only ever sees one chapter of a much longer story.

Time matters as much as breadth. A detection model needs a lookback window long enough to establish what normal looks like and catch drift away from it; a 24-hour window catches the spike at the end and completely misses the 200-day ramp that built up to it. The output that reaches an analyst needs to arrive already assembled, showing what changed, when, and across which systems, sparing hours of manual digging just to gain context. Any behavioral system worth using also has to show its reasoning, laying out which signals fired, in what order, over what timeframe, so the finding can survive scrutiny from HR, from legal, from a courtroom if it comes to that. Integration depth sets the ceiling on all of this: a platform connecting identity systems like Okta, endpoint tools like CrowdStrike, collaboration platforms like Google Workspace or Microsoft 365, HR systems like Workday, and a SIEM like Splunk can stitch the full arc together. A point solution watching one data source cannot, no matter how good its algorithm claims to be.

How security teams use behavioral signals to prioritize cases rather than triage alerts

Picture a team fielding hundreds of DLP alerts a day. Analysts spend their hours closing tickets, not building cases, and the loudest alert is rarely the real threat. The real threat is usually the quietest pattern in the queue, the one that never crossed a single hard threshold, and by the time anyone notices, it's been running for weeks.

Risk scoring changes the job from ranking alerts to filtering users. A behavioral system scores individuals over time and surfaces the ones whose pattern has drifted meaningfully, rather than flagging every event that happened to cross a static line. A user whose risk score has climbed steadily for three weeks deserves a different conversation than a user who triggered one large download this morning; conflating the two is how the real case gets buried under the loud one. The trigger for intensified monitoring shouldn't wait for a resignation letter at all. Given that the exfiltration window can open up to 200 days early, the moment HR flags someone as resigned, at-risk, or on a performance plan should automatically raise monitoring intensity, well before any formal notice arrives.

A complete case, before it ever lands on an analyst's desk, should include a timestamped timeline of behavioral change with source attribution, a clear account of what data was touched or moved and where it was headed, and a comparison against that individual's own baseline rather than a generic policy. The analyst's job becomes deciding, not reconstructing. That distinction is what separates a program that scales from one that drowns.

The distinction matters most for teams that can't hire their way out of the problem. Most insider risk programs run without dedicated headcount, staffed instead by security generalists doing the work alongside everything else on their plate. For those teams, a platform that surfaces only pre-contextualized, genuine cases fits their staffing reality in a way that raw alert volume never will. There's a legal dimension too, one that outlasts the security outcome itself: a case built on a documented behavioral timeline holds up in termination proceedings, litigation, and regulatory review in a way that a folder of single-event alert screenshots never will.

What an early detection program for pre-resignation exfiltration needs to be able to do

None of this works if detection stays anchored to the "known leaver" trigger. That model is structurally late by design, and no amount of tuning the trigger fixes a model that starts the clock in the wrong place. A program has to run continuously across the entire employee population, not just the subset who have already announced they're going. Waiting for the announcement is, at this point, the wrong default, and treating it as a defensible middle ground is how the 200-day window keeps getting missed year after year.

A few capabilities aren't optional. Behavioral baselining needs a lookback window measured in weeks or months, not hours, because the arc itself runs that long. Signal correlation has to span identity systems, endpoints, cloud platforms, collaboration tools, and HR data at once, since no single source carries the full picture. Coverage has to extend past traditional file movement into AI tool usage, clipboard activity, screenshots, and partial document fragments, given how much exfiltrated data now leaves in pieces rather than whole files. Risk scoring needs to accumulate over time and surface drift, not just flag threshold crossings. Cases need to arrive at the analyst pre-assembled, with context attached, instead of raw events waiting to be pieced together. HR integration also needs to be tight enough that a resignation, a performance improvement plan, or an offboarding event automatically raises monitoring intensity the moment it's logged, not weeks later once someone remembers to check.

The 200-day window is the fact that reframes everything else here. Detection built around the resignation date targets the wrong event. The event actually worth watching for started months earlier, and at every step along the way, it looked almost exactly like work.

Sources

  1. swif.ai
  2. syteca.com

More in Insider Threat Detection