How to Protect ISP Data When an Employee Leaves

When an employee leaves an ISP, protect your data by promptly limiting and disabling their system access: assign least-privilege user roles, deactivate or lock the departing user's account, and rely on historical access logs to track activity. In Sonar, role-based permissions, an Enable toggle, and built-in activity logs make each of these steps fast.

Although there is significant debate on how frequently individuals change careers, due to the opacity of what actually constitutes a "career change", it is no secret that "job-hopping" is a trend in today's workforce. In fact, many reputable sources (Forbes, LinkedIn, and Monster, to name a few) encourage changing jobs anywhere from two to five years and tout the benefits that a change can have on your overall career path. Something that everyone can agree on, however, is that a company will see a number of employees come and go throughout its lifespan; whether an individual is leaving a job on good terms, or it's the result of a termination, a universal truth is that turnover is unavoidable.

Why employee turnover raises your data security risk

With each employee that leaves the company, the threat to your data security and privacy practices increases, and this isn't only true for those that leave with malicious intent. Breeding a culture of information security within your organization helps increase awareness that security is a shared responsibility and that everyone has a role to play to keep the company protected; but with the rate at which a company's personnel changes over, this can be an increasingly difficult task.

Limit access with granular user roles and permissions

Sonar Software understands the importance of keeping private information private and helps combat this issue through the use of user roles. By creating a role, you can define which set of permissions a user receives, and can therefore limit the areas and data of your Sonar instance that a user can access and interact with. One role can be applied to various users, such as those who share the same job duties, or they can be tailored for each employee; with over 300 highly granular permissions available to select from, and the ability to create as many roles as required, you are provided the flexibility to define a user role for every scenario that fits your organization's needs. Not only does this help with privacy and keeping sensitive information protected, but it also helps reduce the chance of employees accidentally modifying areas of Sonar that shouldn't be accessed.

If you are looking for a jumping-off point, some commonly used roles within Sonar instances include those for your:

customer portal user

customer support representatives

sales agents

field technicians

Additional information on these roles, as well as general user role creation and best practices, can be found in our knowledge base documentation and cast video on the topic. For those that prefer handling role creation using GraphiQL, rather than through the GUI, the mutation and parameters needed to create each role through GraphiQL are available in the knowledge base as well.

Disable access promptly and keep historical logs

Whether the employee is leaving on agreeable terms, or less favorable ones, disabling that user's access is a crucial step that should be handled in a very timely manner. Sonar makes this easy by providing an "Enable" option for each instance user, which when unchecked, effectively removes the user's ability to access the system. Even after a user is disabled, however, their historical interactions with the software will still remain intact. Historical access logs are another way that Sonar helps to safeguard your data; in nearly all areas of your Sonar instance, activity logs are available, providing details on the change that occurred or the entity that was viewed, the date and time of the event, and the user who initiated it. Therefore, if a due date was added to a ticket, a scheduled event was created for an account, or the management page for a network site was viewed, details for these events will be stored and accessible from within your Sonar instance, and will remain in place long after an employee has left.

How to handle abrupt departures with open tickets or jobs

However, in some situations where the departure is abrupt or unplanned, the employee in question may have unresolved items associated with their user, such as open tickets or jobs - a condition that will prevent the user from being disabled within the instance, until those items are closed or reassigned. Since discussions might need to take place with other employees before these items can be resolved, it is recommended to change the username and email fields for the employee's instance user, if this situation arises. By changing the username and user's email in the system, you can leave the user enabled while preventing the employee from regaining access to your Sonar instance. For more information on the steps required to do this, as well as general information on removing terminated employees in Sonar, continue reading the documentation available on this topic within the knowledge base.

Hopefully, this article has provided insight into additional ways you can maintain your information privacy, increase data security, and ultimately protect your company when dealing with employee turnover.

Frequently asked questions

What is the first step when an employee leaves?

Disable the departing user's access in a timely manner. In Sonar, unchecking the "Enable" option for that instance user removes their ability to access the system while preserving their historical activity.

How do you lock out an employee who still has open tickets or jobs?

Open tickets or jobs prevent a user from being disabled until those items are closed or reassigned. In the meantime, change the user's username and email fields so they cannot regain access while the account stays enabled.

Do access logs survive after an account is disabled?

Yes. Historical activity logs remain intact in nearly all areas of Sonar, recording what changed or was viewed, the date and time, and the user who initiated each event - even long after an employee has left.