Data Inventory for Departing Employee Offboarding Processes
Missing inventory leaves security exposed during the highest-risk window in any employee's tenure.
The riskiest window in an employee's entire tenure at a company often falls after the resignation letter is signed but before IT revokes a single credential. Suspicious activity frequently begins up to six months before a formal departure, long before any offboarding workflow gets triggered. That means the standard sequence, where HR processes paperwork and IT deactivates accounts somewhere in the following days or weeks, is already responding to a risk that started half a year earlier. By the time termination is processed, access revocation, DLP monitoring, and audit triggers are reacting to data that has already moved. Offboarding deserves to be treated as a security event with its own attack surface, its own dwell time, and its own failure modes, not as a line item on an HR checklist.
The case of Rippling against Deel, filed in March 2025, shows what that window looks like in practice. Nothing about that access looked wrong to the systems watching it, because the systems watching it were built to catch violations of rules, not misuse of permission. That is the mechanism that makes departure-period risk so hard to catch: the access is real, the credentials are valid, and the activity resembles the employee's own job.
It would be a mistake to treat this as a story about bad actors. Fortinet's 2025 Insider Risk Report finds that most insider incidents are unintentional. The risk to the business is identical either way, because the exposure comes from the data leaving a controlled environment, not from the intent behind the click.
What makes this especially hard to manage is that HR, IT, and Security typically run on separate timelines with separate triggers, and nothing automatically connects them. The rest of this piece works through what it takes to close that gap, starting with a concept that offboarding programs tend to treat as an afterthought: knowing, in concrete terms, what data a departing employee could touch, did touch, and might still be carrying with them.
What "data inventory" means in an offboarding context
A data inventory in this context is a map, built around a specific person, of what data that person could access, what they actually touched, where that data may have gone, and what access artifacts remain live after they walk out the door, rather than a list of files sitting on a server or a compliance asset register that catalogs systems once a year. Built well, it answers four distinct questions, and each one requires a different kind of looking.
The first question is scope: what sensitive data was available to this person's role, broken down by system, application, and data type. The fourth is residue: what artifacts remain after the person has left, including shared links still live, API keys still valid, forwarding rules still active, session tokens, and cached credentials sitting on devices the company no longer controls.
Each of those questions maps to a real pattern security teams see before departures. None of these patterns look the same to a detection system, so an inventory built to catch only one of them misses the rest.
A data inventory also has to reach data that was never labeled sensitive. The most valuable intellectual property a company owns often carries no classification tag at all, because its sensitivity comes from what it means to the business rather than whether it happens to match a regex pattern in a DLP rule. A spreadsheet of pricing logic, a half-finished product roadmap, a set of design files for an unreleased feature, none of these trip a keyword filter, yet all of them are exactly the kind of material a departing employee might carry to a competitor without anyone noticing.
Fortinet's 2025 Insider Risk Report names visibility as one of the central gaps in insider risk programs today. Most organizations do not have the tooling in place to answer these four questions at the moment an employee gives notice, and many cannot answer them at all, even after the fact. That gap sets up the argument at the heart of this piece: everything an offboarding program does after an employee resigns depends on having already answered these questions, and most programs have not.
Why offboarding controls depend on inventory
Access revocation, DLP enforcement, legal holds, and forensic recovery all sit downstream of inventory. Each one assumes, as a precondition, that someone already knows what data existed and where it lived. Strip that precondition away and each control still runs, technically; none of them can do the job it was built for.
Start with access revocation. A standard offboarding process deactivates accounts in the identity provider, and that step works fine for directory-managed logins. API keys, OAuth tokens, shared service accounts, and persistent session cookies survive IdP deprovisioning because they were never tied to the directory account. A revocation process that only knows about the systems an inventory told it to check will leave every one of those artifacts untouched, and a process built without inventory never knew to check for them.
DLP enforcement runs into the same wall from a different direction. Traditional DLP tools sit at the perimeter, inspecting traffic as it leaves the network and flagging patterns that look wrong. An employee downloading files from their own project folder does not look wrong to a rule built around unauthorized access, because the access is authorized. A DLP tool, without knowing in advance which data was sensitive and in scope for that specific employee, cannot distinguish a routine sync from a deliberate bulk export happening at a volume and speed that only shows up in the days before someone leaves. And once a file has already landed in personal cloud storage or been copied to a USB drive, DLP's visibility ends at the corporate boundary. The file is gone, and without an inventory showing what should have still been there, no one even knows to look for it.
Legal holds depend on inventory just as directly. When litigation or a regulatory inquiry follows a departure, counsel has to define what data is subject to preservation, and that definition is only as good as the inventory behind it. Without one, the hold ends up either so broad it paralyzes normal operations or so narrow it misses the material that matters, which is a legally defective outcome dressed up as caution. For publicly traded companies, the stakes carry a hard deadline: SEC rules require disclosure of a material cybersecurity incident within four business days of determining that it is material. An organization that cannot inventory what was taken cannot make that determination inside the window the rule demands, regardless of how many lawyers it has on staff.
Forensic recovery is the last domino, and it falls for the simplest reason: investigators have to know what to look for before they can look for it. Without a pre-departure inventory describing what data existed and who could reach it, a recovery effort after the fact is closer to guesswork than investigation. This is the throughline across every control: the failure traces back to the same missing layer each time, and that layer is inventory. The Rippling and Deel case makes the point concrete. The alleged insider's access to Slack, Salesforce, and Google Drive was legitimate by every technical measure. Rule-based detection missed it for four months. A system that had mapped what data that role should have touched, and watched for activity outside that scope, had a chance of catching the exfiltration early. A system that only watched for unauthorized access never had one.
Where sensitive data lives for a departing employee
The data a departing employee can reach no longer sits neatly inside the corporate network. It spans corporate systems, personal cloud accounts, removable media, SaaS tools the company may not have approved, and generative AI platforms, and most legacy discovery processes were built for a world where that was not true. Client and customer records, source code, project files, design files, and product formulas make up the categories most commonly at risk, and many of them carry no formal label marking them as sensitive. A tool looking for tagged data walks right past them.
Personal cloud storage is one of the hardest channels to see into after the fact. A file uploaded to Google Drive, Dropbox, or iCloud exists entirely outside the corporate perimeter the moment it lands there, and it may have been synced weeks before the employee ever announced a departure. Without file-level audit trails reaching into that account, the file is invisible once the employee is gone. Removable media creates a similar blind spot through a different mechanism: a USB drive can be connected and disconnected without generating a single network event, so catching that channel requires endpoint controls that many organizations simply do not have deployed.
Generative AI tools deserve particular attention, because they represent the newest and least-covered channel of the group. Data pasted into a GenAI interface leaves the corporate environment without tripping any traditional DLP alert, since those tools were built to watch network egress by destination domain, not by the content or context of what's being typed into a chat window. Fortinet's 2025 Insider Risk Report identifies GenAI as a channel actively expanding the insider risk attack surface, noting that the volume of sensitive data flowing into these tools runs well above what most organizations assume, all while generating no signal that a conventional DLP system would ever flag.
Shadow IT compounds all of this. A SaaS tool an employee adopted on their own, outside of IT procurement, leaves no entry in the asset register and no account in the identity provider. API keys are among the most persistent artifacts left behind after departure, because they often survive deprovisioning entirely, untouched by a process that was only built to deactivate directory accounts.
Credential-based attacks from outside the company ride the same surface. When an external attacker gets hold of a departing or recently departed employee's credentials, the attacker moves through the same systems, using the same channels, that the employee used while still on the job. The inventory challenge in that scenario is identical to the insider case, because the access pattern on the wire looks the same, and a DLP tool built around identifying unauthorized traffic has no way to tell the two apart.
The organizational fragmentation that makes data inventory fail in practice
Data inventory breaks down at offboarding for reasons that go beyond missing tools. HR, IT, and Security typically run on disconnected timelines, using different systems of record, with no shared trigger that tells all three functions that a departure is underway. A manual, fragmented process results, prone to the kind of human error that structure is supposed to prevent: HR processes the paperwork, IT deactivates the accounts it knows about, and Security may never receive formal notice that an employee has left.
Where coordination exists between these groups, it tends to run through ad hoc emails, a Slack message to the right person if someone remembers to send it, or a manually filed ticket. No automated workflow connects the moment an HRIS system logs a departure to the moment Security begins a triage review, so the handoff depends on individual diligence. The deprovisioning window varies wildly from one departure to the next, often stretching into days or weeks rather than hours, and that same window is precisely when an inventory needed to have already been built.
Fortinet's 2025 Insider Risk Report describes effective insider risk governance as cross-functional by necessity, requiring directives, governance structures, and oversight that span HR, Legal, and IT together. Without that defined moment, the inventory process has no starting point, because there is no signal telling it to start.
Underneath this sits a deeper architectural problem. Most legacy DLP tools run in isolation from SIEM, UEBA, and other threat platforms, and that isolation makes it structurally difficult to pull together the four pieces an inventory needs: the person, held in the HR record, the identity, held in the identity provider, the data access, held in DLP or CASB logs, and the behavioral pattern, held in UEBA. Security budgets for insider risk programs have grown in recent years, but spending more on any one of these tools in isolation does not fix a problem rooted in how the systems are connected, or whether they are connected.
How behavioral monitoring and automated discovery expand inventory
Closing the gaps described above requires inventory to stop being a point-in-time snapshot and start functioning as a continuous process that runs for the full span between the decision to leave and the final deprovisioning step. Automated discovery tools that scan for sensitive data regardless of whether it was ever labeled can surface the untagged intellectual property that keyword-based DLP tools miss.
None of this works as a bolt-on to the fragmented process described in the prior section. Fortinet's 2025 Insider Risk Report frames governance spanning HR, Legal, and IT as a necessity for effective insider risk programs, and the data inventory function sits at the center of what that governance structure is actually meant to produce: a complete, current answer to the question of what a departing employee could reach, did reach, and might still be holding on their way out the door.
