In any business, change is unavoidable. Employee turnover and shifting roles are an inevitable part of that change. When those things happen, there are a lot of issues to deal with related to HR and business impacts, etc.

Unfortunately, something that’s often overlooked is the employee’s permissions and access. If these issues aren’t addressed in an appropriate and timely manner, the consequences can be dire for your clients and your business — costly fines, data breaches, lost information… all things we know you’d rather avoid.

At Indiespring, we take data security very seriously and would like to share our guidance on how to ensure your and your clients’ data stays secure — no matter what staffing shifts might take place.

It’s easier to grasp if you take your customers as an example. When you are onboarding them, you allow them access to the tools and areas they need. It would be insensitive and unnecessary to allow them access to other client data.

Possible Data Security Risks

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.

How to Avoid Data Security Issues

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.