The scientific research and healthcare sectors are constantly being reminded that they must protect sensitive and patient confidential data at all times. These are ingrained in their standard operating procedures and they understand too well the potential consequences of any data breaches. The need to encrypt sensitive or personal data is at the forefront of their system requirements.
In our Achiever laboratory information software, we encrypt patient identifiable data as standard. In fact, it was the creation of our laboratory management software that drove our encryption methods and enhanced data security capabilities. To meet the needs of the research community that was using human biological samples, it was imperative that our software could protect this very sensitive, and valuable data. Not just from external access – but equally from unapproved people within the same lab or team.
But other businesses also hold personal and sensitive data in their Customer Relationship Management (CRM) systems for example. How many of these systems hold your data in an encrypted format?
Who has access to your sensitive data in your CRM system?
We all know that our medical records are held in an encrypted format. But what about all the data that you hold about students attending your training courses or applying to your university?
Even if you just take their name, email address, residence and date of birth this can be enough. But if you start thinking about all the other associated information, what school they attended, what other qualifications they have and so on – the amount of potentially sensitive information you are holding about them soon mounts up.
And what about all the business sensitive information you hold about your customers and conversations with your customers? You may not want to advertise to the rest of the world what opportunities you have on the go. Or even what one of your delegates said about your courses or trainers.
Some CRM systems may offer encryption but how many of their customers know this – or even use it? And if these systems offer this they may encrypt all of your data – not just the sensitive information. This could result in you giving access to all data to all your users anyway.
In Achiever’s laboratory information system, we encrypt individual data fields. This means that researchers cannot see a patient’s name, but they can still see enough information to work with the samples – as long as they have the permissions to do this of course.
‘My data is safe as only the users who can access the system can see it’
You may think this but what about those users who can access your servers and databases? Your IT team – which could be internal or outsourced – have access to the back-end database where your data is held. By encrypting your data within the database, the only way anyone can
see it is by logging into the software. This means you have complete control over who can access your data.
And if your system is hosted then unless you specifically ask for your data to be held in an encrypted format it may not be as secure as you think.
It’s not just about encrypting data that you transfer between systems
Many systems encrypt and protect data as they transfer it. If you are passing data from your CRM system to your finance application this is very important. But equally as important is protecting your data when it is ‘at rest’- i.e. in the database and thinking of everyone who can access it.
The importance of conditional data decrypting
If you give your users access to sensitive data, should you allow them to see it all or just a subset? Being able to define the rules that govern who can see decrypted sensitive data is as important as being able to encrypt the data in the first instance. Applying blanket decryption of the database based on the user’s login may give you little or no benefit.
You can set Achiever’s decryption rules at project, role, event and data levels. This gives you a higher level of control over what your users can see. For example, as a project leader you decide who on your project team can see its associated data decrypted. And these rules can vary from project to project within the same system.
How do you encrypt sensitive or personal data in fields you have added?
Many software systems give you the ability to add new fields to hold additional data that you want to capture. Some systems that offer field-level encryption only allow you to apply it to their standard set of fields. But not the ones that you have added. Being able to add encryption to fields that you have created not only offers you greater flexibility but stops you from re-purposing a standard system field which may not give you what exactly you need.
Final thoughts on encrypting sensitive or personal data
Your data is valuable. It helps your run and grow your business. But if you fail to protect your data the damage to your reputation can be significant. You only have to look at the recent news to see how data breaches or misuse can lead to significant loss in customer confidence.
GDPR and other regulations have been created to make sure you are using your information correctly. The right software systems and technology can help make sure you protect it from unauthorised external, as well as internal, access.
What’s more, systems providing encryption that encodes and decodes the entire database may not be giving you the level of security and protection you need.
You need to be able to give your users access to sensitive data under the right circumstances and when they need it. Encrypting selected fields – and being able to add to and amend these when required – means your users can still carry out their work while your data remains protected. And being able to determine the circumstances when users can see data adds an extra layer of protection and puts you firmly in control of your data access and security. When you are thinking about software to run your critical processes consider whether you should also encrypt sensitive or personal data for added protection.