In part 2, we'll look at how customer consent should be handled, offer technical recommendations, concluding with the next steps you should take.
Consent: Do you agree to opt-in and carry on reading? If no, look away now.
I bet you were wondering when you were going to find out what you might have to do about consent. Let’s jump right in.
The definition of consent described in Article 4 point 11.
‘any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her’
This translates to opt-in checkboxes only. There are no opt-out checkboxes anymore. What I mean is, preselected checkboxes or tick here to opt-out of receiving news letters should most definitely no longer be implemented. It shouldn’t come as a surprise. I guess no more having to read and understand those checkbox options that read something like…
‘Please tick here if it is it not true that you don’t not won't to NOT RECEIVE emails from our partners’
Apparently, this kind of statement contains ambiguity and it is unclear. You need to provide a clear statement of consent and a clear way for a user to indicate their intention by taking definitive action like ticking the associated opt-in checkbox.
Article 7 condition 3 states that ‘It shall be as easy to withdraw as to give consent’. So, when an individual joined up to be a member of your organisation through your online form and had to tick a box to give consent to receive newsletters, is it just as easy for them to withdraw their consent or do they have to email to an unsubscribe list or even call up your admin team who will add it to their list of things to do that day?
One recommendation would be to enhance the customers preferences page. If someone signs in to your system, the Rights of the data subject could be visible and manageable by them. What would they see on this page?
- The data you hold about them.
- A breakdown of what certain pieces of data are used for.
- A way of opting in and out of how their data is used.
- What Data Processors have access to their data.
Some of this will already be available to see in this old school preferences page and at first it seems obvious as to what some data is used for. For instance, you may state that you use their first name, surname, postal address and email address to send emails about related products that they have bought before. They opted-in to this.
What they may not currently know is that you share data with a 3rd party organisation. You will need to be transparent about this. Article 18: Right to restriction of processing could translate to the Data Subject requesting that for these communications by the 3rd party organisation, their details like first name and surname not be passed on and used, however, they still wish to receive communications on offers.
So rather than removing the Data Subject completely from the 3rd party organisations list, in their preferences they can opt-in to receive communications from the 3rd party and opt-in to pass on and use their first name etc. for communications. However, they may not want to opt-in to the latter, in which case in the 3rd party communications which they have opted-in to, the salutations will now read as Dear Valued Customer.
This kind of forethought to combine GDPR compliance with you own goals ends up a win-win in this scenario for all parties; the Data Subject gets to choose who their information is shared with and you get to still send marketing information, and the key is transparency.
The work that needs to be done is to extend the customers preferences page coupled with a clear statement of consent and a checkbox that allows a Data Subject to opt-in.
The technical challenges are not really challenges. Some relatively simple changes to the database to store these extended preferences and log when and by whom these changes were made will go a long way to helping when you are asked to provide evidence of these opt-in changes.
Now for a more technical bit: Please, keep it short!
Right I may throw a few words in here that are hard to pronounce let alone understand. But I must because for the purposes of this article, we want to understand some of the tangibles for work that needs to be carried out to meet the GDPR.
Some recommended techniques for protecting personal data are pseudonymization and anonymization. There are many sources on the web that get into its detail so I will not repeat them here. Rest assured, there are tools out there that can help us with protecting personal data.
Why not just encrypt the whole database? You could by using a feature called Transparent Data Encryption (TDE). This is a feature available in SQL Server Enterprise edition (I know, there are other databases out there but for illustration let’s stick to one) and there are many other advanced features and capabilities that will come with Enterprise which you will never use, so if you don’t want to significantly bump up your licence fee just to get access to this feature then you may just want to upgrade your SQL Server Standard version to 2017.
From SQL Server 2016 Service Pack 1, a new feature called ‘Advanced security: Always Encrypted Row-level security, data masking, fine-grained auditing’ has been introduced (This is a good article that briefly explains how it works). It is designed to keep personal data safe. Even when a developer needs to work with the production database, the personal data will be masked. You will need to upgrade versions but not editions of SQL Server.
Encrypting and masking personal data is where we want to get to and upgrading and enabling this feature along with configuring some changes in your app to work with this change is going to tick one of the GDPR boxes. It is a big tick too.
Throw in some standard SSL, and perhaps hardening up your data infrastructure with other security measures to prevent DDos attacks for instance and you will clearly demonstrate your commitment to safeguarding your Data Subjects personal data and be regarded as an organisation to be trusted and ultimately give you a competitive advantage.
What next: Take the test.
There is a lot to know about the GDPR but to get started, you can put your organisation through a GDPR self-assessment. By going through these steps and answering the questions you will begin to paint a picture on the state of readiness for the GDPR deadline.
As you take the test, you may begin to realise that the questions about whether you have fulfilled GDPR requirements directly relate to some of the suggested real-world answers described in this article. If you need help answering some of these questions, just contact us and we can get you started.
To stay current with the ever changing landscape of technology, company websites should look to revamp and/or upgrade every 3-4 years max to keep current with new styles and to incorporate new functionality as business operations change, and GDPR is one of them.
Making an investment in GDPR compliance is essential to continued customer engagement, and in any future work we do for you, our developers will take the Data protection by design and by default approach.
So, the timing might be just right for your organisation, along with implementing GDPR compliance, a revamp and upgrade might be due. (But don’t worry, we can help you with that too).
Mike is a senior software engineer at Quba. He plays a key role in our technology strategy and software architecture. With over sixteen years’ experience in delivering online solutions to business problems, Mike has helped SME’s and multinational companies fulfil their online strategies. He has a wealth of experience in both how data is stored and managed, along with an expert understanding of online security.
In relation to this blog, Mike has produced a free guide to assist you with GDPR website compliance.
In addition to the guide, Quba is offering a GDPR website audit which will identify potential failings and provide actionable recommendations to ensure you don't fall foul of the GDPR and its hefty penalties.