What You Need to Know About the GDPR
Article updated in July 2018.
The GDPR came into effect on May 25, 2018, and raises numerous questions among organizations that handle data in Europe. I gathered the questions and answers collected from our GDPR webinars (webinar 1, webinar 2) as well as questions asked by our customers. Here are the key takeaways:
- Are Organizations Ready for GDPR Compliance?
- Backup and Right to Be Forgotten
- GDPR Challenges
- What Are the Processes to Follow to be GDPR Compliant?
- Cloud Partners and GDPR Compliance
- GDPR Penalties
- GDPR 72 Hour Breach Notification
- Data Portability
- Are they any parts of privacy compliance that can be automated?
- Are there any compliance tools that can be used? What are the arguments to use such tools?
- Where should organizations start with GDPR? What would be the first step?
- Who should oversee this privacy compliance program?
- Do many entities outsource part of their compliance, or get help to create that initial privacy compliance program? What are the advantages of seeking some assistance?
- Data Protection Officer
- HR systems store employee data, what if a past employee migrated from a non-EU to an EU member state, in that case, would it be the responsibility of the past employee to alert the past employer?
- What is Privacy by Design?
Q: A large number of the customers I’ve spoken with are wondering how their compliance efforts towards the GDPR match up with other organizations. From your perspective, how far along are the majority of businesses to GDPR compliance?
A: Within the European Union, this has been out there for a while. It seems that companies in North America and the rest of the world are only realizing how serious this is.
Most companies are scrambling now to establish if they are compliant. In our experience so far, companies are not far along at all and most frankly are beginning to panic. If a disciplined approach is taken you can get
“From here to there”. If you look at it from a Change Management perspective, from an Awareness, a Desire, a Knowledge, an Ability and a Reinforcement, you can get from where you are today to how to get there.
Q: How do companies deal with backing up their data with the GDPR’s new so-called “right to be forgotten?”
A: Great question. The question should also be extended to archiving data as well. The key point is that backups and archives are different.
Backups exist in case information is accidentally destroyed. Backups should cover all information, but each one only needs to be kept for a short time. Since they are only needed when something goes wrong, access to them can be tightly limited. The legal basis for processing is likely to be the organization’s (and its data subjects’) legitimate interest in recovering from accidents. If you’ve got backup data, you may have a legitimate interest to keep that data for backup purposes. If the data is restored and there has already been a request to delete that data, you will still be responsible to do it. But it is a grey area at the moment because backup should be held with all the information in the backup.
Archives, by contrast, involve long-term storage of the organization’s history. The legal basis for archives may well be that they are a legal obligation or else the legitimate interest in retaining an organizational memory. Either is yet to be proven in a court of law.
Where personal data are being processed based on legitimate interests, the individual is entitled to raise an objection, under Article 21 (right to object), requiring the organization to check that its interest in the processing is not overridden by the resulting risk to that individual’s rights and freedoms.
There are rules around banking information for example. What happens when you have to keep the data for 7 years but you received a request from an individual to delete their data? That legal request will circumvent that right to object. If you have a legal requirement to keep the data for 7 years for banks or for HIPAA or PCI reasons, you do have a legitimate reason to keep that data but if you do not have a legitimate reason to keep that data and you restore a backup or take out an archive you will have to delete the data when you recover it.
Q: What have been the biggest challenge for customers to become compliant with GDPR thus far? Have you run across any systems that just will have to have exceptions built in until they could need to be redeveloped or migrated?
A: The biggest challenges I’ve noticed when working on GDPR compliance for a lot of people have been to:
- understand the legislative framework
- map these legislations under one comprehensive framework for gap analysis
- prioritize and develop a remediation plan that takes into consideration their actual resources, such as people, technology and financial, as well as any projects or other standards that are already in place
- leverage different projects that are undergoing in the company and managed by different departments towards GDPR and avoid doubling up the work
- leverage cooperation between numerous departments
- keep control of the project and have a high-level vision of what is happening, and how the level of compliance is moving along
- accurately report to the board of directors and other stakeholders
- meet the requirements of accountability and documentation
What about doing a Systems Inventory?
Some might argue that the biggest challenge is to do an inventory of their systems.
Doing an inventory of your system right off the bat might not be the right solution, especially if 60 quick and affordable fixes can be applied to reduce your privacy risk exposure.
It’s a false belief that GDPR compliance can be achieved the same way by all organizations regardless of size, resources and industry.
A: You should be following these steps:
- Statement of Applicability :
- What parts of the GDPR applies to you?
- What are the national laws that you should be aware of in implementing your program (there are more than 50 openings in the GDPR for national legislations to complete or increase the requirements of the GDPR, including opportunities for national supervisory authority to issue guidelines).
This will clearly cover whether you are a processor or a controller, but you can be both, so it’s not necessary the right questions to ask right off the bat. You need to identify your data transfer; e.g. My HR data are traveling from Germany to Canada, etc. Then you can decide for all those transfers and processing whether you are a controller or a processor.
For example, at Hitachi Systems Security, we are processors for our Managed Security Services and controller for Marketing and HR.
- Gap Assessment: taking into account what you have learned in the first step of the process (Statement of Applicability), e.g. all the laws, what are you missing to be compliant? This should be enterprise-wide examination.
- Risk Assessment: what is your risk exposure?
- Create a plan.
See also GDPR Compliance Services.
Q: Organizations are using cloud solutions and services like AWS more and more, and we expect that to increase over time. With regards to the GDPR, what are the organizations responsibilities for working with their cloud partners to make sure that their cloud partners are complying with the GDPR rules themselves?
A: The GDPR rules extend right out of your supply chain.
It seems businesses are assuming that by storing their data in the cloud it is, by default, compliant. This is not the case, and this ‘out-of-sight, out-of-mind’ mentality has contributed to many data breaches around the world. Storing data in the cloud without properly considering security is the same as locking your front door but leaving the garage open. It doesn’t work. Your enterprise network may be secure, but it means nothing if the cloud isn’t as well.
The following security protocols must be included in any cloud cybersecurity strategy:
- Two-factor authentication – helps to ensure only those authorized to access data can do so by ensuring the employee accesses through something they have (a phone) and know (code/password)
- Encryption – makes a business’ data unreadable and therefore useless to anyone that is not allowed to access it
- Key management – holds keys created in the encryption process to ensure only those that are meant to access the data do so. Often encryption keys are stored in hardware to prevent them being stolen
Q: What are your thoughts on the seriousness of the regulation? Are auditors going to be immediately penalizing organizations if they do not comply with the GDPR?
A: Factors to be considered are by reference to each individual case and it will take account of (amongst other things) the nature, gravity, and duration of the infringement, any mitigating actions taken and whether there is any history of previous infringements. Member states will have the discretion to designate breaches of specific aspects of the GDPR as criminal offenses.
The DPA’s (Data Protection Authorities) that administer enforcement notices and ultimately penalties, I believe there will be a ramp-up of enforcement policies and fines over time.
If you compare it to what happened with HIPAA for example, there were warnings given beforehand.
Given the fact that we now know more about privacy and controls, there may be a short runway into an era of more assertive enforcement.
Q: The legislation is now demanding organizations to notify customers within 72 hours of first having become aware of the breach – looking at the responses of Equifax, Yahoo and so many others, it took them months to notify some of their consumers. How are organizations going to do this?
A: Dwell time, the time that a botnet is within your system, can be the biggest issue here. Botnets can be in a system acting as a legitimate user for a long time exfiltrating data slowly from the network and systems. Once the breach has been identified, you do have 72 hours to report. As mentioned earlier, you do have the opportunity to “ramp up” the response. This means that you need to notify that a breach has happened and that your incident response team is investigating.
Q: How will the data portability piece of the legislation impact organizations?
A: This is the perfect reason why most organizations need to minimize the amount of data kept over time. This minimalist approach in “Privacy by design” or “Privacy by default” will ensure that the data required to keep on the data subject would be negligible and therefore sharing that or reporting that to someone else should be more straightforward. It comes down to discipline.
I don’t believe in full automation of compliance. Privacy legislation will always need to be interpreted by humans. Software can certainly support compliance. For example, the assessment of processing operations that are high-risk is something that can very well be automated analyzing an organization’s capacity to comply, especially over time, can very well be automated but in both situations, the outcome will be fully dependent on the quality of the input.
We can distinguish 3 types of tools:
- Legal research software: helping you to understand your requirements
- Privacy office support software: helping the development and maintenance of your privacy program by the corporative team
- Privacy management software: allowing organizations to document compliance
In most situations, tools will start to make sense if you have a large data processing operation or if they are rather complex. For example, if you are working across many jurisdictions. There are currently over 775 privacy laws in the world so if you are a truly global company that is something to take into account.
You’d need to have a compliance program in place because you need to understand what are the gaps, what you have in place, what resources you have… But to do this compliance program you will need to do this Article 30, which is data mapping, not at the granular level to know where your data is but at least at a high level: how you are processing data, are you a high-risk enterprise or not and that will open up the way for you to document your data privacy. You may go back in your data mapping later on to add things that you found out.
Organizations would appoint a privacy or DPO to be in charge of privacy compliance. It is mandatory in many situations under the GDPR but even if it is not mandatory it is often desirable in larger organizations. If you can’t do that or don’t see the capacity, a compliance or legal department could take up this role as well. In some organizations, the CISO takes the lead on privacy but you will have to pay attention, in that situation, that compliance is more than just technical measures. Many organizations also seek outside support to get their privacy compliance program up and running such as a DPO-as-a-service.
It is certainly a trend we see and it’s a bit of a challenge in both situations. If you don’t have the time to learn about privacy but do know your organization very well then it might be good to work together with a consultant. Nobody can do this alone. To assess what is appropriate, you need the understanding of what an organization does and how it works.
Q: What is a DPO? Why a DPO? Do I need a DPO? When to appoint a DPO?
We actually have a dedicated article answering all of these questions! Read it here.
It is not about the data subject and where he or she is located. It is about the processing.
For example, if it is a Canadian company and you just have one former employee in Europe, you shouldn’t be concerned about GDPR.
Privacy by Design can be found at Article 25 GDPR. The GDPR imposes Privacy by Design and privacy as the default setting to all controllers. We covered Privacy by Design in detail in this article.
Interested in knowing more about the GDPR? Access the webinar by clicking here or below.