How to Protect Data Security Amidst Staff Turnover

Unauthorised Access

This may seem obvious, but when someone leaves your company, their access should be removed from all systems as quickly as possible. It is a serious breach of privacy and GDPR regulations if your employees still have access to systems after they have left.

This may feel more obvious if an employee is leaving due to a negative situation such as a firing or layoff. If someone is leaving on good terms, you probably won’t expect any malicious behavior, and it might be tempting to take your time removing access. But you simply can’t take that chance.

It has been proven in court that employers are responsible for the actions of their past employees. In 2014, Morrisons Supermarket chain was responsible for a rogue employee accessing and distributing bank details, salary, and national insurance details. This was as a result of the company ‘forgetting to remove his access’ and resulted in a huge fine.

Also keep in mind that access issues occur both when someone leaves the company and when they change roles within the company. For example, if someone is a developer, they need access to a number of codebases in order to do their job. However, if that person is moved or promoted to a different role within the company, they no longer need that access. As roles change, so should access. As we use individual accounts where possible at Indiespring, it means we can easily add and remove users to systems or data without having an effect on others or the security of that data. It does also mean it’s easier to identify who had access if there is a problem.

Knowledge & Loss

Where appropriate, shared knowledge should be in effect throughout the business. This ensures when someone leaves, they are not taking all the knowledge with them. This can have an effect on even minor tasks such as logins.

If you are not prepared for this, it can become a problem, particularly for legacy or older clients. This can be addressed simply by ‘drip-feeding’ other developers onto the project. If someone has never worked with a technology, having them start on smaller improvements on issues both helps them learn and be confident. Before long you will have multiple developers skilled in the project, dramatically reducing the likelihood of knowledge loss.

Hardware

In some instances, it is acceptable for employees to use personal devices for work — particularly during a time when many of us are working from home. However, unless you are monitoring this for example with an MDM, then it’s very difficult to manage if they still have access to change or even see some of the data of your customers.

To avoid hardware issues, you should have a log of hardware devices, who they are assigned to and where they currently are. Particularly if you want to be compliant with ISO 27001. There is a control on ‘Physical and environmental security’ that covers the standards you should adhere to. As an example, the physical side covers logs of hardware, who it’s assigned to when it was bought and its security package. Whereas environmental security refers to the access that particular individuals should have and how you keep that access safe using password managers and individual credentials.

Programs define the various measures or controls that protect organizations from loss of connectivity and availability of computer processing caused by theft, fire, flood, intentional destruction, unintentional damage, mechanical equipment failure, and power failures. Physical security measures should be sufficient to deal with foreseeable threats and should be tested periodically for their effectiveness and functionality.

Use an Onboarding Checklist

The key to ensuring that you minimize risk as much as possible is by having a good plan for your employees from the moment they walk in the door. I recommend an onboarding checklist that ensures you know the access individuals need in their job roles. For example, at Indiespring we have a defined checklist for Project Managers, Designers, Developers and so on, each with unique access to tools. In this way, we remain compliant with the ‘Physical and environmental security control’ of ISO 270001.

Use an Offboarding Checklist

Reverse engineer your onbaording checklist to make an offboarding checklist. The line manager of the user in question can go down through this list to ensure access is systematically removed. If you use methods like SSO (single sign-on) then you only need to change that password and then systematically go through other tools and gradually remove access. Exit interviews can be a great time to run through the checklist of devices/programs the user needs to return.

Use an MDM

We’ve spoken at Indiespring before about how the use of MDMs will not only help you manage all devices, but in this scenario, they will allow you to ensure no devices are missed when being returned. It does also mean that you can be safer if you feel that someone may have malicious intent, as you can lock down/control the devices from your MDM.

Share Knowledge

In an app development world, it is very easy when a problem arises to get the most senior developer and assign them to that problem. You know they will get it done fast and to a great quality. Although in doing this all the time, you are then digging yourself into a hole. At the very least, you should be exposing another developer to the issue, with the most experienced proving a shadow. By the end of the issue, two people can now fix it. Exposing your team to more technologies or systems where appropriate will allow you to ensure that loss of knowledge is at a minimum, but more importantly, your team is more efficient.