How to Protect Your Data When an Employee Leaves

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.

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.

Sonar 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.

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.

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.