%20(1).png)
Scene: the goodbye party for a sales manager who is leaving for another company. After one of the company execs makes a speech of appreciation, they say to the sales manager, as an aside, “Oh, and you can keep your key to our offices. A memento to remember us by.”
?!?!
Never happened, and never will. (And not just because old-school keys are being phased out.)
If an employee leaves, they should not retain a method of access to your organization’s space and assets. Especially if they might be leaving for a competitor.
During their offboarding period, all keys must go.
The keys to your data kingdom
In the digital work environment where we spend much - or even most - of our time, our user identities and access credentials are the keys.
These keys open up our entrance to company SaaS applications (like Google Workspace, or Slack, or Salesforce) and all the data assets therein.
When a user leaves your organization, it’s only sensible that they should “return their keys,” but unlike the two-second act of handing back a physical key, it takes 47 total hours of work to manually deactivate and offboard a user who leaves the organization.
This incredible time and resource drain explains the popularity of IdP systems, like Okta. Their automation of the user offboarding process removes user access at scale, saving time for the IT team and reducing costs.These automated offboarding processes, however, often leave your departing users with some level of retained access to your organization SaaS systems. Most commonly this access is to data assets; sometimes it is even to entire applications. These are office keys with which your departing user is being allowed to walk out the door, and they might come back to haunt you.
This is not good news for your data security.
This post will take a look at:
- the situations where these offboarding gaps most commonly show up
- the data security issues caused by each type of gap
- how you can prevent these issues using DoControl
Offboarding hole #1: when the work email is still active
While IdPs are generally good at removing user access at scale, it’s not a foolproof process. We have often seen cases with DoControl clients of terminated employees who can still sign in to their organization’s Google Workspace even after the IdP offboarding process.
What’s the problem? Lack of synchronization between the systems.
In a recent user status alignment study we did internally based on our client data, we compared users’ HRIS (Workday/HiBob), Okta and Google Workspace statuses. The logical thing to assume was that the statuses should be aligned, as this is one of the primary reasons for using an IdP in the first place.
Unfortunately, what we saw was an unacceptably high mismatch rate between statuses in these different systems. For example, there was a significant percentage of terminated or deprovisioned employees in HRIS/Okta systems who remained active in Google Workspace, with an average mismatch rate of 5%, and some companies going as high as 17%.
The gaps got much wider when we were looking at suspended users in Okta. The most aligned company saw 28% of its suspended users still retaining active users in Google Workspace. And most organizations fared much worse, with an average of 73% of Okta suspended users still defined as Google Workspace active users.
This mismatch - where you’ve signified to your IdP that a user should be deprovisioned or suspended, but the IdP hasn’t managed to convey that to your corporate Google Workspace - can leave some gaping security holes. A former user with an active Google Workspace account can easily sign in and gain access to corporate applications and assets, viewing, modifying and downloading at will.
The mismatch can go the other way also, where an active user according to HRIS or Okta is for some unknown reason defined as inactive in Google Workspace. This doesn’t have security consequences, but it can have operational consequences.
Now, let’s say you could solve this issue and make sure that all systems sync 100%. In this ideal hypothetical situation, if you mark a user as terminated in your HRIS, you know with certainty that it will propagate correctly and result in an inactive user in Google Workspace.
Would solving the mismatch issue secure your SaaS offboarding? Can you now be confident that your former employee doesn’t carry any keys to your office?
Well… no. Not yet.
Because first we have to deal with…
Offboarding hole #2: access permissions for non-work emails
Are the users shared on your corporate Google Workspace assets 100% from your organization?
If yes, we’re jealous of your information security department.
The vast majority of organizations allow some level of permission granting to external email domains. Otherwise it would be too tricky to collaborate with clients, partners, contractors, agencies and the like.
So… what happens when your soon-to-be-terminated employee grants asset access permissions to my-personal-email@gmail.com or any other non-work email they own?
Even if they are fully offboarded, and have no way of accessing their corporate Google Workspace user account, corporate Google Drives, or any other applications - these individual assets will still remain available to them via the personal user accounts that were granted access.
Transferring the assets to a new owner (often the departing employee’s manager) doesn’t solve the problem. The departing user is no longer the owner, but all access permissions for the asset stay as they were.
These permissions to private, external emails may have been given innocuously, months before the employee ever dreamed they would leave the company, or they may be a deliberate attempt to retain access to sensitive company data even after the upcoming termination.
Either way, they leave a gaping hole for former employees to peek and climb through.
Now, let’s say you could solve this issue also, and find a way to remove all private/external account access belonging to this departing user. Not only will the former user no longer own the assets, but they will have no way of accessing them short of going to their manager and asking to borrow their device.
Does your offboarding process fully secure your data now?
Almost. But…
Offboarding hole #3: data theft during the offboarding process
Employee offboarding is not a two-second process.
It is usually about two to four weeks from the time an employee is given notice (or from when they give notice) to when they actually leave the company. During this time period, the employee still needs enough access to be able to do their work, even as you transfer their data to a new owner.
It is in this time period that employees pose the most risk to the company. They have one foot out the door, and incentive to look for assets to take with them to enhance their potential success in their new position. Most won’t, but it only takes one or two who will to do strategic damage to your company.
Departing employees should therefore be monitored more carefully. They should have more stringent definitions of “risky actions” applied to their behavior. A file download or share that would have been normal three months ago should raise eyebrows and an investigation now. Unfortunately, offboarding automation solutions like Okta do not have these monitoring and behavior analysis capabilities, leaving you vulnerable to data exfiltration.
What can you do?
Seal the holes with DoControl’s secure SaaS offboarding workflows
DoControl was designed to secure SaaS data under all conditions, and especially in the high-risk scenario of departing users. DoControl helps to:
Ensure user status sync for departing users
DoControl seamlessly synchronizes HRIS systems like Workday or HiBob, IdP solutions like Okta and SaaS applications like Google Workspace. Automated workflows can be set up so that as soon as an employee is marked “terminated” in the HRIS, they enter the workflow that will bring them to a status of “deprovisioned” in Okta and “inactive” in Google Workspace.
DoControl can also compare statuses between systems and initiate remediation upon encountering mismatches.
With DoControl, your organization no longer finds itself in a situation where former employees can still come and operate within your Google Workspace instance, or where it is paying Google for dozens of Workspace user accounts belonging to users who left the company long ago.
Bulk remove user access permissions for departing user’s personal or private accounts
DoControl not only solves the issue of application access through the user’s former corporate account, but also that of asset access through a personal email. Automated workflows and integrations with HRIS make it easy to find all user accounts associated with a departing employee and remove access permissions granted to any and all of those accounts.
This way, once the employee leaves, they no longer have any back door into the company’s data assets.
Monitor the behavior of departing user identities and act fast to prevent data exfiltration
What about the concern of data theft by departing employees? Here too, DoControl provides a solution.
DoControl’s Identity Threat Detection and Response (ITDR) capability monitors all user interaction with your SaaS assets and applications. Any risky actions are reflected in the user’s overall identity risk profile - and can also be the trigger for a remediation workflow.
Departing employees are automatically given a higher risk profile. DoControl’s HRIS integration enables DoControl’s ITDR to reflect this higher risk profile immediately upon designation of the user as “departing” in the HRIS.
Take back control of offboarding
Automated offboarding saves valuable time and resources. If it leaves security holes, however, your resources may be drained from dealing with the consequences.
With DoControl’s supervision and synchronization, you can be sure that this savings doesn’t come at the expense of your data security and control.
