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:
Disclaimer: This blog article was written by our compliance experts for general information and does not claim to provide legal advice. To understand the full context of your organization, please consult with a privacy compliance and/or legal professional.
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:
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:
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, we are processors for our Managed Security Services and controller for Marketing and HR.
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:
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:
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.