Following on from my previous article regarding the General Data Protection Regulation (GDPR) titled GDPR and what it means to you (Part 1), we’ll pick up where we left off and discuss some important areas to focus on, this is by no means a definitive list but will get you started. There are numerous methods to approach implementation to ensuring that your organisation is prepared for compliance come 25th May 2018.
Remember, the earlier you plan your strategy to implement compliance the more you will achieve and the actions required will be more manageable. Check that if your organisation or regulator requires you to be audited, that you book your auditors now for a date no later than April 2018 such that any outstanding controls may be completed on time and re-audited if necessary.
Below are 12 areas which need to be addressed, some of which are related to existing Data Protection legislation, so if you’re already doing what you should be and compliant, being ready for GDPR will be much easier to achieve. I have tried to go into much detail on some of the points as I can and I hope you find it useful.
- 1. Get everyone on-board, and I mean everyone…
You should start by ensuring that all key stakeholders, decision makers, policy makers, budget holders and senior management are aware of GDPR, and what it means to them and the organisation. Complying with GDPR is likely going to cost you, maybe not in £,$ or € but certainly in time and effort. There are many ways in which to manage the route to compliance, such as creating a project or steering group, but do remember that you will need buy-in from all levels in the organisation, this is not an IT issue although they could likely be your biggest ally in achieving parts of this journey.
Your organisation is unique, and so your approach to getting the right people on board will vary, there is no silver bullet and so gathering the right people who can ‘do’ will go a long way to ensuring the organisation’s success in being compliant.
Clear direction and instruction must come from the top, if the organisation tries to feed the process from the bottom up, there is a risk that different departments or teams will be going it alone and the full picture of activities towards compliance will not be known and therefore there will likely by gaps which could lead to something being missed.
Once you know all the right people who will be needed, you can then have everyone on the same page, meeting regularly to review progress and keep the pace going, all of this will pay off to get the organisation heading where it should.
- 2. Discover the data, look everywhere…
Data lurks everywhere, the start of finding the data is to look in the obvious places such as file servers, application servers, databases and corporate applications. But what about the other places, all those SaaS services that are being used, the desktop or ‘My Documents’ of staff and the infamous ‘shadow it’ hiding in far-flung places away from the corporate view and out of sight from IT.
GDPR requires that all data is managed effectively, so this means that you will need to rein in those obscure systems and often people’s attitudes and behaviours before you can start cataloguing the data, this has to be done first. Once you know where all of that data is sitting, then you can start identifying what you hold and therefore what controls may need to be changed and also how that data may be stored. You will also likely need to update or even create policies, and don’t forget that a policy is only any use if everyone knows about it and is following it.
Another approach is to identify all your systems and cloud services that are used throughout the organisation and then to see what data types are held and then a catalogue of the data type can be created which will allow for the data to be found easily when required.
There are also many software suppliers who provide data discovery tools which will go looking for data and classify it, these are popular with compliance for PCI DSS in identifying PANs and where they are, but be wary and have a trial of such software on known data types and locations, as these tools are only as good as the people using them, and if the types of data are not fully understood, then how can the tool find them if it doesn’t really know what it’s looking for. Finding certain data types is easy such as NI numbers, DoB, Addresses and postcodes, these are easy to find because they follow patterns which a regex could identify, but other type of data that don’t follow patterns or where the data is encrypted will need more thought and therefore take more time to discover the data.
- 3. Tell your subjects (thats data subjects…)
This all needs to be presented in a clear way, likely that you will need to update the privacy notices in applications and on web forms along with paper based forms. Privacy policies will need to be visible and easy to find on your websites and that of third-party applications and SaaS services such that data subjects can read and understand it. You should also publish details of who to contact if they feel they need more details about the collection and processing of their data.
Along with how the data is to be collected, stored and processed, you also have to inform data subjects about the retention of that data along with reasons for collecting the data. Data subject also have the right to complain to the regulator if they feel that you are not handling their data in the right way.
- 4. Handling those SARs
Currently data subject can submit Subject Access Requests and these have to be processed and responded to within 40 calendar days, under GDPR this changes to one month. Also in most cases you will not be able to make a charge for SARs under GDPR, whereas currently you can charge a statutory amount. You will however be able to refuse to comply with requests which are excessive or manifestly unfounded, but you will need to notify the individual of the reasons why and they do have the option to complain to the regulatory authority for a judgement.
If you organisation handles a large amount of SARs currently, you will need to deal with these much quicker and also likely more of them. Having access to the catalogue of where data is kept will make this must easier to respond along with considering developing systems that enable individuals to access their data themselves easier online.
- 5. Get permission (consent)
There are many methods that are used within an organisation to collect data from individuals, but before you collect any data, you will need to ensure that explicit consent is obtained and also you will need to store details of this consent. Under current legislation you needed to obtain consent but not necessarily store details of it, the fact that you collected data after asking for content meant you could collect and process the data but not necessarily know all the details about the consent itself.
You will need to explain exactly what data you plan to collect, what you are going to do with it, how you are going to process it and who else you will be sharing the data with, this also means third parties who process data on your behalf, all of this needs to be presented in a clear and easy to understand way up front, in order to seek explicit consent to the collection and processing.
You are not required to seek new consent retrospectively from individuals which you are currently processing, but you must ensure that you are processing their data in a GDPR compliant manner. You must therefore ensure that any data you are processing which was collected prior to 25th May 2018 you are processing it in the following compliant ways;
– properly documented
– easily withdrawn
If you cannot demonstrate these traits about how you are doing it, you will need to update your processes and then you must seek new consent from those individuals.
The previous method of ‘implied consent’ is no longer an option, therefore statements which suggest that ‘if you don’t tell us otherwise we will add you to our mailing list’ are not compliant, you must therefore ask if the individual ‘please tell us if you would like to be added to our mailing list’ for example. Some organisations are already practising this explicit consent, but there are many that are not.
Any finally, individuals will have the right to withdraw their consent to you processing their data, unless there are contractual reasons as to why you cannot fulfil something without their consent, for example, employment contracts have to be fulfilled by both the organisation and the individual, in order to pay someone you need to process their data, without their consent to do this, you are not able to pay them, and this would breach the contract of employment, also there are statutory regulations in the UK for employers to process data and return data to government agencies and therefore is something that must be done.
This is likely going to be one of the most time-consuming parts of preparing for GDPR because there are many changes in this area. I won’t cover some of the finer points of consent, but maybe I will do a follow-up article on this area specifically.
- 6. Reasons for processing data (lawful ones, just ‘because’ isn’t a reason)
But what does lawful processing of personal data actually mean, because this is likely something that you haven’t considered before under existing legislation. The lawful processing of data doesn’t have any implications under current legislation thus it is important to understand that under GDPR the rights on an individual can be different depending on the lawful basis of processing their personal data.
You should fully understand all the processing activities and why you are doing them in order to satisfy that the organisation is do so lawfully. This helps the organisation to comply with the new requirements in GDPR around ‘accountability’.
- 7. Subjects rights, and what you can do with their data
GDPR also requires that you document and retain records of processing activities such that you are able to identify all the systems and processes that data will touch, this ensures that should any data found to be inaccurate, this can be fixed quickly and also the processes rectified that may have been at fault. This also comes in where you share data with third parties as you may need to update them to correct data that you had shared.
Individuals rights under GDPR have been expanded to include the following:
– the right of access
– the right to rectification
– the right to erasure
– the right to be informed
– the right to data portability
– the right to object
– the right to restrict processing
– the right not to be subject to automated decision-making including profiling
Some of these are new with GDPR over the rights and individual has in current legislation, particularly the last one. This is going to have a big impact on some organisations that process data in order to offer a product or service that depends on the outcome of automated processing,
If you are already conforming to current legislation then you should be able to transition to these new rights fairly easily but you do need to ensure that your procedures and processing is documented, and prove to yourself how you would respond should an individual exercise all of these rights, and to understand what you will need to do or change to be ready.
Along with other areas, this also goes towards demonstrating the new principle of accountability.
- 8. Breaches (oh no, but you have to plan for them)
Every organisation should already have comprehensive incident response plans and procedures, and already under current legislation you are required to report certain breach’s to the regulator. Under GDPR this has changed somewhat, you may have to report the data breach to the regulator and also to the individual who have become affected. If the data breach is likely to cause a risk to the individuals rights and freedoms then you have to report this to the regulator and to the individuals as well. The risk to individuals is a bigger concern, therefore if the data that is breached would cause harm to the individual then they must be notified.
So, what would constitute a breach that causes a risk to the rights and freedoms, this is not a straight forward answer. It’s up to the organisation to assess its data and to decide what kinds of data fall in this category and what data doesn’t such that it can be effective should it be required to do so.
The time to report a breach has also been defined, all data breaches that require notification have to be done within 72 hours of the breach being detected. This also means that processes and procedures need to be clear about how the organisation deals with detection and who in the organisation needs to know, the Data Protection Officer if you have one, will be the one who will need to do the notifying, so make sure you know who that is.
Failure to report a breach when required to do so, or failure to report in a timely manner could result in a fine against the organisation as well as for the breach itself. Go and check your incident response plans and ensure that it’s up to date and responsibilities are clear, then make sure everyone in the organisation who knows how to report incidents to the incident manager.
Consider encrypting the data at system entry as this is a excellent way to mitigate against data theft, and should you suffer a data breach where the only data to be exfiltrated is encrypted, then could spare yourself a fine, however don’t rely on this alone as your processes and procedures will still come under scrutiny from your regulator, but by showing good security in process, storage and system design, your dealings with the regulator will be in your favour. Ensure that any security controls are tested regularly and that each time a system or process is changed that the security of the system is retested by your security team or a third party tester. Pay particular attention to any web applications, as these know the passphrase for the database in order to write data and therefore are at risk more so than storage where tokenised access can used.
- 9. Data Protection by Design
Best practice approaches to system design and software development should be at the heart of all organisations, all systems put into production use should be tested for defects and against common threats, and where data is stored these should be tested for vulnerabilities from attack vectors like cross-site scripting and injection. Under GDPR this approach is now a requirement and places a legal duty on organisations to ensure that ‘data protection by design and by default’ is incorporated into all systems and processes.
Data Protection Impact Assessments (DPIA) must be conducted against systems and processes where there is a high risk to individual’s data, such scenarios include:
– where new technology is being deployed (new systems, new methods of processing)
– where a profiling operating is likely to significantly affect individuals
– where there is processing on a large-scale of the special categories of data
Where a DPIA is conducted and the data processing is high risk, and you cannot mitigate those risks, you will need to seek further information from your regulator as to if that processing is compliant with the GDPR, failure to do this could result in a fine.
There is further clarification on this area published by the UK ICO and guidance from the Article 29 Working Party, so make sure that your organisation know how to implement DPIAs and decide how they are done and by who, and if they are going to be done as part of organisational processes such as project management or risk management.
Adding DPIAs to project plans for all new systems or upgrades ensures that they will be conducted and therefore any risk identified can be managed as part of the project before it completes.
Once again, use encryption where possible especially on special categories of data, but as a minimum you must use encryption whilst data is in transit especially between systems you are not in control of, such as your third party processor.
- 10. Data Protection Officers
Whether you are required to have a Data Protection Officer is something that you need to consider, there are some organisations where there is a requirement to do so, these being:
– a public authority (except for courts acting in their normal judicial capacity)
– an organisation that carries out regular and systematic monitoring of individuals on a large-scale
– an organisation that carries out the large-scale processing of special categories of data
So even if your organisation isn’t required to have the specific role of DPO, it might be worth considering having someone n the organisation designated as one, they would be the focal point for all things GDPR and be the champion throughout the organisation.
The more important part is, someone in the organisation takes responsibility for your data protection compliance to ensure everyone has the right support and knowledge and that everything is in order ready for GDPR. They should also have the authority to make things happen and to get important decisions made at stakeholder level such that GDPR is throughly understood and the organisation is compliance with the assurance necessary.
The Article 29 Working Party has some guidance for organisations on the role and position of a Data Protection Officer.
- 11. Geography
All organisations need to know the areas in which it operates, but with GDPR in mind, your customers or data subject might be in other EU member states and as such GDPR places different requirements on how an individuals data is protected. Your regulator is the one in the state where your main administration centre is or your headquarters. However, if you operate in more than one state or you process data mainly for individuals in a different state then this could well change who your regulator is. You should understand the processing that you do such that you can determine your ‘main establishment’ and this will indicate who your regulator is.
In the UK the regulator is the Information Commissioners Office (ICO) so this is who is the regulator for most UK organisations unless you are based in the UK and processes data mainly for other member states in which case it will be the regulator where the data subjects mainly reside.
The Article 29 Working Party has published guidance on identifying the right regulator or supervisory authority so if in doubt, take further guidance.
- 12. Children
The processing of data on individuals who are considered ‘children’ needs special treatment. As part of your data discovery exercise ensure that you identify if you are processing this kind of data as you will need to make sure that you obtain parental or guardian consent for any processing of their data.
In current legislation there isn’t a specific requirement to verify the age of a data subject, because you may not be collecting that data, but under GDPR there is a specific requirement on getting consent for children.
GDPR has set the age at which an individual can give consent at 16 years of age, and in the UK the ICO is suggesting that this may be lowered to 13 in some circumstances. This requirement will need consideration for any organisation that has an online presence or is a social networking or ‘information society service’ aimed at children, as the requirement for seeking and obtaining specific consent from a parent or guardian will be more onerous.
This area will likely get careful scrutiny as we get closer to May 2018 especially with the current media interest in social networking sites and the UKs new Digital Charter announced in the Queens Speech.
- In conclusion
To conclude this article, we’ll finish on the fines and special categories as these have an impact throughout compliance to GDPR.
The special categories referred to explicitly are moreover the same as what we consider to be ‘sensitive personal data’ under current legislation, but now you need to consider data in context. For example collecting the name of next of kin for the purpose of managing a pension alone is not a special category, but this information would give an indication of an individuals sexual persuasion and therefore you need to take this into account when processing data.
Alongside this, the consent of collection of data also cannot always be taken to be the lawful basis of processing, because when some specific data is put in context with other collected data (as in the above example) it becomes a different lawful basis for processing. As discussed above, you will need to conduct Data Protection Impact Assessments on all your systems and processes, which will identify where you are collecting data which is going to need special considerations.
Heres a quote from the Article 29 Working Party which sums this up:
“… obtaining consent does not negate the controller’s obligations under Article 6 with regard to fairness, necessity and proportionality, as well as data quality. For instance, even if the processing of personal data is based on the consent of the user, this would not legitimise the collection of data which is excessive in relation to a particular purpose.”
The fines that can leveraged by the regulator are much larger than current legislation, the regulator can fine an organisation for a data breach of €20 million or 4% of organisation’s global annual turnover per breach, coupled with the failure to report the breach within the 72 hours of it becoming know, the regulator can fine an additional €10 million or 2% of organisation’s global annual turnover, which I think you’ll agree is a massive incentive to make sure that you get everything in order by the 25th May 2018 when the GDPR becomes enforceable throughout the EU.
I hope that you have found this article interesting and informative and please stop by again soon for more articles on aspects of Information Security.
If you have any comments, please leave them below or get in touch via the contact details not he About the Author page.