GDPR - Can your systems deliver compliance? - part 1

One would hope in any IT system, protection of data was always part of the consideration and on a broader level, some technical implementations have been put in place already like one-way encryption of passwords and industry standard password validation amongst other server level security. But the new GDPR regulations is a game changer as we are required to protect the rights of the Data Subject in the way the regulations outline. 

As a company, we decided to look deeper into this to see what this means in practical terms; we wanted to identify some of those places in IT systems and business processors that will need changes. We are looking for tangible, meaningful steps that should be taken to satisfy the GDPR regulations. 

In part 1 we will look at steps to start a data audit and gap analysis, then look at a real-world example of disparate systems, and look at an example of who in your organisation or 3rd party might have 'too much' access to your customer data.

In part 2, we shall look at how customer consent should be handled, offer technical recommendations, concluding with the next steps you should take.

The Audit: Where is this data coming from? Tribal Knowledge might not be good enough.

The GDPR regulations force you to think about how you process your data, data collection methods and its use within your organisation. This audit is an important step in understanding how to identify the changes to your digital infrastructure to be compliant come May 2018.

Now is the time to take stock of your data processing. Begin by attempting to answer these questions and you will be off to a good start.

• How is the data from the Data Subject collected? Maybe via online forms?
• Where do you store that data? Databases, file system, 3rd party like Kentico cloud?
• How is that data transmitted across networks? Internal network, over the web, by email?
• Who in your organisation has access to what data and more importantly what do they use that information for? Helpline support, marketing, analytics?
• Are your 3rd party Data Processors (like MailChimp) taking steps to become GDPR compliant? You better check this.
• Do you know when you obtained a Data Subjects personal data?
• Can you explain what you are going to use the information for?
• Do you know how long you are going to keep the Data Subjects data for and can you explain why?

While you are answering these questions, be mindful of the reasons why you collect the data and note those reasons down. One of the biggies is how you obtain personal data and whether you had consent from the Data Subject as outlined under the GDPR regulations (we will discuss consent later). 

These reasons will sit under the umbrella of either your…

• Contractual obligations
• Public interest
• Legal obligation (tax, insurance)
• Vital Interest (for example medical notes)
• Legitimate interest (for example, for marketing similar bought products)

When GDPR kicks in, you can be sure that at some point you will need to process requests from individuals, sorry, Data Subjects, where they are exercising their new rights such as their right to be forgotten, right of access (to the data you keep about them and why) and their right to data portability. But can you do this from your current software? Or, can this be achieved already, but is a bit of a lengthy process to deliver evidence of this data in a 'structured, commonly used and machine-readable format'? 

These are processes that need to be automated and streamlined into your administrative software whether it is a CRM, CMS or bespoke software to avoid employee hours needlessly lost processing these subject access requests. 

To give an example, if an individual has an online account with your organisation, giving them the ability to carry out their right of access to see how their data is being used will require changes to that traditional profile/preferences page. Showing that data in its traditional form might not be enough.

In Article 15 point 3 it states that 'The controller shall provide a copy of the personal data undergoing processing'. (by the way, by default you cannot refuse to do this and the first one is free!) 

So, having the Data Subjects' data that is being processed easily exportable, will add efficiency to your processes and save a ton of admin time. But it also goes on to say, 'For any further copies requested by the data subject, the controller may charge a reasonable fee based on administrative costs.' So, has the first request been recorded? Can you evidence that so you can justify, if appropriate, charging for administrative costs of a second request? Clearly, new information needs to be recorded perhaps in the form of keeping a log as one way of recording that information.

Disparate Systems: 

Think about this scenario, when individuals sign up to your service, their details will no doubt be shared among different departments? It is not uncommon for an organisations IT infrastructure to consist of a public facing website, developed using a CMS like Kentico, where users can sign up and sign in to use your bespoke online services, a 3rd party CRM that handles more specialised customer relations, and even another 3rd party system like MailChimp for bulk communications. 

There is nothing fundamentally wrong with this set up, after all they were chosen because each specializes in delivering best in class functionality. But, GDPR regulations makes us look at how the data flows between each of these systems. To use a tangible example, let's revisit one of the Data Subjects rights; Article 17: 'The right to be forgotten'. Sounds simple enough. Find the Data Subject and hit delete, right?

When you do this though, does that 'delete' action trickle down or up to your other supporting systems? If you exercise a Data Subjects request to be forgotten and sign in to your admin portal of your CMS, find and delete the individual, will they get deleted from your CRM and from other 3rd party tools like MailChimp? Same thing if they are deleted from your CRM, will they get deleted from your CMS and will they wrongly still receive emails because they have not been removed from your marketing list in MailChimp? What about those exported excel sheets of Data Subjects that your marketing department uses as a filtered list of those you wish to market an event to. Do they get deleted from there? (Might be time to stop doing this by the way). 

These are the kind of actions that happen on the ground. Ideally, an all in one, centralized system is the dream, but sometimes the sum of the parts is cheaper than the whole.

To help comply with GDPR, tying in these systems by seamless integration will save hours on manual actions and checks for such a simple request of 'Delete me please'.

What you want is a single version of the truth. 

Roles & Privileges: Sorry son, you can't watch Blade Runner (Directors cut) because you are only 5

As an organisation, you will need to decide which admin groups will see what data about individuals. 

Customer helpline staff are an admin group that will need to fulfil the company's contractual obligations with the customer and, probably, will need to see personal details of the customer making the enquiry; name, address, postcode etc. 

In front of them might be a screen showing a list of individuals until the exact match is found. This group can see personal details; name, address, postcode so they can help the customer with their order.

Working off that same screen, the generic customer list, might be another admin group, let's say the Analytics department. They are mainly interested in seeing numbers though. For instance, the number of members who signed up last month. What they don't need to see are the names and addresses of these individuals. So, while they are working off the same screen, the first name, surname and date of birth should either be hidden or masked for them.

This is a simple example to illustrate awareness of visibility of data under the new GDPR regulations. Ask this, is it reasonable that the analytics team should be able to view names and addresses, and if not, they should not be able to have access to this personal information. This approach will appropriately shrink the detail of this view and satisfies data minimisation. In a nutshell, the data subject's personal data should be on a need to know basis.

Put another way, if you went to see a doctor because of your sore throat and the doctor asked you to take off your clothes right down to your 'personal data', you will probably feel slightly uncomfortable and regard it as excessive that this much information is needed for the doctor to carry out their role in diagnosing the reason for the soreness in your throat. Ok, bad example. 

Changes to this view of data potentially will require role based changes, privilege changes, and potentially coding changes. Implementing this demonstrates you have taken steps to safeguard personal details.

About Mike

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

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.