The Why, What, How, Where, When and Whom of GDPR
Unless you have just arrived from a round trip to Mars, you couldn’t have not heard of the new EU data protection law – the EU GDPR. The new data protection law that will have global impact on any organisation processing EU resident’s data and the huge fines it is likely to attract for non-compliance.
If you have not, then don’t worry, you are not alone. With less than a year to go to when the enforcement kicks in, there are many organisations across the globe that too have not heard of or are not doing anything to become compliant. There are other organisations that are struggling to start their GDPR compliance programmes. We cannot do anything about those organisations unwilling to do anything about GDPR but we can help those that want to but need help.
This article is aimed at organisations struggling to set off towards compliance or get to a point where they have covered most of the important areas of the regulation. There is no silver bullet or a single magical technical solution that will make you automatically compliant. You will have to do the work. The good news is that most of it is common sense and those already at a decent maturity level with their current data protection regime will find it an extension of what they already are doing. As with information protection, most of it is basically what you should have been doing all along. I’m positive that most will agree that it makes sense to understand what data you have, where you use it and who has access to it? This article will try and explain the why, what, how, where and who question that need to be asked and answered in order to become compliant.
So, let’s begin with why we need to do this?
The first part of the Why is easy, because GDPR is a law and you must comply with the law or you will get a big fine, lose your reputation, the trust of data subjects and possibly the closure of your business. This is serious stuff.
The second part of Why is about understanding why you are processing the data in the first place. What are your business reasons or rationale for collecting and processing personal data? If you can answer this question, then you are on the way to understanding your legal basis for processing personal data. Answering this question could inform if you whether you have legitimate right to process, have contractual obligations to fulfil or require Consent as the legal basis of processing. It is therefore important to be able to answer this question at the outset. The Why will also provide the rationale and basis for how information is obtained, processed, retained, how long for and who it is shared with.
- Understand your legal basis for processing, – do you need to rely on Consent or do you have another basis for processing?
- If you need Consent, is your current consent still valid and do you now need to obtain consent again?
The What is a trickier question to answer for most organisations. What, is about understanding what personal information you hold, process and share. This is not a simple question as it seems to answer. If you do not understand what data you collect and process you will surely fail the GDPR compliance requirements and the specific controls required to protect the data. This is especially true for special categories of data (some of which was previously known as sensitive personal data) or children’s data, automated processing and decision making, monitoring and profiling which requires additional considerations.
The problem is, most organisations have acquired mountains and lakes of information. It is said more information has been collected in the last two years than all the information put together from the beginning of time.
Whilst there a lot of information that is structured, i.e. in databases, file systems, spreadsheets, indexed, tagged and labelled, however, the majority of recently collected data is unstructured and it continues to grow at an exponential rate. This data no doubt contains personal data but it may not. The problem is, it is hard to assess until you do the hard work to find and catalogue this unstructured data.
The GDPR introduces the need to create a personal data inventory or records or processing activities, Data Protection Impact Assessment (DPIA) and Privacy by Design (PbD), all required for knowing the What. The data flow mapping exercise will inform at least the Where, Whom and How the data is used.
From a security perspective, this will help to ensure you have the most appropriate security controls in place. For example, in terms of access controls and authorisations to personal data. Both important controls in protecting personal data. The What is also about the definition of the scope of your GDPR programme. The What should help you frame and scope your GDPR programme. It should help you to realise where the data interfaces, gaps, risks and boundaries are. These are likely to change but make a start with as-is state.
- Carry out data discovery exercise, don’t forget printed information, spreadsheets and emails.
- Categorise your data into normal and special categories and understand requirements for each.
- Map data flows internal to the organisation and externally too. This will help you understand third-party risks and any contracts that require review and update, assuming you have these in place.
- If there are any changes as a result of GDPR to the existing data, then carry out DPIA to understand impacts on privacy.
- For new projects, include DPIA and integrate Privacy by Design into your projects and programme artefacts. Use check-points to check against GDPR requirements into the programme life-cycle.
- Review your contracts, documentation, policies and processes too.
- Look at your liabilities and risks regardless of whether you are a controller or a processor.
The How is how you do things in your organisations and how you should tackle GDPR compliance.
The next question to ask is How? For example, how the personal data is collected and used. Two of the most important intention of the GDPR is to prevent abuse or misuse of personal data – the lawful basis and security. Violations of these principles are likely to attract penalties and right to remedy etc. Therefore, it is critical to get it right here. This means using the data exactly for the purpose it was collected and avoiding secondary processing without obtaining further consent from the data subjects. If it was obtained under other bases than consent then this must be reviewed and the data subject informed of the change in processing. The How should be reviewed regularly to ensure the legal basis has not changed. In order to do this, regular data flow mapping, audits, risk assessments and reviews must be carried out.
Another important aspect of How, is the need to understand how the data was acquired in the first place. For example, do you have right consent, if this is what you are relying on to process the data. Where you transparent, unambiguous and for the special categories, explicit? Not forgetting data of vulnerable persons, such as children’s personal data, which requires parental/guardian consent.
The How also extends to how you manage the data. For example, do have data management/privacy strategy, which includes cradle-to-grave data management, security, record keeping, retention and deletion etc.
How will you respond to access requests, and other subject rights such as the right to be forgotten, portability, restriction on processing etc.? Will you be able to comply with these within the newly reduced timeframe if not automated for example? Will you need new tools, training for the staff etc.? Does your technology roadmap include GDPR solutions? Any IT project/programme will need to include GDPR requirements going forward not from privacy by design perspective but also solutions for some of the more challenging aspects of GDPR, such as data portability and right to be forgotten.
If you transfer information to other parts of the business outside the EU or to third-parties, then you need to consider how you will do this, under what internal (e.g. BCR)or external agreements and model contracts. You will need to consider how you will protect the data in storage and in transit between the two points. Paying careful attention to the protection of data in second and third countries, if data is transferred onward.
Another important How is, how will you meet the new 72 hours breach notification requirement? Are your processes, including your processors’ geared for this? Have they been tested? How will you detect breaches? Do you have the tools to detect and alert on suspicious activities? Are your people trained to detect and report the unusual and the suspicious just in case and if so how do they do this?
Many organisations cause greater harm in the post-breach handling and communication than because of the actual breach. Breaches, if not managed diligently can cause enormous harm. Can you be confident you have the right people, process and technology?
- Review how personal data life-cycle to see how you use the data, is it used lawfully and as stated in the privacy notices and T&Cs?
- Follow your data – map all uses of personal data inside and outside the organisation.
- Assess risks in data flows both to privacy and security of the data.
- Look at how you can best meet the GDPR requirements and especially the subject rights. Some of it may actually need technical solutions whilst for others a manual process may suffice.
- Build and test your incident detection, handling and response capabilities.
- Review and build your technology and solutions roadmap with GDPR in mind.
As mentioned before, the Where is not only about where the data is collected but it is more importantly about where it is stored, processed and accessed from. The storage is about having adequate protection against compromise, corruption, loss or disruption. The processed could mean understanding who your processors and sub-processors are. Are there international transfers of personal data to countries outside the EU for instance? In the case of outsourcing/offshoring and for larger multi-national companies this is something that needs to be considered too. This means managing risks from data transfers and processing in destination countries, ensuring adequacy or alternative means and instruments are used to protect the personal information. The meaning of transfer is very wide. Even accessing information stored within the EU from outside the EU can be constituted as data transfer to the remote country.
Scrutinise existing contracts and draft GDPR compliant contracts, ensuring you have strict processing instructions and that they are included. Consider using a code of conduct with strict processing and breach reporting clauses. For internal transfers, ensuring you have Binding Corporate Rules (BCR) and so on. For cloud-based processing ensuring the cloud service is GDPR compliant is a good start. Also ensure you can meet your obligations such as the enhanced subject rights under the GDPR, wherever your data is hosted or processed. Don’t also forget data sovereignty and residency controls, both are important aspects of privacy too.
- Review and update your contracts with processors.
- Build your personal data inventory, including all the interfaces and sharing points.
- Review transfer methods, risks and controls to protect transferred data.
Personal data can only be used for the purpose it was collected and once that purpose has been met, it should be securely disposed of. It cannot be used for secondary purposes without consent in the absence of other legal bases. Therefore, the first set of questions to ask is when was the data collected? Is it still relevant, accurate, up to date, useful and most of all do you still have the legal basis for processing under GDPR? Do you need to re-obtain consent, if consent was used to collect the data? How will you re-obtain consent without violating privacy or be accused of marketing?
If you cannot use the data under then you have to start all over again and gain consent or find another means for processing the data, if appropriate? If the data is inaccurate, out of date or incomplete then you could get into a whole lot of problems. Legacy databases with obsolete data should be cleansed. Look into de-duplicating data that could be related to the same persons they may have registered multiple times using identities. this is required for example when it comes to things like the right to be forgotten. You don’t want to delete one records but retain another for the same person. Was part of a programme to do this. It is not a trivial task!
You should also ask when do you need to dispose the data at the end of its life-cycle. For this build a retentions schedule against GDPR and all other competing regulatory and legal compliance regimes. They will have different retention requirements will need to be balanced with the GDPR.
- Review legal basis, e.g. consent, legitimacy, contracts etc that allows you to process data. Has the legal basis changed?
- Review the data for currency.
- Cleanse the data, improve data quality and integrity. Great opportunity to start afresh with a single version of the truth and an authoritative data-set.
- Review data retention schedule and get rid of obsolete and unusable data.
- Review and update your policies on collecting and using data.
GDPR requires accountability across the board. Starting with the top level management, in controller and processor organisation. Both are now liable for data breaches, miss-processing. The Whom means, taking accountability and defining privacy and data protection roles and responsibilities. Everyone needs to understand their roles in protecting personal data and contribute towards compliance.
The Whom also can mean understanding who your supervisory authority is, what their requirements are. Who your internal and external stakeholder for personal data and most importantly whose data you are processing. For example, if you are processing special categories of data, you need to be able to meet the more stringent requirements of the GDPR.
The other related important question here is who has access to the data and with whom the data is shared. This means building a list of suppliers, what data they have, why and what role the play in processing this data.
- Ensure roles and responsibilities for privacy and data protection is clear.
- Ensure all stakeholders, including the supervisory authority for all your processing, is known. Consult them if you need advice and guidance. They would appreciate it and hey it is free advice from the best source.
- Ensure you know whose data you are processing and any specific requirements that come with it.
- Provide privacy and security awareness training for your staff, it is their data too.
I hope this not too detailed article helps to provide some guidance and some practical pointers to what organisations need to do to start completing the GDPR jigsaw piece by piece.
Author: Moyn Uddin GDPR-P, CISSP, CISA, CISM, CRISC, ISO27001 LA, TOGAF is a certified GDPR and Cybersecurity practitioner. He is also the co-author of RESILIA – Cyber Resilience Best Practices from AXLEOS, published in 2014 and the author of the accompanying Pocketbook. He is also the lead author of the Cyber Resilience Best Practices training course for ITpreneuersLinkedIn: www.linkedin.com/in/moynuddin