Exfiltration Timing Patterns Relative to HR Lifecycle Events

Data exfiltration by departing employees does not happen uniformly across the employment lifecycle. It clusters inside a small number of predictable windows tied to specific HR events, and most organizations spend their security budget protecting the wrong one. The controls that get the most investment, badge deactivation, laptop recovery, the final exit interview, guard the last mile of an employee's tenure. The damage, in a meaningful share of documented cases, is already done by then.

Structural factors, not behavioral ones, produce this pattern. An employee's decision to leave a company precedes any formal signal to HR by a substantial stretch of time, and during that stretch the employee still holds every credential, every permission, and every login they held the day before. Security teams cannot watch for a departure they do not yet know is coming. That mismatch, between when the risk actually begins and when the organization's monitoring posture changes, is what produces the clustering. Three windows carry distinct risk profiles: the period before anyone decides to resign formally, the notice period that follows a resignation, and the compressed gap that opens the moment an involuntary termination is communicated. Each works differently, and each demands a different response. The rest of this piece maps all three.

The pre-announcement phase: when exfiltration happens before security teams know there is anything to watch

The most dangerous window on the HR timeline is also the one with no formal name in most offboarding policies, because nothing has happened yet that HR would recognize as an event. Suspicious activity often begins up to six months before a formal departure. The employee has made the decision to leave, but no resignation letter exists, no exit interview is scheduled, and no manager has been told. Full legitimate access remains in place throughout.

That combination, intent without any administrative trace of it, is what makes the phase so hard to police. The employee's actions during this period look almost indistinguishable from ordinary work. Bulk downloading files from shared drives or a CRM system, emailing documents to a personal address under the cover of "keeping safe copies," uploading material to personal cloud storage, printing documents, copying files to a USB drive: none of these actions trip a rule-based DLP alert when a credentialed user performs them, because each one sits inside what the role is already permitted to do. Inside SaaS environments specifically, the same pattern repeats in forms that look like routine daily use: copying files to a personal Google Drive, forwarding pipeline contacts to a personal email address, downloading a customer list, generating a shared link set to "anyone with the link." All of it happens constantly across a normal workforce.

The Deel case from March 2025 is the clearest documented illustration of what this phase looks like when it goes wrong. An alleged insider, hired as a Global Payroll Compliance Manager, held legitimate access to Slack, Salesforce, and Google Drive. Activity that reportedly included exfiltration of customer lists, pricing details, and competitive intelligence went undetected for four months. By the time a resignation letter reaches HR, in cases like this, a meaningful portion of the damage has already occurred, and no part of the standard offboarding sequence, which begins only once HR is notified, ever had a chance to intervene.

The notice period: why organizations misread two weeks of open access as low risk

Once a resignation is submitted, the risk picture does not improve, even though it becomes visible for the first time. The two weeks of notice that follow are often treated by organizations as a low-risk interval, something to be managed administratively rather than defended against. That reading gets the moment backward. The employee's loyalty has already shifted by the time notice is given, yet in most companies, full access to systems remains intact precisely so the person can finish projects and hand off their work.

Keeping an employee's access open during notice so a handoff can happen smoothly is a defensible business decision. Productivity typically drops the moment notice is given, even as systems access stays at its pre-resignation level, and that gap between declining engagement and undiminished access is precisely when the motivation to extract data is at its highest and the oversight of that access is at its lowest. Organizations that leave access untouched until the final day are not managing a known risk. They are failing to notice they ever made a decision.

Making that decision explicit is the actual intervention available here. For voluntary departures, IT access during the notice period should be scoped down, with sensitive systems reviewed at the moment notice is received rather than left intact until the employee's last day. The scoping has to balance two failure modes: restrict access too aggressively and the knowledge transfer the notice period exists to support breaks down; wait too long to restrict it and the security exposure runs for the full two weeks instead of a fraction of it. Role matters as much as timing here. Privileged users, IT admins, developers with production access, executives who touch financial systems, need to be treated differently from individual contributors regardless of whether the exit is voluntary or not. An individual contributor's access can reasonably phase out across the notice period with a full cut on the last day. A departing developer or engineer needs production access actively monitored during that window, with credentials revoked on the final day. An IT admin or other privileged user needs same-hour or same-day revocation with a second reviewer signing off, a tighter standard than the general workforce gets because the blast radius of a privileged account is categorically larger.

Involuntary separations: the acute timing gap between notification and access revocation

Involuntary separations remove the notice period altogether, and with it, the two weeks of lead time that voluntary departures at least offer security teams to plan around. What remains is a much smaller and more acute gap: the interval between the moment an employee learns they are being let go and the moment their access to company systems actually disappears.

That interval can be measured in hours, not days, and during it a departing employee may still hold full access to Salesforce, to the company codebase, to customer databases, or to financial systems. The standard this demands is correspondingly strict: for involuntary departures, IT access should be revoked at the moment of notification, simultaneously with the termination conversation rather than sometime after it concludes. Achieving that kind of simultaneity is not something IT can improvise in the moment. It depends on pre-coordination between IT, HR, and security arranged well before the conversation ever takes place, so that revocation can begin the instant the discussion starts, or even just ahead of it. Security and IT need to be looped in before the employee is notified, so the technical and the human parts of the termination happen on the same clock.

Legal sequencing requirements complicate the timeline without changing what the security clock demands. For employees aged 40 and over, a federal age-discrimination law requires a 21-day review period (45 days for group terminations) plus a further 7-day revocation period attached to any release agreement. That legal timeline runs alongside the immediate access-revocation requirement, not in place of it. The same is true of WARN Act obligations for mass layoffs in the US, and of statutory redundancy rules in the UK: these govern how and when an organization notifies employees of a termination, but none of them extend the window during which a terminated employee should retain system access. The legal clock and the security clock run on separate tracks, and conflating them, treating a 21-day review period as license to leave access open, is itself a security failure.

Why the offboarding checklist cannot close the pre-HR-notification gap

Offboarding checklists, however thorough, share one structural limitation: they are triggered by HR events. A checklist activates when a resignation is logged, when a termination is processed, when an exit date is entered into a system of record. That means the checklist is, by design, blind to anything that happens before an HR event occurs, which is exactly the window the pre-announcement phase occupies and exactly where the Deel case's four undetected months took place.

Even once a checklist does trigger, most of the applications a departing employee used are invisible to it. The average employee today uses dozens of applications, a large share of them adopted informally, outside IT's provisioning workflows, without SSO coverage, and without any centralized record that the account exists. A checklist built around a company's identity provider cannot revoke access to a tool the identity provider never knew about. Even for the tools it does know about, deactivating an account in the identity provider does not revoke OAuth tokens, does not terminate active sessions, does not invalidate API keys, and does not remove access to content that was shared externally before departure. Treating IdP deactivation as the finish line of offboarding is one of the most common and most dangerous misconceptions in the entire process. Active sessions inside platforms like Slack, Salesforce, and Box can persist for hours or days after IdP deactivation, and a former employee with an active mobile session may retain full working access well past the date their employment officially ended.

The scale of the resulting exposure is documented in multiple industry surveys. Sixty-three percent of ex-employees retained active access to organizational data after their departure, Wing Security found, and Beyond Identity found that a substantial majority of IT professionals say former employees still hold some form of active access after leaving. DoControl's own data recorded a case of a former employee accessing SaaS assets two years after leaving an organization, an extreme instance but a documented one, of how far the persistence vector can run. The private sector is not alone in this problem. An inspector general's office reviewing a federal financial regulatory agency found that offboarding weaknesses led to delayed deactivation of identity-verification credentials and site badges for departing employees and contractors, confirming that the same structural gap appears inside federal oversight bodies as readily as it does inside private companies.

Closing the gap that opens before any HR event occurs requires something a checklist cannot provide by its nature: a detection layer that runs continuously, independent of whether HR has logged anything yet.

Why traditional DLP fails against exfiltration via legitimate access

Legacy data loss prevention tools were built to enforce a perimeter and inspect content crossing it. That design assumption breaks down against exfiltration carried out by a credentialed user during a window the HR timeline already predicts, because the action in question is technically permitted by the user's role no matter when on that timeline it happens.

Three structural blind spots follow from that mismatch. Legitimate access defeats rule-based detection outright: an employee downloading files from a project they work on raises no flag, because the system has no rule against an authorized action. Only a statistical anomaly, an unusual volume, an unusual hour, stands a chance of triggering a flag, and catching those requires a carefully tuned behavioral baseline that most rule-based DLP deployments were never built to maintain. DLP also loses all visibility once a file leaves the corporate boundary. A document copied to a personal cloud account or a USB drive exists entirely outside anything DLP can see from that point forward. And access revocation, as the offboarding data above shows, is frequently too slow in practice, leaving former employees with working access to cloud platforms and SaaS tools for days or weeks past their last day of employment.

The Deel case again supplies the clearest documented example of this failure mode operating at scale. Activity went undetected for four months because each individual action, querying Salesforce, accessing Google Drive, posting in Slack, fell within what the role's technical permissions allowed, giving no rule-based system any cause to raise an alert. The case has since produced proceedings across multiple jurisdictions: a filing in California federal court, a case before the Irish High Court, a countersuit filed in Delaware that was later dismissed, and a grand jury investigation opened by a federal law enforcement agency. That legal sprawl is the downstream cost of a detection gap that opened quietly, in the pre-announcement phase, long before any of the parties involved knew there was a dispute.

Most DLP tools, beyond the Deel case specifically, run into a problem that is endemic to the SaaS era generally: distinguishing a legitimate cloud sync from a deliberate act of exfiltration is, for a system built around content rules, close to impossible, because the two can look mechanically identical.

Detection anchored to the HR timeline instead of static rules

Closing the pre-announcement gap means running continuous behavioral monitoring that can detect a deviation from an individual employee's own baseline before any HR event has occurred, and that automatically tightens its sensitivity the moment an HR signal, a resignation, a notice date, a termination flag, does arrive.

That design differs from legacy DLP at the architectural level, not just in degree of tuning. Endpoint-based detection captures actual user behavior at the device level: access timing, volume, destination, and the application context surrounding an action, rather than only inspecting traffic as it crosses a network perimeter. Building a baseline per individual changes the question a detection system is asking. Instead of "did this action exceed some fixed, organization-wide threshold," the system asks whether this action is consistent with this particular person's own established pattern. That distinction carries the most weight during the pre-announcement phase, when the volume of a given download or upload may still sit within a plausible range for the role, and only a comparison against that individual's own history, rather than a flat company-wide rule, would register it as unusual.

Anchoring that behavioral baseline to the HR timeline, rather than running it as a flat, constant-sensitivity system, is what makes the three windows described above actionable rather than merely descriptive. A detection system that knows a resignation was just filed, or that a termination conversation is scheduled for 2 p.m., can tighten its thresholds precisely when the mechanics of this piece say the risk is concentrated, instead of applying the same scrutiny uniformly across an employment relationship that, as the data throughout this piece shows, was never uniformly risky to begin with.